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 <[email protected]> > Signed-off-by: Mika Westerberg <[email protected]>
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 <[email protected]> -- Sakari Ailus [email protected]
