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] [day] [month] [year] [list]

Message-ID: <h6nfc5amtqsfbka5n36i4hldcpomyped66xbvtaes3y6p3dctv@3j5iiyky6o44>
Date: Wed, 5 Nov 2025 14:59:09 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Jonathan Denose <jdenose@...gle.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

On Wed, Nov 05, 2025 at 04:40:29PM -0600, Jonathan Denose wrote:
> 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?

drivers/acpi/button.c is not the only source of SW_LID events (we also
have cros-ec-keyb.c and others), so I'd recommend putting it into
drivers/input, maybe as lid-notifier.c

> 
> > 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.

Another option would be to schedule work and then use blocking notifier.

Thanks.

-- 
Dmitry