4.11.6-stable review

This is the start of the stable review cycle for the 4.11.6 release. There are 13 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat Jun 17 17:54:16 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.11.6-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.11.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.11.6-rc1

Kai Chen <[email protected]>
drm/i915: Disable decoupled MMIO

Maarten Lankhorst <[email protected]>
drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

Chris Wilson <[email protected]>
drm/i915: Guard against i915_ggtt_disable_guc() being invoked unconditionally

Ville Syrjälä <[email protected]>
drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail

Ville Syrjälä <[email protected]>
drm/i915: Fix 90/270 rotated coordinates for FBC

Daniel Vetter <[email protected]>
Revert "drm/i915: Restore lost "Initialized i915" welcome message"

Christian Borntraeger <[email protected]>
s390/kvm: do not rely on the ILC on kvm host protection fauls

Max Filippov <[email protected]>
xtensa: don't use linux IRQ #0

Dave Young <[email protected]>
efi: Fix boot panic because of invalid BGRT image address

Richard <[email protected]>
partitions/msdos: FreeBSD UFS2 file systems are not recognized

Imre Deak <[email protected]>
drm/i915: Prevent the system suspend complete optimization

Imre Deak <[email protected]>
PCI/PM: Add needs_resume flag to avoid suspend complete optimization

Chris Wilson <[email protected]>
drm/i915: Do not drop pagetables when empty

-------------

Diffstat:

 Makefile                                           |  4 ++--
 arch/s390/kernel/entry.S                           | 19 +++++++++++-----
 arch/x86/platform/efi/efi-bgrt.c                   | 26 +++++++++++++++++++++-
 arch/xtensa/include/asm/irq.h                      |  3 ++-
 arch/xtensa/kernel/irq.c                           |  5 -----
 .../platforms/xtfpga/include/platform/hardware.h   |  6 +++--
 arch/xtensa/platforms/xtfpga/setup.c               | 10 ++++-----
 block/partitions/msdos.c                           |  2 ++
 drivers/gpu/drm/i915/i915_drv.c                    | 13 +++++++----
 drivers/gpu/drm/i915/i915_gem_gtt.c                | 13 ++---------
 drivers/gpu/drm/i915/i915_pci.c                    |  1 -
 drivers/gpu/drm/i915/intel_display.c               |  9 ++++++++
 drivers/gpu/drm/i915/intel_fbc.c                   | 19 ++++++----------
 drivers/gpu/drm/i915/intel_pm.c                    |  9 ++++++++
 drivers/gpu/drm/i915/intel_sprite.c                | 21 +++++++++++++++++
 drivers/irqchip/irq-xtensa-mx.c                    |  2 +-
 drivers/irqchip/irq-xtensa-pic.c                   |  2 +-
 drivers/pci/pci.c                                  |  3 ++-
 include/linux/pci.h                                |  5 +++++
 19 files changed, 119 insertions(+), 53 deletions(-)

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chris Wilson <[email protected]>

This is the minimal backport for stable of the upstream commit:

commit dd19674bacba227ae5d3ce680cbc5668198894dc

Author: Chris Wilson <[email protected]>
Date:   Wed Feb 15 08:43:46 2017 +0000

drm/i915: Remove bitmap tracking for used-ptes

Due to a race with the shrinker, when we try to allocate a pagetable, we may end up shrinking it instead. This comes as a nasty surprise as we try to dereference it to fill in the pagetable entries for the object.

In linus/master this is fixed by pinning the pagetables prior to allocation, but that backport is roughly

 drivers/gpu/drm/i915/i915_gem_gtt.c |   10 ----------
 1 file changed, 10 deletions(-)

i.e. unsuitable for stable. Instead we neuter the code that tried to free the pagetables.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99295

@@ -755,10 +755,6 @@ static bool gen8_ppgtt_clear_pt(struct i
 	GEM_BUG_ON(pte_end > GEN8_PTES);
 
 	bitmap_clear(pt->used_ptes, pte, num_entries);
-	if (USES_FULL_PPGTT(vm->i915)) {
-		if (bitmap_empty(pt->used_ptes, GEN8_PTES))
-			return true;
-	}
 
 	pt_vaddr = kmap_px(pt);
 

@@ -798,9 +794,6 @@ static bool gen8_ppgtt_clear_pd(struct i
 		}
 	}
 
-	if (bitmap_empty(pd->used_pdes, I915_PDES))
-		return true;
-
 	return false;
 }
 

@@ -829,9 +822,6 @@ static bool gen8_ppgtt_clear_pdp(struct
 
 	mark_tlbs_dirty(ppgtt);
 
-	if (bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv)))
-		return true;
-
 	return false;
 }
 

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Imre Deak <[email protected]>

commit 4d071c3238987325b9e50e33051a40d1cce311cc upstream.

Some drivers - like i915 - may not support the system suspend direct complete optimization due to differences in their runtime and system suspend sequence. Add a flag that when set resumes the device before calling the driver's system suspend handlers which effectively disables the optimization.

Needed by a future patch fixing suspend/resume on i915.

Suggested by Rafael.

(rebased on v4.8, added kernel version to commit message stable tag)

---
 drivers/pci/pci.c   |    3 ++-
 include/linux/pci.h |    5 +++++
 2 files changed, 7 insertions(+), 1 deletion(-)

@@ -2142,7 +2142,8 @@ bool pci_dev_keep_suspended(struct pci_d
 
 	if (!pm_runtime_suspended(dev)
 	    || pci_target_state(pci_dev) != pci_dev->current_state
-	    || platform_pci_need_resume(pci_dev))
+	    || platform_pci_need_resume(pci_dev)
+	    || (pci_dev->dev_flags & PCI_DEV_FLAGS_NEEDS_RESUME))
 		return false;
 
 	/*

@@ -178,6 +178,11 @@ enum pci_dev_flags {
 	PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
 	/* Get VPD from function 0 VPD */
 	PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
+	/*
+	 * Resume before calling the driver's system suspend hooks, disabling
+	 * the direct_complete optimization.
+	 */
+	PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11),
 };
 
 enum pci_irq_reroute_variant {

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard <[email protected]>

commit 223220356d5ebc05ead9a8d697abb0c0a906fc81 upstream.

The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions.

But for FreeBSD the subpartitions are always "bad".

Kernel: <bsd:bad subpartition - ignored

Though all 3 of these BSD systems use UFS as a file system, only FreeBSD uses relative start addresses in the subpartition declarations.

The following patch fixes this for FreeBSD partitions and leaves the code for OpenBSD and NetBSD intact:

---
 block/partitions/msdos.c |    2 ++
 1 file changed, 2 insertions(+)

@@ -300,6 +300,8 @@ static void parse_bsd(struct parsed_part
 			continue;
 		bsd_start = le32_to_cpu(p->p_offset);
 		bsd_size = le32_to_cpu(p->p_size);
+		if (memcmp(flavour, "bsd\0", 4) == 0)
+			bsd_start += offset;
 		if (offset == bsd_start && size == bsd_size)
 			/* full parent partition, we have it already */
 			continue;

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dave Young <[email protected]>

commit 792ef14df5c585c19b2831673a077504a09e5203 upstream.

Maniaxx reported a kernel boot crash in the EFI code, which I emulated by using same invalid phys addr in code:

  BUG: unable to handle kernel paging request at ffffffffff280001
  IP: efi_bgrt_init+0xfb/0x153
  ...
  Call Trace:
   ? bgrt_init+0xbc/0xbc
   acpi_parse_bgrt+0xe/0x12
   acpi_table_parse+0x89/0xb8
   acpi_boot_init+0x445/0x4e2
   ? acpi_parse_x2apic+0x79/0x79
   ? dmi_ignore_irq0_timer_override+0x33/0x33
   setup_arch+0xb63/0xc82
   ? early_idt_handler_array+0x120/0x120
   start_kernel+0xb7/0x443
   ? early_idt_handler_array+0x120/0x120
   x86_64_start_reservations+0x29/0x2b
   x86_64_start_kernel+0x154/0x177
   secondary_startup_64+0x9f/0x9f

There is also a similar bug filed in bugzilla.kernel.org:

https://bugzilla.kernel.org/show_bug.cgi?id=195633

The crash is caused by this commit:

7b0a911478c7 efi/x86: Move the EFI BGRT init code to early init code

The root cause is the firmware on those machines provides invalid BGRT image addresses.

In a kernel before above commit BGRT initializes late and uses ioremap() to map the image address. Ioremap validates the address, if it is not a valid physical address ioremap() just fails and returns. However in current kernel EFI BGRT initializes early and uses early_memremap() which does not validate the image address, and kernel panic happens.

According to ACPI spec the BGRT image address should fall into EFI_BOOT_SERVICES_DATA, see the section 5.2.22.4 of below document:

http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf

Fix this issue by validating the image address in efi_bgrt_init(). If the image address does not fall into any EFI_BOOT_SERVICES_DATA areas we just bail out with a warning message.

---
 arch/x86/platform/efi/efi-bgrt.c |   26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

@@ -27,6 +27,26 @@ struct bmp_header {
 	u32 size;
 } __packed;
 
+static bool efi_bgrt_addr_valid(u64 addr)
+{
+	efi_memory_desc_t *md;
+
+	for_each_efi_memory_desc(md) {
+		u64 size;
+		u64 end;
+
+		if (md->type != EFI_BOOT_SERVICES_DATA)
+			continue;
+
+		size = md->num_pages << EFI_PAGE_SHIFT;
+		end = md->phys_addr + size;
+		if (addr >= md->phys_addr && addr < end)
+			return true;
+	}
+
+	return false;
+}
+
 void __init efi_bgrt_init(struct acpi_table_header *table)
 {
 	void *image;

@@ -36,7 +56,7 @@ void __init efi_bgrt_init(struct acpi_ta
 	if (acpi_disabled)
 		return;
 
-	if (!efi_enabled(EFI_BOOT))
+	if (!efi_enabled(EFI_MEMMAP))
 		return;
 
 	if (table->length < sizeof(bgrt_tab)) {

@@ -65,6 +85,10 @@ void __init efi_bgrt_init(struct acpi_ta
 		goto out;
 	}
 
+	if (!efi_bgrt_addr_valid(bgrt->image_address)) {
+		pr_notice("Ignoring BGRT: invalid image address\n");
+		goto out;
+	}
 	image = early_memremap(bgrt->image_address, sizeof(bmp_header));
 	if (!image) {
 		pr_notice("Ignoring BGRT: failed to map image header memory\n");

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Max Filippov <[email protected]>

commit e5c86679d5e864947a52fb31e45a425dea3e7fa9 upstream.

Linux IRQ #0 is reserved for error reporting and may not be used. Increase NR_IRQS for one additional slot and increase irq_domain_add_legacy parameter first_irq value to 1, so that linux IRQ #0 is not associated with hardware IRQ #0 in legacy IRQ domains. Introduce macro XTENSA_PIC_LINUX_IRQ for static translation of xtensa PIC hardware IRQ # to linux IRQ #. Use this macro in XTFPGA platform data definitions.

This fixes inability to use hardware IRQ #0 in configurations that don't use device tree and allows for non-identity mapping between linux IRQ # and hardware IRQ #.

---
 arch/xtensa/include/asm/irq.h                            |    3 ++-
 arch/xtensa/kernel/irq.c                                 |    5 -----
 arch/xtensa/platforms/xtfpga/include/platform/hardware.h |    6 ++++--
 arch/xtensa/platforms/xtfpga/setup.c                     |   10 +++++-----
 drivers/irqchip/irq-xtensa-mx.c                          |    2 +-
 drivers/irqchip/irq-xtensa-pic.c                         |    2 +-
 6 files changed, 13 insertions(+), 15 deletions(-)

@@ -29,7 +29,8 @@ static inline void variant_irq_disable(u
 # define PLATFORM_NR_IRQS 0
 #endif
 #define XTENSA_NR_IRQS XCHAL_NUM_INTERRUPTS
-#define NR_IRQS (XTENSA_NR_IRQS + VARIANT_NR_IRQS + PLATFORM_NR_IRQS)
+#define NR_IRQS (XTENSA_NR_IRQS + VARIANT_NR_IRQS + PLATFORM_NR_IRQS + 1)
+#define XTENSA_PIC_LINUX_IRQ(hwirq) ((hwirq) + 1)
 
 #if VARIANT_NR_IRQS == 0
 static inline void variant_init_irq(void) { }

@@ -34,11 +34,6 @@ asmlinkage void do_IRQ(int hwirq, struct
 {
 	int irq = irq_find_mapping(NULL, hwirq);
 
-	if (hwirq >= NR_IRQS) {
-		printk(KERN_EMERG "%s: cannot handle IRQ %d\n",
-				__func__, hwirq);
-	}
-
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
 	/* Debugging check for stack overflow: is there less than 1KB free? */
 	{

@@ -24,16 +24,18 @@
 
 /* Interrupt configuration. */
 
-#define PLATFORM_NR_IRQS	10
+#define PLATFORM_NR_IRQS	0
 
 /* Default assignment of LX60 devices to external interrupts. */
 
 #ifdef CONFIG_XTENSA_MX
 #define DUART16552_INTNUM	XCHAL_EXTINT3_NUM
 #define OETH_IRQ		XCHAL_EXTINT4_NUM
+#define C67X00_IRQ		XCHAL_EXTINT8_NUM
 #else
 #define DUART16552_INTNUM	XCHAL_EXTINT0_NUM
 #define OETH_IRQ		XCHAL_EXTINT1_NUM
+#define C67X00_IRQ		XCHAL_EXTINT5_NUM
 #endif
 
 /*

@@ -63,5 +65,5 @@
 
 #define C67X00_PADDR		(XCHAL_KIO_PADDR + 0x0D0D0000)
 #define C67X00_SIZE		0x10
-#define C67X00_IRQ		5
+
 #endif /* __XTENSA_XTAVNET_HARDWARE_H */

@@ -175,8 +175,8 @@ static struct resource ethoc_res[] = {
 		.flags = IORESOURCE_MEM,
 	},
 	[2] = { /* IRQ number */
-		.start = OETH_IRQ,
-		.end   = OETH_IRQ,
+		.start = XTENSA_PIC_LINUX_IRQ(OETH_IRQ),
+		.end   = XTENSA_PIC_LINUX_IRQ(OETH_IRQ),
 		.flags = IORESOURCE_IRQ,
 	},
 };

@@ -213,8 +213,8 @@ static struct resource c67x00_res[] = {
 		.flags = IORESOURCE_MEM,
 	},
 	[1] = { /* IRQ number */
-		.start = C67X00_IRQ,
-		.end   = C67X00_IRQ,
+		.start = XTENSA_PIC_LINUX_IRQ(C67X00_IRQ),
+		.end   = XTENSA_PIC_LINUX_IRQ(C67X00_IRQ),
 		.flags = IORESOURCE_IRQ,
 	},
 };

@@ -247,7 +247,7 @@ static struct resource serial_resource =
 static struct plat_serial8250_port serial_platform_data[] = {
 	[0] = {
 		.mapbase	= DUART16552_PADDR,
-		.irq		= DUART16552_INTNUM,
+		.irq		= XTENSA_PIC_LINUX_IRQ(DUART16552_INTNUM),
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
 				  UPF_IOREMAP,
 		.iotype		= XCHAL_HAVE_BE ? UPIO_MEM32BE : UPIO_MEM32,

@@ -142,7 +142,7 @@ static struct irq_chip xtensa_mx_irq_chi
 int __init xtensa_mx_init_legacy(struct device_node *interrupt_parent)
 {
 	struct irq_domain *root_domain =
-		irq_domain_add_legacy(NULL, NR_IRQS, 0, 0,
+		irq_domain_add_legacy(NULL, NR_IRQS - 1, 1, 0,
 				&xtensa_mx_irq_domain_ops,
 				&xtensa_mx_irq_chip);
 	irq_set_default_host(root_domain);

@@ -89,7 +89,7 @@ static struct irq_chip xtensa_irq_chip =
 int __init xtensa_pic_init_legacy(struct device_node *interrupt_parent)
 {
 	struct irq_domain *root_domain =
-		irq_domain_add_legacy(NULL, NR_IRQS, 0, 0,
+		irq_domain_add_legacy(NULL, NR_IRQS - 1, 1, 0,
 				&xtensa_irq_domain_ops, &xtensa_irq_chip);
 	irq_set_default_host(root_domain);
 	return 0;

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christian Borntraeger <[email protected]>

commit c0e7bb38c07cbd8269549ee0a0566021a3c729de upstream.

For most cases a protection exception in the host (e.g. copy on write or dirty tracking) on the sie instruction will indicate an instruction length of 4. Turns out that there are some corner cases (e.g. runtime instrumentation) where this is not necessarily true and the ILC is unpredictable.

Let's replace our 4 byte rewind_pad with 3 byte nops to prepare for all possible ILCs.

---
 arch/s390/kernel/entry.S |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

@@ -233,12 +233,17 @@ ENTRY(sie64a)
 	lctlg	%c1,%c1,__LC_USER_ASCE		# load primary asce
 .Lsie_done:
 # some program checks are suppressing. C code (e.g. do_protection_exception)
-# will rewind the PSW by the ILC, which is 4 bytes in case of SIE. Other
-# instructions between sie64a and .Lsie_done should not cause program
-# interrupts. So lets use a nop (47 00 00 00) as a landing pad.
+# will rewind the PSW by the ILC, which is often 4 bytes in case of SIE. There
+# are some corner cases (e.g. runtime instrumentation) where ILC is unpredictable.
+# Other instructions between sie64a and .Lsie_done should not cause program
+# interrupts. So lets use 3 nops as a landing pad for all possible rewinds.
 # See also .Lcleanup_sie
-.Lrewind_pad:
-	nop	0
+.Lrewind_pad6:
+	nopr	7
+.Lrewind_pad4:
+	nopr	7
+.Lrewind_pad2:
+	nopr	7
 	.globl sie_exit
 sie_exit:
 	lg	%r14,__SF_EMPTY+8(%r15)		# load guest register save area

@@ -251,7 +256,9 @@ sie_exit:
 	stg	%r14,__SF_EMPTY+16(%r15)	# set exit reason code
 	j	sie_exit
 
-	EX_TABLE(.Lrewind_pad,.Lsie_fault)
+	EX_TABLE(.Lrewind_pad6,.Lsie_fault)
+	EX_TABLE(.Lrewind_pad4,.Lsie_fault)
+	EX_TABLE(.Lrewind_pad2,.Lsie_fault)
 	EX_TABLE(sie_exit,.Lsie_fault)
 EXPORT_SYMBOL(sie64a)
 EXPORT_SYMBOL(sie_exit)

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Vetter <[email protected]>

commit d38162e4b5c643733792f32be4ea107c831827b4 upstream.

This reverts commit bc5ca47c0af4f949ba889e666b7da65569e36093.

Gabriel put this back into generic code with

commit 75f6dfe3e652e1adef8cc1b073c89f3e22103a8f

Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Wed Dec 28 12:32:11 2016 -0200

drm: Deduplicate driver initialization message

but somehow he missed Chris' patch to add the message meanwhile.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101025

---
 drivers/gpu/drm/i915/i915_drv.c |    4 ----
 1 file changed, 4 deletions(-)

@@ -1252,10 +1252,6 @@ int i915_driver_load(struct pci_dev *pde
 
 	dev_priv->ipc_enabled = false;
 
-	/* Everything is in place, we can now relax! */
-	DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
-		 driver.name, driver.major, driver.minor, driver.patchlevel,
-		 driver.date, pci_name(pdev), dev_priv->drm.primary->index);
 	if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
 		DRM_INFO("DRM_I915_DEBUG enabled\n");
 	if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Maarten Lankhorst <[email protected]>

commit 4e3aed844547f63614363a386de126e6304e55fb upstream.

On some systems there can be a race condition in which no crtc state is added to the first atomic commit. This results in all crtc's having a null DDB allocation, causing a FIFO underrun on any update until the first modeset.

Changes since v1:
- Do not take the connection_mutex, this is already done below.

check time (v4)")

---
 drivers/gpu/drm/i915/intel_pm.c |    9 +++++++++
 1 file changed, 9 insertions(+)

@@ -4140,11 +4140,19 @@ skl_compute_wm(struct drm_atomic_state *
 	struct drm_crtc_state *cstate;
 	struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
 	struct skl_wm_values *results = &intel_state->wm_results;
+	struct drm_device *dev = state->dev;
 	struct skl_pipe_wm *pipe_wm;
 	bool changed = false;
 	int ret, i;
 
 	/*
+	 * When we distrust bios wm we always need to recompute to set the
+	 * expected DDB allocations for each CRTC.
+	 */
+	if (to_i915(dev)->wm.distrust_bios_wm)
+		changed = true;
+
+	/*
 	 * If this transaction isn't actually touching any CRTC's, don't
 	 * bother with watermark calculation.  Note that if we pass this
 	 * test, we're guaranteed to hold at least one CRTC state mutex,

@@ -4154,6 +4162,7 @@ skl_compute_wm(struct drm_atomic_state *
 	 */
 	for_each_crtc_in_state(state, crtc, cstate, i)
 		changed = true;
+
 	if (!changed)
 		return 0;
 

4.11-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kai Chen <[email protected]>

commit 4c4c565513cca1c53a12956640b5915727431631 upstream.

The decoupled MMIO feature doesn't work as intended by HW team. Enabling it with forcewake will only make debugging efforts more difficult, so let's disable it.

---
 drivers/gpu/drm/i915/i915_pci.c |    1 -
 1 file changed, 1 deletion(-)

@@ -389,7 +389,6 @@ static const struct intel_device_info in
 	.has_hw_contexts = 1, \
 	.has_logical_ring_contexts = 1, \
 	.has_guc = 1, \
-	.has_decoupled_mmio = 1, \
 	.has_aliasing_ppgtt = 1, \
 	.has_full_ppgtt = 1, \
 	.has_full_48bit_ppgtt = 1, \

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Great, thanks for testing all of these and letting me know.

greg k-h

Build results:

	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Wow, I didn't expect all of these to go that well :)

Thanks for testing them all and letting me know.

greg k-h