From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752466AbcEXHJo (ORCPT ); Tue, 24 May 2016 03:09:44 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36167 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751954AbcEXHJm (ORCPT ); Tue, 24 May 2016 03:09:42 -0400 Date: Tue, 24 May 2016 09:09:38 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Andrei Borzenkov Cc: Gabriele Mazzotta , Darren Hart , "Rafael J. Wysocki" , "D. Jared Dominguez" , "platform-driver-x86@vger.kernel.org" , Alex Hung , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended Message-ID: <20160524070938.GG29844@pali> 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> <5743CF19.8050404@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5743CF19.8050404@gmail.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 24 May 2016 06:48:41 Andrei Borzenkov wrote: > 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) I would rename this function to rbtn_clear_suspended_flag. > > +{ > > + 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 :) Yes, thats better. > > + status = acpi_os_execute(OSL_NOTIFY_HANDLER, > > + rbtn_acpi_clear_flag, rbtn_data); > > + if (ACPI_FAILURE(status)) > > + rbtn_data->suspended = false; And here rbtn_clear_suspended_flag(rbtn_data) call instead direct assignment. > > + > > + 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); > > > -- Pali Rohár pali.rohar@gmail.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pali =?utf-8?B?Um9ow6Fy?= Subject: Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended Date: Tue, 24 May 2016 09:09:38 +0200 Message-ID: <20160524070938.GG29844@pali> 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> <5743CF19.8050404@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-wm0-f68.google.com ([74.125.82.68]:36167 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751954AbcEXHJm (ORCPT ); Tue, 24 May 2016 03:09:42 -0400 Content-Disposition: inline In-Reply-To: <5743CF19.8050404@gmail.com> Sender: platform-driver-x86-owner@vger.kernel.org List-ID: To: Andrei Borzenkov Cc: Gabriele Mazzotta , Darren Hart , "Rafael J. Wysocki" , "D. Jared Dominguez" , "platform-driver-x86@vger.kernel.org" , Alex Hung , "linux-kernel@vger.kernel.org" On Tuesday 24 May 2016 06:48:41 Andrei Borzenkov wrote: > 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= 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= =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 wh= at it=20 > >> is doing as at first time I was confused. > >> > >> So I believe that you can update patch in your queue with new vers= ion=20 > >> which just change comments in source code (without functional chan= ges). > >> > >=20 > > Something such as the following? > > Feel free to reword the comments if you have something better in mi= nd. > >=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/x8= 6/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) I would rename this function to rbtn_clear_suspended_flag. > > +{ > > + 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 notificatio= n > > + * 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 th= e > > + * workqueue used to deliver the notifications. This should be en= ough > > + * to guarantee that the flag is cleared only after we received t= he > > + * extra notification, if any. > > + */ >=20 > "guarantee" is rather strong word here. We really do not know anythin= g > how and when these notifications are generated by firmware, so can on= ly > hope. But otherwise this explains what this patch intends to do (so t= hat > even me finally understood it :) Yes, thats better. > > + status =3D acpi_os_execute(OSL_NOTIFY_HANDLER, > > + rbtn_acpi_clear_flag, rbtn_data); > > + if (ACPI_FAILURE(status)) > > + rbtn_data->suspended =3D false; And here rbtn_clear_suspended_flag(rbtn_data) call instead direct assignment. > > + > > + 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 *de= vice, 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 >=20 --=20 Pali Roh=C3=A1r pali.rohar@gmail.com