linux-kernel - Re: [PATCH 1/2] Input: Create input notifier chain in input.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMCVhVP+LW27iLXttyFegRj_HMHheYrZtj4uuERLN0uqUjkR6Q@mail.gmail.com>
Date: Wed, 5 Nov 2025 16:40:29 -0600
From: Jonathan Denose <jdenose@...gle.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Jiri Kosina <jikos@...nel.org>, Benjamin Tissoires <bentiss@...nel.org>, linux-input@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Input: Create input notifier chain in input.c

Hi Dmitry,

Thanks for your feedback.

On Wed, Nov 5, 2025 at 3:55 PM Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>
> Hi Jonathan,
>
> On Thu, Oct 30, 2025 at 02:10:40PM +0000, Jonathan Denose wrote:
> > To expose input events to other kernel modules, add a blocking notifier
> > chain. Publish LID_SWITCH_OPEN/LID_SWITCH_CLOSE events through this
> > notifier chain when input_handle_event detects events signaling the lid
> > switch has opened or closed.
> >
> > Additionally, export a function which allows other kernel modules to
> > register notifier_block structs against this notifier chain.
> >
> > Signed-off-by: Jonathan Denose <jdenose@...gle.com>
> > ---
> >  drivers/input/input.c | 13 +++++++++++++
> >  include/linux/input.h |  7 +++++++
> >  2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/input/input.c b/drivers/input/input.c
> > index a500e1e276c211d1146dbfea421a3402084007f8..b342b1ff138ccc58d4623edcf1152bd85d7054bf 100644
> > --- a/drivers/input/input.c
> > +++ b/drivers/input/input.c
> > @@ -26,6 +26,7 @@
> >  #include <linux/kstrtox.h>
> >  #include <linux/mutex.h>
> >  #include <linux/rcupdate.h>
> > +#include <linux/notifier.h>
> >  #include "input-compat.h"
> >  #include "input-core-private.h"
> >  #include "input-poller.h"
> > @@ -62,6 +63,8 @@ static const unsigned int input_max_code[EV_CNT] = {
> >       [EV_FF] = FF_MAX,
> >  };
> >
> > +static struct blocking_notifier_head input_notifier_head;
> > +
> >  static inline int is_event_supported(unsigned int code,
> >                                    unsigned long *bm, unsigned int max)
> >  {
> > @@ -367,10 +370,20 @@ void input_handle_event(struct input_dev *dev,
> >               if (type != EV_SYN)
> >                       add_input_randomness(type, code, value);
> >
> > +             if (type == EV_SW && code == SW_LID && !value)
> > +                     blocking_notifier_call_chain(&input_notifier_head, value ?
> > +                             LID_SWITCH_CLOSE : LID_SWITCH_OPEN, dev);
>
> I would prefer not having this directly in the input core but rather
> have a lid handler that can then use notifier chain to forward the
> events further.

Ok, that makes sense to me. In that case, do you have a recommendation
for where the lid handler should go?

It looks like drivers/acpi/button.c initializes and handles the lid switch, so
would it make sense for it to go there?

> Also, here you are running in atomic context, so you need atomic
> notifier, not blocking (or you need to involve a workqueue).

I'll use an atomic notifier in the next version.

> Thanks.
>
> --
> Dmitry
-- 
Jonathan