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@xxxxxxx> > > > > > > > > > > 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@xxxxxxxxx> > > 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