From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, james.quinlan@broadcom.com,
Jonathan.Cameron@huawei.com, f.fainelli@gmail.com,
etienne.carriere@linaro.org, vincent.guittot@linaro.org,
daniel.lezcano@linaro.org, tarek.el-sherbiny@arm.com,
adrian.slatineanu@arm.com, souvik.chakravarty@arm.com,
wleavitt@marvell.com, wbartczak@marvell.com
Subject: Re: [PATCH v3 8/9] firmware: arm_scmi: Add scmi_driver optional setup/teardown callbacks
Date: Fri, 1 Jul 2022 16:21:11 +0100 [thread overview]
Message-ID: <Yr8Q2RqGe4+FOSLS@e120937-lin> (raw)
In-Reply-To: <20220701151829.j2blytsgma5so6ox@bogus>
On Fri, Jul 01, 2022 at 04:18:29PM +0100, Sudeep Holla wrote:
> On Fri, Jul 01, 2022 at 04:09:05PM +0100, Cristian Marussi wrote:
> > On Fri, Jul 01, 2022 at 03:09:46PM +0100, Sudeep Holla wrote:
> > > On Mon, Jun 27, 2022 at 01:30:37PM +0100, Cristian Marussi wrote:
> > > > Add optional .setup and .teardown methods to the scmi_driver descriptor:
> > > > such callbacks, if provided, will be called by the SCIM core at driver
> > > > registration time, so that, an SCMI driver, registered as usual with the
> > > > module_scmi_driver() helper macro, can provide custom callbacks to be
> > > > run once for all at module load/unload time to perform specific setup
> > > > or teardown operations before/after .probe and .remove steps.
> > > >
> > >
> > > What can't the driver call this setup/teardown on its own before/after
> > > calling scmi_driver_register/unregister ?
> >
> > >
> > > Based on the usage in 9/9, I guess it is mainly to use the
> > > module_scmi_driver ? If so, I would avoid using that or have another
> > > macro to manage this setup/teardown(once there are multiple users for that).
> > > IMO, it doesn't make sense to add callbacks to do things that are outside
> > > the scope of scmi drivers. No ?
> > >
> >
> > This is exactly what I was doing in fact :D at first ... defining a normal
> > init/exit from where I called what I needed at first and then ivoke the
> > scmi_driver_register()...so bypassing/not using the module_scmi-driver macro
> > indeed...then I realized I needed something similar also for the SCMI Test
> > driver, so I tried to unify; in both cases indeed the required ops to be
> > done before the scmi_driver_register are NOT scmi related things.
> >
> > So I can drop this if you prefer and use bare module_init/exit that
> > calls scmi_driver_register() after having setup what needed for the
> > specific driver initialization (before probe)...I was not really
> > convinced it was worth this level of unification.
> >
>
> We can add macro for that too if there is another user for this. i.e.
> if and when we merge the test code using something similar, we can
> wrap them in a macro module_scmi_driver_setup_teardown(driver, setup, teardown)
> and simplify things for the users.
>
Ok, thanks I'll drop this for this series.
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, james.quinlan@broadcom.com,
Jonathan.Cameron@huawei.com, f.fainelli@gmail.com,
etienne.carriere@linaro.org, vincent.guittot@linaro.org,
daniel.lezcano@linaro.org, tarek.el-sherbiny@arm.com,
adrian.slatineanu@arm.com, souvik.chakravarty@arm.com,
wleavitt@marvell.com, wbartczak@marvell.com
Subject: Re: [PATCH v3 8/9] firmware: arm_scmi: Add scmi_driver optional setup/teardown callbacks
Date: Fri, 1 Jul 2022 16:21:11 +0100 [thread overview]
Message-ID: <Yr8Q2RqGe4+FOSLS@e120937-lin> (raw)
In-Reply-To: <20220701151829.j2blytsgma5so6ox@bogus>
On Fri, Jul 01, 2022 at 04:18:29PM +0100, Sudeep Holla wrote:
> On Fri, Jul 01, 2022 at 04:09:05PM +0100, Cristian Marussi wrote:
> > On Fri, Jul 01, 2022 at 03:09:46PM +0100, Sudeep Holla wrote:
> > > On Mon, Jun 27, 2022 at 01:30:37PM +0100, Cristian Marussi wrote:
> > > > Add optional .setup and .teardown methods to the scmi_driver descriptor:
> > > > such callbacks, if provided, will be called by the SCIM core at driver
> > > > registration time, so that, an SCMI driver, registered as usual with the
> > > > module_scmi_driver() helper macro, can provide custom callbacks to be
> > > > run once for all at module load/unload time to perform specific setup
> > > > or teardown operations before/after .probe and .remove steps.
> > > >
> > >
> > > What can't the driver call this setup/teardown on its own before/after
> > > calling scmi_driver_register/unregister ?
> >
> > >
> > > Based on the usage in 9/9, I guess it is mainly to use the
> > > module_scmi_driver ? If so, I would avoid using that or have another
> > > macro to manage this setup/teardown(once there are multiple users for that).
> > > IMO, it doesn't make sense to add callbacks to do things that are outside
> > > the scope of scmi drivers. No ?
> > >
> >
> > This is exactly what I was doing in fact :D at first ... defining a normal
> > init/exit from where I called what I needed at first and then ivoke the
> > scmi_driver_register()...so bypassing/not using the module_scmi-driver macro
> > indeed...then I realized I needed something similar also for the SCMI Test
> > driver, so I tried to unify; in both cases indeed the required ops to be
> > done before the scmi_driver_register are NOT scmi related things.
> >
> > So I can drop this if you prefer and use bare module_init/exit that
> > calls scmi_driver_register() after having setup what needed for the
> > specific driver initialization (before probe)...I was not really
> > convinced it was worth this level of unification.
> >
>
> We can add macro for that too if there is another user for this. i.e.
> if and when we merge the test code using something similar, we can
> wrap them in a macro module_scmi_driver_setup_teardown(driver, setup, teardown)
> and simplify things for the users.
>
Ok, thanks I'll drop this for this series.
Thanks,
Cristian
next prev parent reply other threads:[~2022-07-01 15:22 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 12:30 [PATCH v3 0/9] SCMIv3.1 Powercap protocol and driver Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 1/9] dt-bindings: firmware: arm,scmi: Add powercap protocol Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 2/9] firmware: arm_scmi: Add SCMIv3.1 Powercap protocol basic support Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 3/9] firmware: arm_scmi: Generalize FastChannel support Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 4/9] firmware: arm_scmi: Add SCMIv3.1 Powercap FastChannels support Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 5/9] firmware: arm_scmi: Make use of FastChannels configurable Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-07-01 14:03 ` Sudeep Holla
2022-07-01 14:03 ` Sudeep Holla
2022-07-01 14:47 ` Cristian Marussi
2022-07-01 14:47 ` Cristian Marussi
2022-07-01 14:55 ` Sudeep Holla
2022-07-01 14:55 ` Sudeep Holla
2022-07-01 15:05 ` Cristian Marussi
2022-07-01 15:05 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 6/9] include: trace: Add SCMI FastChannel tracing Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 7/9] firmware: arm_scmi: Use " Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 8/9] firmware: arm_scmi: Add scmi_driver optional setup/teardown callbacks Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
2022-07-01 14:09 ` Sudeep Holla
2022-07-01 14:09 ` Sudeep Holla
2022-07-01 15:09 ` Cristian Marussi
2022-07-01 15:09 ` Cristian Marussi
2022-07-01 15:18 ` Sudeep Holla
2022-07-01 15:18 ` Sudeep Holla
2022-07-01 15:21 ` Cristian Marussi [this message]
2022-07-01 15:21 ` Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 9/9] powercap: arm_scmi: Add SCMI Powercap based driver Cristian Marussi
2022-06-27 12:30 ` Cristian Marussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yr8Q2RqGe4+FOSLS@e120937-lin \
--to=cristian.marussi@arm.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=adrian.slatineanu@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=etienne.carriere@linaro.org \
--cc=f.fainelli@gmail.com \
--cc=james.quinlan@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--cc=tarek.el-sherbiny@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=wbartczak@marvell.com \
--cc=wleavitt@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.