[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zqp0IZfUobg6dq8G@google.com>
Date: Wed, 31 Jul 2024 10:28:01 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Peng Fan <peng.fan@....com>
Cc: Cristian Marussi <cristian.marussi@....com>,
"Peng Fan (OSS)" <peng.fan@....nxp.com>,
Sudeep Holla <sudeep.holla@....com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
"arm-scmi@...r.kernel.org" <arm-scmi@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Subject: Re: [PATCH v7 7/7] input: keyboard: support i.MX95 BBM module
Hi Peng,
On Wed, Jul 31, 2024 at 03:37:18PM +0000, Peng Fan wrote:
> Hi Cristian,
>
> > Subject: Re: [PATCH v7 7/7] input: keyboard: support i.MX95 BBM
> > module
> >
> > On Wed, Jul 31, 2024 at 08:56:11PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@....com>
> > >
> > > The BBM module provides BUTTON feature. To i.MX95, this module is
> > > managed by System Manager and exported using System
> > Management Control
> > > Interface(SCMI). Linux could use i.MX SCMI BBM Extension protocol
> > to
> > > use BUTTON feature.
> > >
> > > This driver is to use SCMI interface to enable pwrkey.
> > >
> > > +}
> > > +
> > > +static void scmi_imx_bbm_key_remove(struct scmi_device *sdev) {
> > > + struct device *dev = &sdev->dev;
> > > + struct scmi_imx_bbm *bbnsm = dev_get_drvdata(dev);
> > > +
> > > + device_init_wakeup(dev, false);
I do not believe you need to reset the wakeup flag on driver unbind, as
well as in the error handling path of probe(). If this is needed then
driver core should do this cleanup (maybe it already does?).
> > > +
> > > + cancel_delayed_work_sync(&bbnsm->check_work);
> > > +}
> > > +
> >
> > ..so in v6 I asked you to add a cancel_delayed_work_sync() on the
> > removal path, BUT I missed, my bad, that indeed above there was
> > already a call to cancel_delayed_work_sync() associated to a
> > devm_add_action_or_reset....so now we have 2....also you should try
> > not to mix devm_add_action_or_reset and plain .remove methods..use
> > one or the other.
>
> Thanks for your detailed reviewing on this. I will wait to see if Sudeep
> has any comments to patch 1-4. If no comments, I will not do a new
> version to this patchset.
>
> If v7 patch 1-4 are good for Sudeep to pick up, I will separate this patch
> out as a standalone one for input subsystem maintainer.
If you remove the duplicated cancel_delayed_work_sync() in remove() and
unneded device_init_wakeup(dev, false); then you can merge the input
patch with the rest of them with my:
Acked-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
Thanks.
--
Dmitry
Powered by blists - more mailing lists