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:09:05 +0100 [thread overview]
Message-ID: <Yr8I6KHUrOfLSmEj@e120937-lin> (raw)
In-Reply-To: <20220701140946.uar5ohadyjksf2ka@bogus>
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.
Thanks,
Cristian
next prev parent reply other threads:[~2022-07-01 15:09 UTC|newest]
Thread overview: 18+ 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 ` [PATCH v3 1/9] dt-bindings: firmware: arm,scmi: Add powercap protocol 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 ` [PATCH v3 3/9] firmware: arm_scmi: Generalize FastChannel support 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 ` [PATCH v3 5/9] firmware: arm_scmi: Make use of FastChannels configurable Cristian Marussi
2022-07-01 14:03 ` Sudeep Holla
2022-07-01 14:47 ` Cristian Marussi
2022-07-01 14:55 ` Sudeep Holla
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 ` [PATCH v3 7/9] firmware: arm_scmi: Use " Cristian Marussi
2022-06-27 12:30 ` [PATCH v3 8/9] firmware: arm_scmi: Add scmi_driver optional setup/teardown callbacks Cristian Marussi
2022-07-01 14:09 ` Sudeep Holla
2022-07-01 15:09 ` Cristian Marussi [this message]
2022-07-01 15:18 ` Sudeep Holla
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
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=Yr8I6KHUrOfLSmEj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox