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?
