Messages in this thread | | | Date | Wed, 28 Jul 2021 12:40:18 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH v6 05/17] firmware: arm_scmi: Add transport optional init/exit support |
| |
On Mon, Jul 12, 2021 at 03:18:21PM +0100, Cristian Marussi wrote: > Some SCMI transport could need to perform some transport specific setup > before they can be used by the SCMI core transport layer: typically this > early setup consists in registering with some other kernel subsystem. > > Add the optional capability for a transport to provide a couple of .init > and .exit functions that are assured to be called early during the SCMI > core initialization phase, well before the SCMI core probing step. > > [ Peter: Adapted RFC patch by Cristian for submission to upstream. ] > Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> > [ Cristian: Fixed scmi_transports_exit point of invocation ] > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > v4 --> V5 > - removed useless pr_debug > - moved scmi_transport_exit() invocation > --- > drivers/firmware/arm_scmi/common.h | 8 +++++ > drivers/firmware/arm_scmi/driver.c | 56 ++++++++++++++++++++++++++++++ > 2 files changed, 64 insertions(+) > > diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h > index 7c2b9fd7e929..6bb734e0e3ac 100644 > --- a/drivers/firmware/arm_scmi/common.h > +++ b/drivers/firmware/arm_scmi/common.h > @@ -321,6 +321,12 @@ struct scmi_device *scmi_child_dev_find(struct device *parent, > /** > * struct scmi_desc - Description of SoC integration > * > + * @init: An optional function that a transport can provide to initialize some > + * transport-specific setup during SCMI core initialization, so ahead of > + * SCMI core probing. > + * @exit: An optional function that a transport can provide to de-initialize > + * some transport-specific setup during SCMI core de-initialization, so > + * after SCMI core removal. > * @ops: Pointer to the transport specific ops structure > * @max_rx_timeout_ms: Timeout for communication with SoC (in Milliseconds) > * @max_msg: Maximum number of messages that can be pending > @@ -328,6 +334,8 @@ struct scmi_device *scmi_child_dev_find(struct device *parent, > * @max_msg_size: Maximum size of data per message that can be handled. > */ > struct scmi_desc { > + int (*init)(void); > + void (*exit)(void);
Does it make sense to rename scmi_desc as scmi_transport or scmi_transport_desc ? I reason I ask is plain init/exit here doesn't make sense. You can change it to transport_init/exit if we don't want to rename the structure.
> const struct scmi_transport_ops *ops;
I assume we don't want init/exit inside ops as it is shared with protocols ? Looks good other than the above comment.
-- Regards, Sudeep
| |