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. -- With Best Regards, Andy Shevchenko
