linux-kernel - Re: [PATCH v7 7/7] input: keyboard: support i.MX95 BBM module

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: <Zq3KkwhB89zUfAjn@google.com>
Date: Fri, 2 Aug 2024 23:13:39 -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

On Thu, Aug 01, 2024 at 01:36:10AM +0000, Peng Fan wrote:
> Hi Dmitry,
> 
> > 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?).
> 
> I just check the driver core code, you are right, there is
> no need do this.
> 
> DevAttrError:
>  device_pm_remove-> device_wakeup_disable(dev);
>  dpm_sysfs_remove
> 
> > 
> > > > > +
> > > > > +	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 for your Ack. But I think patch 1-4 needs go to arm-scmi tree,
> Patch 5 to arm imx tree, patch 6 to rtc tree, patch 7 to input tree.
> 
> I put the patches together in a patchset is to let reviewers could
> get a full picture how the whole stuff work.
> 
> For patch 7, I will send out it as a separate patch with fix and tag
> after patch 1-4 is ready in arm-scmi tree.

Right, but to accelerate getting support for your part into the mainline
I am OK with input piece not going through the input tree but together
with the rest of the patches through some other tree, probably through
arm-scmi. If they are not willing to take it then we will have to wait
till core support lands in mainline and then I can pick up the input
piece and move it through my tree.

Thanks.

-- 
Dmitry