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.
Regards,
Hans
This tablet has a broken _PS0 method on the touchscreen's I2C controller,
causing acpi_device_fix_up_power() to fail, causing fallback to standard
platform-dev handling and specifically causing acpi_lpss_save/restore_ctx
to not run.
The I2C controllers _PS0 method does actually turn on the device, but then
does some more nonsense which fails when run during early boot trying to
use I2C opregion handling on another not-yet registered I2C controller.
