linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: "Zheng, Lv" <lv.zheng@intel.com>
Cc: "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"Brown, Len" <len.brown@intel.com>, Lv Zheng <zetalog@gmail.com>,
	Peter Hutterer <peter.hutterer@who-t.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"systemd-devel@lists.freedesktop.org"
	<systemd-devel@lists.freedesktop.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
Date: Tue, 6 Jun 2017 12:29:08 +0200	[thread overview]
Message-ID: <20170606102908.GB14880@mail.corp.redhat.com> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E886CEC510A@SHSMSX101.ccr.corp.intel.com>

On Jun 05 2017 or thereabouts, Zheng, Lv wrote:
> Hi,
> 
> > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
> > Subject: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
> > 
> > From: Lv Zheng <lv.zheng@intel.com>
> > 
> > acpi/button.c now contains the logic to avoid frequently replayed events
> > which originally was ensured by using blocking notifier.
> > On the contrary, using a blocking notifier is wrong as it could keep on
> > returning NOTIFY_DONE, causing events lost.
> > 
> > This patch thus changes lid notification to raw notifier in order not to
> > have any events lost.
> 
> This patch is on top of the following:
> https://patchwork.kernel.org/patch/9756467/
> where button driver implements a frequency check and
> thus is capable of filtering redundant events itself:
> I saw you have deleted it from PATCH 02.
> So this patch is not applicable now.

I actually rebased it in this series. I kept your SoB line given that
the idea came from you and the resulting patch was rather similar (only
one hunk differs, but the meaning is the same).

> 
> Is input layer capable of filtering redundant events.

I don't think it does, and it should not. If an event is emitted, it has
to be forwarded. However, the logic of the protocol makes that the only
state that matters is when an EV_SYN is emitted. So if a SW_LID 0 then 1
is sent between the 2 EV_SYN, and the state was 1 before, from a
protocol point of view it's a no-op.

> I saw you unconditionally prepend "open" before "close",
> which may make input layer incapable of filtering redundant close events.

Again, we don't care about events. We care about states, and those are
only emitted when the lid is marked as non reliable.

> 
> If input layer is capable of filtering redundant events,
> why don't you:
> 1. drop this commit;
> 2. remove all ACPI lid notifier APIs;
> 3. change lid notifier callers to register notification via input layer?

Having the i915 driver listening to the input events is actually a good
solution. Let me think about it a little bit more and I'll come back.

Cheers,
Benjamin

> 
> Thanks and best regards
> Lv 
> 
> > 
> > Signed-off-by: Lv Zheng <lv.zheng@intel.com>
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > ---
> >  drivers/acpi/button.c | 68 ++++++++++++++++++++-------------------------------
> >  1 file changed, 27 insertions(+), 41 deletions(-)
> > 
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index 03e5981..1927b08 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -114,7 +114,7 @@ struct acpi_button {
> > 
> >  static DEFINE_MUTEX(button_input_lock);
> > 
> > -static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
> > +static RAW_NOTIFIER_HEAD(acpi_lid_notifier);
> >  static struct acpi_device *lid_device;
> >  static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
> > 
> > @@ -179,14 +179,12 @@ static int acpi_lid_evaluate_state(struct acpi_device *device)
> >  	return lid_state ? 1 : 0;
> >  }
> > 
> > -static int acpi_lid_notify_state(struct acpi_device *device, int state)
> > +static void acpi_lid_notify_state(struct acpi_device *device, int state)
> >  {
> >  	struct acpi_button *button = acpi_driver_data(device);
> > 
> > -	/* button_input_lock must be held */
> > -
> >  	if (!button->input)
> > -		return 0;
> > +		return;
> > 
> >  	/*
> >  	 * If the lid is unreliable, always send an "open" event before any
> > @@ -201,8 +199,6 @@ static int acpi_lid_notify_state(struct acpi_device *device, int state)
> > 
> >  	if (state)
> >  		pm_wakeup_hard_event(&device->dev);
> > -
> > -	return 0;
> >  }
> > 
> >  /*
> > @@ -214,28 +210,14 @@ static void acpi_button_lid_events(struct input_handle *handle,
> >  {
> >  	const struct input_value *v;
> >  	int state = -1;
> > -	int ret;
> > 
> >  	for (v = vals; v != vals + count; v++) {
> >  		switch (v->type) {
> >  		case EV_SYN:
> > -			if (v->code == SYN_REPORT && state >= 0) {
> > -				ret = blocking_notifier_call_chain(&acpi_lid_notifier,
> > +			if (v->code == SYN_REPORT && state >= 0)
> > +				(void)raw_notifier_call_chain(&acpi_lid_notifier,
> >  								state,
> >  								lid_device);
> > -				if (ret == NOTIFY_DONE)
> > -					ret = blocking_notifier_call_chain(&acpi_lid_notifier,
> > -								state,
> > -								lid_device);
> > -				if (ret == NOTIFY_DONE || ret == NOTIFY_OK) {
> > -					/*
> > -					 * It is also regarded as success if
> > -					 * the notifier_chain returns NOTIFY_OK
> > -					 * or NOTIFY_DONE.
> > -					 */
> > -					ret = 0;
> > -				}
> > -			}
> >  			break;
> >  		case EV_SW:
> >  			if (v->code == SW_LID)
> > @@ -433,13 +415,25 @@ static int acpi_button_remove_fs(struct acpi_device *device)
> >     -------------------------------------------------------------------------- */
> >  int acpi_lid_notifier_register(struct notifier_block *nb)
> >  {
> > -	return blocking_notifier_chain_register(&acpi_lid_notifier, nb);
> > +	return raw_notifier_chain_register(&acpi_lid_notifier, nb);
> >  }
> >  EXPORT_SYMBOL(acpi_lid_notifier_register);
> > 
> > +static inline int __acpi_lid_notifier_unregister(struct notifier_block *nb,
> > +						 bool sync)
> > +{
> > +	int ret;
> > +
> > +	ret = raw_notifier_chain_unregister(&acpi_lid_notifier, nb);
> > +	if (sync)
> > +		synchronize_rcu();
> > +
> > +	return ret;
> > +}
> > +
> >  int acpi_lid_notifier_unregister(struct notifier_block *nb)
> >  {
> > -	return blocking_notifier_chain_unregister(&acpi_lid_notifier, nb);
> > +	return __acpi_lid_notifier_unregister(nb, false);
> >  }
> >  EXPORT_SYMBOL(acpi_lid_notifier_unregister);
> > 
> > @@ -452,40 +446,36 @@ int acpi_lid_open(void)
> >  }
> >  EXPORT_SYMBOL(acpi_lid_open);
> > 
> > -static int acpi_lid_update_state(struct acpi_device *device)
> > +static void acpi_lid_update_state(struct acpi_device *device)
> >  {
> >  	int state;
> > 
> >  	state = acpi_lid_evaluate_state(device);
> >  	if (state < 0)
> > -		return state;
> > +		return;
> > 
> > -	return acpi_lid_notify_state(device, state);
> > +	acpi_lid_notify_state(device, state);
> >  }
> > 
> > -static int acpi_lid_notify(struct acpi_device *device)
> > +static void acpi_lid_notify(struct acpi_device *device)
> >  {
> >  	struct acpi_button *button = acpi_driver_data(device);
> > -	int ret;
> > 
> >  	mutex_lock(&button_input_lock);
> >  	if (!button->input)
> >  		acpi_button_add_input(device);
> > -	ret = acpi_lid_update_state(device);
> > +	acpi_lid_update_state(device);
> >  	mutex_unlock(&button_input_lock);
> > -
> > -
> > -	return ret;
> >  }
> > 
> >  static void acpi_lid_initialize_state(struct acpi_device *device)
> >  {
> >  	switch (lid_init_state) {
> >  	case ACPI_BUTTON_LID_INIT_OPEN:
> > -		(void)acpi_lid_notify_state(device, 1);
> > +		acpi_lid_notify_state(device, 1);
> >  		break;
> >  	case ACPI_BUTTON_LID_INIT_METHOD:
> > -		(void)acpi_lid_update_state(device);
> > +		acpi_lid_update_state(device);
> >  		break;
> >  	case ACPI_BUTTON_LID_INIT_IGNORE:
> >  	default:
> > @@ -641,11 +631,7 @@ static int acpi_lid_update_reliable(struct acpi_device *device)
> >  		if (error)
> >  			return error;
> > 
> > -		error = acpi_lid_update_state(device);
> > -		if (error) {
> > -			acpi_button_remove_input(device);
> > -			return error;
> > -		}
> > +		acpi_lid_update_state(device);
> >  	}
> > 
> >  	if (!lid_reliable && button->input)
> > --
> > 2.9.4
> 

  reply	other threads:[~2017-06-06 10:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01 18:46 [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI Benjamin Tissoires
2017-06-01 18:46 ` [WIP PATCH 1/4] ACPI: button: extract input creation/destruction helpers Benjamin Tissoires
2017-06-01 18:46 ` [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown Benjamin Tissoires
2017-06-05  3:19   ` Zheng, Lv
2017-06-06 10:22     ` Benjamin Tissoires
2017-06-07  1:27       ` Peter Hutterer
2017-06-07  9:56       ` Zheng, Lv
2017-06-01 18:46 ` [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events Benjamin Tissoires
2017-06-05  4:28   ` Zheng, Lv
2017-06-06 10:31     ` Benjamin Tissoires
2017-06-01 18:46 ` [WIP PATCH 4/4] ACPI: button: Fix lid notification locks Benjamin Tissoires
2017-06-05  3:33   ` Zheng, Lv
2017-06-06 10:29     ` Benjamin Tissoires [this message]
2017-06-07  9:47       ` Zheng, Lv
2017-06-01 21:43 ` [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI Bastien Nocera
2017-06-02  7:24   ` Benjamin Tissoires
2017-06-05  2:25 ` Zheng, Lv
2017-06-07  7:48 ` Lennart Poettering
2017-06-13 10:06   ` Benjamin Tissoires
2017-06-15  2:52     ` [systemd-devel] " Zheng, Lv
2017-06-15  6:47       ` Peter Hutterer
2017-06-15  7:33         ` Zheng, Lv
2017-06-15  7:57           ` Peter Hutterer
2017-06-16  5:37             ` Zheng, Lv
2017-06-16  7:23               ` Benjamin Tissoires
2017-06-16  7:45                 ` Zheng, Lv
2017-06-16  8:09                   ` Benjamin Tissoires
2017-06-16  8:53                     ` [systemd-devel] " Zheng, Lv
2017-06-16  9:06                       ` Bastien Nocera
2017-06-16 16:32                         ` Lennart Poettering
2017-06-19  2:16                           ` Zheng, Lv
2017-06-19  1:43                         ` Zheng, Lv
2017-06-19 22:08                           ` Bastien Nocera
2017-06-20  2:45                             ` [systemd-devel] " Zheng, Lv
2017-06-21 10:23                               ` Bastien Nocera
2017-06-22  3:16                                 ` Zheng, Lv
2017-06-14 23:50   ` Zheng, Lv

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=20170606102908.GB14880@mail.corp.redhat.com \
    --to=benjamin.tissoires@redhat.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=peter.hutterer@who-t.net \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=zetalog@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).