From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752973AbcEXDsw (ORCPT ); Mon, 23 May 2016 23:48:52 -0400 Received: from mail-lb0-f194.google.com ([209.85.217.194]:35916 "EHLO mail-lb0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752179AbcEXDsu (ORCPT ); Mon, 23 May 2016 23:48:50 -0400 Subject: Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended To: Gabriele Mazzotta , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Darren Hart References: <1457740175-8327-1-git-send-email-gabriele.mzt@gmail.com> <201605240006.03580@pali> <20160523221715.GE2735@f23x64.localdomain> <201605240022.28140@pali> <1d56338e-6312-371d-ace7-96f762e18bba@gmail.com> Cc: "Rafael J. Wysocki" , "D. Jared Dominguez" , "platform-driver-x86@vger.kernel.org" , Alex Hung , "linux-kernel@vger.kernel.org" From: Andrei Borzenkov Message-ID: <5743CF19.8050404@gmail.com> Date: Tue, 24 May 2016 06:48:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1d56338e-6312-371d-ace7-96f762e18bba@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 24.05.2016 02:03, Gabriele Mazzotta пишет: > On 24/05/2016 00:22, Pali Rohár wrote: >> On Tuesday 24 May 2016 00:17:15 Darren Hart wrote: >>> On Tue, May 24, 2016 at 12:06:03AM +0200, Pali Rohár wrote: >>>> On Monday 23 May 2016 23:26:55 Darren Hart wrote: >>>>> I've queued this. Thanks for your patience. >>>> >>>> Ok, In that case I would update comments in patch to try it more >>>> clear what code is doing. >>> >>> I thought I had your approval on this one Pali. Apologies if that was >>> not the case. Did I miss a change request from you? >>> >>> If so, please point me at it, and I'll dequeue this one and wait for >>> an updated one. >> >> I just wanted to review that code from somebody else and decide if >> accept it or not. Because I was not sure if it is OK... >> >> But there was no objection, so patch is OK. >> >> And I pointed that patch could have better comments to describe what it >> is doing as at first time I was confused. >> >> So I believe that you can update patch in your queue with new version >> which just change comments in source code (without functional changes). >> > > Something such as the following? > Feel free to reword the comments if you have something better in mind. > > --- > drivers/platform/x86/dell-rbtn.c | 56 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 56 insertions(+) > > diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c > index 331d63c..e0208ba 100644 > --- a/drivers/platform/x86/dell-rbtn.c > +++ b/drivers/platform/x86/dell-rbtn.c > @@ -28,6 +28,7 @@ struct rbtn_data { > enum rbtn_type type; > struct rfkill *rfkill; > struct input_dev *input_dev; > + bool suspended; > }; > > > @@ -235,9 +236,55 @@ static const struct acpi_device_id rbtn_ids[] = { > { "", 0 }, > }; > > +#ifdef CONFIG_PM_SLEEP > +static void ACPI_SYSTEM_XFACE rbtn_acpi_clear_flag(void *context) > +{ > + struct rbtn_data *rbtn_data = context; > + > + rbtn_data->suspended = false; > +} > + > +static int rbtn_suspend(struct device *dev) > +{ > + struct acpi_device *device = to_acpi_device(dev); > + struct rbtn_data *rbtn_data = acpi_driver_data(device); > + > + rbtn_data->suspended = true; > + > + return 0; > +} > + > +static int rbtn_resume(struct device *dev) > +{ > + struct acpi_device *device = to_acpi_device(dev); > + struct rbtn_data *rbtn_data = acpi_driver_data(device); > + acpi_status status; > + > + /* > + * Upon resume, some BIOSes autonomously send an ACPI notification > + * that triggers an unwanted input event. In order to ignore it, > + * we use a flag that we set at suspend and clear once we have > + * received the extra notification. Since ACPI notifications are > + * delivered asynchronously to drivers, we clear the flag from the > + * workqueue used to deliver the notifications. This should be enough > + * to guarantee that the flag is cleared only after we received the > + * extra notification, if any. > + */ "guarantee" is rather strong word here. We really do not know anything how and when these notifications are generated by firmware, so can only hope. But otherwise this explains what this patch intends to do (so that even me finally understood it :) > + status = acpi_os_execute(OSL_NOTIFY_HANDLER, > + rbtn_acpi_clear_flag, rbtn_data); > + if (ACPI_FAILURE(status)) > + rbtn_data->suspended = false; > + > + return 0; > +} > +#endif > + > +static SIMPLE_DEV_PM_OPS(rbtn_pm_ops, rbtn_suspend, rbtn_resume); > + > static struct acpi_driver rbtn_driver = { > .name = "dell-rbtn", > .ids = rbtn_ids, > + .drv.pm = &rbtn_pm_ops, > .ops = { > .add = rbtn_add, > .remove = rbtn_remove, > @@ -399,6 +446,15 @@ static void rbtn_notify(struct acpi_device *device, u32 event) > { > struct rbtn_data *rbtn_data = device->driver_data; > > + /* > + * Some BIOSes send autonomously a notification at resume. > + * Ignore it to prevent unwanted input events. > + */ > + if (rbtn_data->suspended) { > + dev_dbg(&device->dev, "ACPI notification ignored\n"); > + return; > + } > + > if (event != 0x80) { > dev_info(&device->dev, "Received unknown event (0x%x)\n", > event); > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrei Borzenkov Subject: Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended Date: Tue, 24 May 2016 06:48:41 +0300 Message-ID: <5743CF19.8050404@gmail.com> References: <1457740175-8327-1-git-send-email-gabriele.mzt@gmail.com> <201605240006.03580@pali> <20160523221715.GE2735@f23x64.localdomain> <201605240022.28140@pali> <1d56338e-6312-371d-ace7-96f762e18bba@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-lb0-f194.google.com ([209.85.217.194]:35916 "EHLO mail-lb0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752179AbcEXDsu (ORCPT ); Mon, 23 May 2016 23:48:50 -0400 In-Reply-To: <1d56338e-6312-371d-ace7-96f762e18bba@gmail.com> Sender: platform-driver-x86-owner@vger.kernel.org List-ID: To: Gabriele Mazzotta , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Darren Hart Cc: "Rafael J. Wysocki" , "D. Jared Dominguez" , "platform-driver-x86@vger.kernel.org" , Alex Hung , "linux-kernel@vger.kernel.org" 24.05.2016 02:03, Gabriele Mazzotta =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 24/05/2016 00:22, Pali Roh=C3=A1r wrote: >> On Tuesday 24 May 2016 00:17:15 Darren Hart wrote: >>> On Tue, May 24, 2016 at 12:06:03AM +0200, Pali Roh=C3=A1r wrote: >>>> On Monday 23 May 2016 23:26:55 Darren Hart wrote: >>>>> I've queued this. Thanks for your patience. >>>> >>>> Ok, In that case I would update comments in patch to try it more >>>> clear what code is doing. >>> >>> I thought I had your approval on this one Pali. Apologies if that w= as >>> not the case. Did I miss a change request from you? >>> >>> If so, please point me at it, and I'll dequeue this one and wait fo= r >>> an updated one. >> >> I just wanted to review that code from somebody else and decide if=20 >> accept it or not. Because I was not sure if it is OK... >> >> But there was no objection, so patch is OK. >> >> And I pointed that patch could have better comments to describe what= it=20 >> is doing as at first time I was confused. >> >> So I believe that you can update patch in your queue with new versio= n=20 >> which just change comments in source code (without functional change= s). >> >=20 > Something such as the following? > Feel free to reword the comments if you have something better in mind= =2E >=20 > --- > drivers/platform/x86/dell-rbtn.c | 56 ++++++++++++++++++++++++++++++= ++++++++++ > 1 file changed, 56 insertions(+) >=20 > diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/= dell-rbtn.c > index 331d63c..e0208ba 100644 > --- a/drivers/platform/x86/dell-rbtn.c > +++ b/drivers/platform/x86/dell-rbtn.c > @@ -28,6 +28,7 @@ struct rbtn_data { > enum rbtn_type type; > struct rfkill *rfkill; > struct input_dev *input_dev; > + bool suspended; > }; > =20 > =20 > @@ -235,9 +236,55 @@ static const struct acpi_device_id rbtn_ids[] =3D= { > { "", 0 }, > }; > =20 > +#ifdef CONFIG_PM_SLEEP > +static void ACPI_SYSTEM_XFACE rbtn_acpi_clear_flag(void *context) > +{ > + struct rbtn_data *rbtn_data =3D context; > + > + rbtn_data->suspended =3D false; > +} > + > +static int rbtn_suspend(struct device *dev) > +{ > + struct acpi_device *device =3D to_acpi_device(dev); > + struct rbtn_data *rbtn_data =3D acpi_driver_data(device); > + > + rbtn_data->suspended =3D true; > + > + return 0; > +} > + > +static int rbtn_resume(struct device *dev) > +{ > + struct acpi_device *device =3D to_acpi_device(dev); > + struct rbtn_data *rbtn_data =3D acpi_driver_data(device); > + acpi_status status; > + > + /* > + * Upon resume, some BIOSes autonomously send an ACPI notification > + * that triggers an unwanted input event. In order to ignore it, > + * we use a flag that we set at suspend and clear once we have > + * received the extra notification. Since ACPI notifications are > + * delivered asynchronously to drivers, we clear the flag from the > + * workqueue used to deliver the notifications. This should be enou= gh > + * to guarantee that the flag is cleared only after we received the > + * extra notification, if any. > + */ "guarantee" is rather strong word here. We really do not know anything how and when these notifications are generated by firmware, so can only hope. But otherwise this explains what this patch intends to do (so tha= t even me finally understood it :) > + status =3D acpi_os_execute(OSL_NOTIFY_HANDLER, > + rbtn_acpi_clear_flag, rbtn_data); > + if (ACPI_FAILURE(status)) > + rbtn_data->suspended =3D false; > + > + return 0; > +} > +#endif > + > +static SIMPLE_DEV_PM_OPS(rbtn_pm_ops, rbtn_suspend, rbtn_resume); > + > static struct acpi_driver rbtn_driver =3D { > .name =3D "dell-rbtn", > .ids =3D rbtn_ids, > + .drv.pm =3D &rbtn_pm_ops, > .ops =3D { > .add =3D rbtn_add, > .remove =3D rbtn_remove, > @@ -399,6 +446,15 @@ static void rbtn_notify(struct acpi_device *devi= ce, u32 event) > { > struct rbtn_data *rbtn_data =3D device->driver_data; > =20 > + /* > + * Some BIOSes send autonomously a notification at resume. > + * Ignore it to prevent unwanted input events. > + */ > + if (rbtn_data->suspended) { > + dev_dbg(&device->dev, "ACPI notification ignored\n"); > + return; > + } > + > if (event !=3D 0x80) { > dev_info(&device->dev, "Received unknown event (0x%x)\n", > event); >=20