Messages in this thread |  | | Subject | Re: [PATCH] x86/irq: Do not touch IRQ chip_data if it does not belong to x86_vector_domain | From | Sakari Ailus <> | Date | Mon, 3 Oct 2016 16:37:20 +0300 |
| |
Hi Mika,
On 10/03/16 13:17, Mika Westerberg wrote: > When a CPU is about to be offlined we call fixup_irqs() that resets IRQ > affinities related to the CPU in question. The same thing is also done when > the system is suspended to S-states like S3 (mem). > > For each IRQ we try to complete any on-going move regardless whether the > IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch > its chip_data, assume it is of type struct apic_chip_data and manipulate it > by clearing old_domain mask etc. For irq_chips that are not part of the > x86_vector_domain, like those created by various GPIO drivers, will find > their chip_data being changed unexpectly. > > Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets > corrupted after resume: > > # cat /sys/kernel/debug/gpio > gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: > gpio-511 ( |sysfs ) in hi > > # rtcwake -s10 -mmem > <10 seconds passes> > > # cat /sys/kernel/debug/gpio > gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: > gpio-511 ( |sysfs ) in ? > > Note '?' in the output. It means the struct gpio_chip ->get function is > NULL whereas before suspend it was there. > > Fix this by first checking that the IRQ belongs to x86_vector_domain before > we try to use the chip_data as struct apic_chip_data. > > Reported-by: Sakari Ailus <sakari.ailus@linux.intel.com> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Thanks for debugging this! I've tested it on the laptop where the SD card is no longer detected after suspend; with this patch it works fine.
Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
-- Sakari Ailus sakari.ailus@linux.intel.com
|  |