On Wednesday, December 12, 2018 2:15:55 PM CET Andy Shevchenko wrote: > On Wed, Dec 12, 2018 at 02:04:32PM +0100, Rafael J. Wysocki wrote: > > On Sun, Dec 9, 2018 at 3:12 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > On 09-12-18 06:55, Andy Shevchenko wrote: > > > > On Sat, Dec 08, 2018 at 01:59:24PM +0100, Hans de Goede wrote: > > > >> Ignore acpi_device_fix_up_power() return value. If we return an error > > > >> we end up with acpi_default_enumeration() still creating a platform- > > > >> device for the device and we end up with the device still being used > > > >> but without the special LPSS related handling which is not useful. > > > >> > > > >> Specicifically ignoring the error fixes the touchscreen no longer > > > >> working after a suspend/resume on a Prowise PT301 tablet. > > > > > > > > Hmm... Sounds like a hammer for a rather rare cases. > > > > Wouldn't be better to have DMI based matching quirk then do it for everyone? > > > > > > As I tried to explain in the commit message making acpi_lpss_create_device() > > > fail and thus failing the acpi_scan_handler lpss_handler.attach method does > > > not really gain us anything. This will make drivers/acpi/scan.c fall back > > > to the acpi_default_enumeration() function, calling acpi_create_platform_device() > > > so a platform_device will still be created, the driver for the LPSS function > > > will still bind to it, etc. Also at this point we have already called > > > dev_desc->setup(), registered the clock-device, etc. None of which we undo. > > > > > > All causing acpi_lpss_create_device() to fail does is remove the special handling > > > on suspend/resume mainly skipping acpi_lpss_save/restore_ctx, which really > > > does not gain us anything. > > > > > > So my reason for taking the big hammer approach here is that exiting with > > > an error at this point really is not helpful. > > > > This sounds fair enough for me. Andy, do you agree? > > Yes. Patch applied, then. Thanks!
