Linux ACPI
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5.6 regression fix 1/2] ACPI: PM: Add acpi_s2idle_register_wake_callback()
Date: Fri, 3 Apr 2020 12:27:42 +0200	[thread overview]
Message-ID: <70f2747e-43b9-f191-5884-6f0fc4e48fe6@redhat.com> (raw)
In-Reply-To: <4023796.rWsessMiv5@kreacher>

Hi,

On 4/1/20 9:09 PM, Rafael J. Wysocki wrote:
> On Wednesday, April 1, 2020 8:26:16 PM CEST Hans de Goede wrote:
>> Hi,
>>
>> On 4/1/20 6:32 PM, Rafael J. Wysocki wrote:
>>> On Mon, Mar 30, 2020 at 12:34 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Since commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from
>>>> waking up the system") the SCI triggering without there being a wakeup
>>>> cause recognized by the ACPI sleep code will no longer wakeup the system.
>>>>
>>>> This works as intended, but this is a problem for devices where the SCI
>>>> is shared with another device which is also a wakeup source.
>>>>
>>>> In the past these, from the pov of the ACPI sleep code, spurious SCIs
>>>> would still cause a wakeup so the wakeup from the device sharing the
>>>> interrupt would actually wakeup the system. This now no longer works.
>>>>
>>>> This is a problem on e.g. Bay Trail-T and Cherry Trail devices where
>>>> some peripherals (typically the XHCI controller) can signal a
>>>> Power Management Event (PME) to the Power Management Controller (PMC)
>>>> to wakeup the system, this uses the same interrupt as the SCI.
>>>> These wakeups are handled through a special INT0002 ACPI device which
>>>> checks for events in the GPE0a_STS for this and takes care of acking
>>>> the PME so that the shared interrupt stops triggering.
>>>>
>>>> The change to the ACPI sleep code to ignore the spurious SCI, causes
>>>> the system to no longer wakeup on these PME events. To make things
>>>> worse this means that the INT0002 device driver interrupt handler will
>>>> no longer run, causing the PME to not get cleared and resulting in the
>>>> system hanging. Trying to wakeup the system after such a PME through e.g.
>>>> the power button no longer works.
>>>>
>>>> Add an acpi_s2idle_register_wake_callback() function which registers
>>>> a callback to be called from acpi_s2idle_wake() and when the callback
>>>> returns true, return true from acpi_s2idle_wake().
>>>>
>>>> The INT0002 driver will use this mechanism to check the GPE0a_STS
>>>> register from acpi_s2idle_wake() and to tell the system to wakeup
>>>> if a PME is signaled in the register.
>>>>
>>>> Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
>>>> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>
>>> I generally agree with the approach, but I would make some, mostly
>>> cosmetic, changes.
>>>
>>> First off, I'd put the new code into drivers/acpi/wakeup.c.
>>>
>>> I'd export one function from there to be called from
>>> acpi_s2idle_wake() and the install/uninstall routines for the users.
>>
>> Ok.
>>
>>>> ---
>>>>    drivers/acpi/sleep.c | 70 ++++++++++++++++++++++++++++++++++++++++++++
>>>>    include/linux/acpi.h |  7 +++++
>>>>    2 files changed, 77 insertions(+)
>>>>
>>>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>>>> index e5f95922bc21..e360e51afa8e 100644
>>>> --- a/drivers/acpi/sleep.c
>>>> +++ b/drivers/acpi/sleep.c
>>>> @@ -943,6 +943,65 @@ static struct acpi_scan_handler lps0_handler = {
>>>>           .attach = lps0_device_attach,
>>>>    };
>>>>
>>>> +struct s2idle_wake_callback {
>>>
>>> I'd call this acpi_wakeup_handler.
>>>
>>>> +       struct list_head list;
>>>
>>> list_node?
>>>
>>>> +       bool (*function)(void *data);
>>>
>>> bool (*wakeup)(void *context)?
>>>
>>>> +       void *user_data;
>>>
>>> context?
>>
>> Sure (for all of the above).
>>
>>>
>>>> +};
>>>> +
>>>> +static LIST_HEAD(s2idle_wake_callback_head);
>>>> +static DEFINE_MUTEX(s2idle_wake_callback_mutex);
>>>> +
>>>> +/*
>>>> + * Drivers which may share an IRQ with the SCI can use this to register
>>>> + * a callback which returns true when the device they are managing wants
>>>> + * to trigger a wakeup.
>>>> + */
>>>> +int acpi_s2idle_register_wake_callback(
>>>> +       int wake_irq, bool (*function)(void *data), void *user_data)
>>>> +{
>>>> +       struct s2idle_wake_callback *callback;
>>>> +
>>>> +       /*
>>>> +        * If the device is not sharing its IRQ with the SCI, there is no
>>>> +        * need to register the callback.
>>>> +        */
>>>> +       if (!acpi_sci_irq_valid() || wake_irq != acpi_sci_irq)
>>>> +               return 0;
>>>> +
>>>> +       callback = kmalloc(sizeof(*callback), GFP_KERNEL);
>>>> +       if (!callback)
>>>> +               return -ENOMEM;
>>>> +
>>>> +       callback->function = function;
>>>> +       callback->user_data = user_data;
>>>> +
>>>> +       mutex_lock(&s2idle_wake_callback_mutex);
>>>> +       list_add(&callback->list, &s2idle_wake_callback_head);
>>>> +       mutex_unlock(&s2idle_wake_callback_mutex);
>>>> +
>>>> +       return 0;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(acpi_s2idle_register_wake_callback);
>>>> +
>>>> +void acpi_s2idle_unregister_wake_callback(
>>>> +       bool (*function)(void *data), void *user_data)
>>>> +{
>>>> +       struct s2idle_wake_callback *cb;
>>>> +
>>>> +       mutex_lock(&s2idle_wake_callback_mutex);
>>>> +       list_for_each_entry(cb, &s2idle_wake_callback_head, list) {
>>>> +               if (cb->function == function &&
>>>> +                   cb->user_data == user_data) {
>>>> +                       list_del(&cb->list);
>>>> +                       kfree(cb);
>>>> +                       break;
>>>> +               }
>>>> +       }
>>>> +       mutex_unlock(&s2idle_wake_callback_mutex);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(acpi_s2idle_unregister_wake_callback);
>>>> +
>>>>    static int acpi_s2idle_begin(void)
>>>>    {
>>>>           acpi_scan_lock_acquire();
>>>> @@ -992,6 +1051,8 @@ static void acpi_s2idle_sync(void)
>>>>
>>>>    static bool acpi_s2idle_wake(void)
>>>>    {
>>>> +       struct s2idle_wake_callback *cb;
>>>> +
>>>>           if (!acpi_sci_irq_valid())
>>>>                   return pm_wakeup_pending();
>>>>
>>>> @@ -1025,6 +1086,15 @@ static bool acpi_s2idle_wake(void)
>>>>                   if (acpi_any_gpe_status_set() && !acpi_ec_dispatch_gpe())
>>>>                           return true;
>>>>
>>>> +               /*
>>>> +                * Check callbacks registered by drivers sharing the SCI.
>>>> +                * Note no need to lock, nothing else is running.
>>>> +                */
>>>> +               list_for_each_entry(cb, &s2idle_wake_callback_head, list) {
>>>> +                       if (cb->function(cb->user_data))
>>>> +                               return true;
>>>> +               }
>>>
>>> AFAICS this needs to be done in acpi_s2idle_restore() too to clear the
>>> status bits in case one of these wakeup sources triggers along with a
>>> GPE or a fixed event and the other one wins the race.
>>
>> The "wakeup" callback does not actually clear the interrupt source, just like
>> for normal interrupts it relies on the actual interrupt handling (which at this
>> point is still suspended) to do this.
> 
> Of course, you are right, sorry for the confusion.
> 
> What I meant was that the interrupt handler needed to run in acpi_s2idle_restore(),
> but that should be taken care of the acpi_os_wait_events_complete() in there
> which synchronizes the SCI among other things.

Ok, I've prepared a v2 with the other discussed changes. I'll give it a
quick test and then send it out.

Regards,

Hans


  reply	other threads:[~2020-04-03 10:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-29 22:34 [PATCH 5.6 regression fix 0/2] ACPI: PM: s2idle: Fix some systems no longer waking up from suspend Hans de Goede
2020-03-29 22:34 ` [PATCH 5.6 regression fix 1/2] ACPI: PM: Add acpi_s2idle_register_wake_callback() Hans de Goede
2020-04-01 16:32   ` Rafael J. Wysocki
2020-04-01 18:26     ` Hans de Goede
2020-04-01 19:09       ` Rafael J. Wysocki
2020-04-03 10:27         ` Hans de Goede [this message]
2020-03-29 22:34 ` [PATCH 5.6 regression fix 2/2] platform/x86: intel_int0002_vgpio: Use acpi_s2idle_register_wake_callback Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70f2747e-43b9-f191-5884-6f0fc4e48fe6@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox