linux-stable.git/drivers/acpi, branch v5.7.4

ACPI: PM: Avoid using power resources if there are none for D0

2020-06-17T14:42:53+00:00

commit 956ad9d98b73f59e442cc119c98ba1e04e94fe6d upstream.

As recently reported, some platforms provide a list of power
resources for device power state D3hot, through the _PR3 object,
but they do not provide a list of power resources for device power
state D0.

Among other things, this causes acpi_device_get_power() to return
D3hot as the current state of the device in question if all of the
D3hot power resources are "on", because it sees the power_resources
flag set and calls acpi_power_get_inferred_state() which finds that
D3hot is the shallowest power state with all of the associated power
resources turned "on", so that's what it returns.  Moreover, that
value takes precedence over the acpi_dev_pm_explicit_get() return
value, because it means a deeper power state.  The device may very
well be in D0 physically at that point, however.

Moreover, the presence of _PR3 without _PR0 for a given device
means that only one D3-level power state can be supported by it.
Namely, because there are no power resources to turn "off" when
transitioning the device from D0 into D3cold (which should be
supported since _PR3 is present), the evaluation of _PS3 should
be sufficient to put it straight into D3cold, but this means that
the effect of turning "on" the _PR3 power resources is unclear,
so it is better to avoid doing that altogether.  Consequently,
there is no practical way do distinguish D3cold from D3hot for
the device in question and the power states of it can be labeled
so that D3hot is the deepest supported one (and Linux assumes
that putting a device into D3hot via ACPI may cause power to be
removed from it anyway, for legacy reasons).

To work around the problem described above modify the ACPI
enumeration of devices so that power resources are only used
for device power management if the list of D0 power resources
is not empty and make it mart D3cold as supported only if that
is the case and the D3hot list of power resources is not empty
too.

Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057
Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/
Reported-by: Hans de Goede 
Tested-by: Hans de Goede 
Tested-by: youling257@gmail.com
Cc: 3.10+  # 3.10+
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

ACPI: GED: add support for _Exx / _Lxx handler methods

2020-06-17T14:42:53+00:00

commit ea6f3af4c5e63f6981c0b0ab8ebec438e2d5ef40 upstream.

Per the ACPI spec, interrupts in the range [0, 255] may be handled
in AML using individual methods whose naming is based on the format
_Exx or _Lxx, where xx is the hex representation of the interrupt
index.

Add support for this missing feature to our ACPI GED driver.

Cc: v4.9+  # v4.9+
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe()

2020-06-17T14:42:53+00:00

commit 4d8be4bc94f74bb7d096e1c2e44457b530d5a170 upstream.

kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object. Previous
commit "b8eb718348b8" fixed a similar problem.

Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance")
Signed-off-by: Qiushi Wu 
Cc: 4.10+  # 4.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: sysfs: Fix reference count leak in acpi_sysfs_add_hotplug_profile()

2020-06-17T14:42:53+00:00

commit 6e6c25283dff866308c87b49434c7dbad4774cc0 upstream.

kobject_init_and_add() takes reference even when it fails.
Thus, when kobject_init_and_add() returns an error,
kobject_put() must be called to properly clean up the kobject.

Fixes: 3f8055c35836 ("ACPI / hotplug: Introduce user space interface for hotplug profiles")
Signed-off-by: Qiushi Wu 
Cc: 3.10+  # 3.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive

2020-05-18T11:15:13+00:00

Flushing the EC work while suspended to idle when the EC GPE status
is not set causes some EC wakeup events (notably power button and
lid ones) to be missed after a series of spurious wakeups on the Dell
XPS13 9360 in my office.

If that happens, the machine cannot be woken up from suspend-to-idle
by the power button or lid status change and it needs to be woken up
in some other way (eg. by a key press).

Flushing the EC work only after successful dispatching the EC GPE,
which means that its status has been set, avoids the issue, so change
the code in question accordingly.

Fixes: 7b301750f7f8 ("ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()")
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Tested-by: Chris Chiu

ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()

2020-05-11T08:11:38+00:00

If the EC GPE status is not set after checking all of the other GPEs,
acpi_s2idle_wake() returns 'false', to indicate that the SCI event
that has just triggered is not a system wakeup one, but it does that
without canceling the pending wakeup and re-arming the SCI for system
wakeup which is a mistake, because it may cause s2idle_loop() to busy
spin until the next valid wakeup event.  [If that happens, the first
spurious wakeup is still pending after acpi_s2idle_wake() has
returned, so s2idle_enter() does nothing, acpi_s2idle_wake()
is called again and it sees that the SCI has triggered, but no GPEs
are active, so 'false' is returned again, and so on.]

Fix that by moving all of the GPE checking logic from
acpi_s2idle_wake() to acpi_ec_dispatch_gpe() and making the
latter return 'true' only if a non-EC GPE has triggered and
'false' otherwise, which will cause acpi_s2idle_wake() to
cancel the pending SCI wakeup and re-arm the SCI for system
wakeup regardless of the EC GPE status.

This also addresses a lockup observed on an Elitegroup EF20EA laptop
after attempting to wake it up from suspend-to-idle by a key press.

Fixes: d5406284ff80 ("ACPI: PM: s2idle: Refine active GPEs check")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=207603
Reported-by: Todd Brandt 
Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
Link: https://lore.kernel.org/linux-acpi/CAB4CAwdqo7=MvyG_PE+PGVfeA17AHF5i5JucgaKqqMX6mjArbQ@mail.gmail.com/
Reported-by: Chris Chiu 
Tested-by: Chris Chiu 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki

PM: ACPI: Output correct message on target power state

2020-04-27T08:33:40+00:00

Transitioned power state logged at the end of setting ACPI power.

However, D3cold won't be in the message because state can only be
D3hot at most.

Use target_state to corretly report when power state is D3cold.

Cc: All applicable 
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Rafael J. Wysocki

Merge branch 'acpi-pci'

2020-04-24T19:03:57+00:00

* acpi-pci:
  ACPI/PCI: pci_link: use extended_irq union member when setting ext-irq shareable

ACPI: button: Drop no longer necessary Asus T200TA lid_init_state quirk

2020-04-20T08:37:15+00:00

Commit 17e5888e4e18 ("x86: Select HARDIRQS_SW_RESEND on x86") fixes
the edge-triggered embedded-controller (WC) IRQ not being replayed after
resume when woken by opening the lid, which gets signaled by the EC.

This means that the lid_init_state=ACPI_BUTTON_LID_INIT_OPEN quirk for
the Asus T200TA is no longer necessary, the lid now works properly
without it, so drop the quirk.

Fixes: 17e5888e4e18 ("x86: Select HARDIRQS_SW_RESEND on x86")
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki

ACPI/PCI: pci_link: use extended_irq union member when setting ext-irq shareable

2020-04-20T08:36:22+00:00

The case ACPI_RESOURCE_TYPE_EXTENDED_IRQ inside acpi_pci_link_set()
is correctly using resource->res.data.extended_irq.foo for most settings,
but for the shareable setting it so far has accidentally been using
resource->res.data.irq.shareable instead of
resource->res.data.extended_irq.shareable.

Note that the old code happens to also work because the shareable field
offset is the same for both the acpi_resource_irq and
acpi_resource_extended_irq structs.

Acked-by: Bjorn Helgaas 
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki