From: Cristian Marussi <cristian.marussi@arm.com>
To: Etienne CARRIERE <etienne.carriere@st.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"arm-scmi@vger.kernel.org" <arm-scmi@vger.kernel.org>,
"sudeep.holla@arm.com" <sudeep.holla@arm.com>,
"james.quinlan@broadcom.com" <james.quinlan@broadcom.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"peng.fan@oss.nxp.com" <peng.fan@oss.nxp.com>,
"michal.simek@amd.com" <michal.simek@amd.com>,
"quic_sibis@quicinc.com" <quic_sibis@quicinc.com>,
"quic_nkela@quicinc.com" <quic_nkela@quicinc.com>,
"ptosi@google.com" <ptosi@google.com>,
"dan.carpenter@linaro.org" <dan.carpenter@linaro.org>,
"souvik.chakravarty@arm.com" <souvik.chakravarty@arm.com>
Subject: Re: [PATCH v2 3/8] firmware: arm_scmi: Add support for standalone transport drivers
Date: Fri, 26 Jul 2024 15:59:44 +0100 [thread overview]
Message-ID: <ZqO54KACyHUUYEXj@pluto> (raw)
In-Reply-To: <PAXPR10MB4687B74810CA8EDB5BFC4781FDA92@PAXPR10MB4687.EURPRD10.PROD.OUTLOOK.COM>
On Tue, Jul 23, 2024 at 01:39:41PM +0000, Etienne CARRIERE wrote:
> Hi Cristian,
>
> Few nitpicking comments.
>
> On Wednesday, July 10, 2024, Cristian Marussi wrote:
> > Extend the core SCMI stack with structures and methods to allow for
> > transports to be split out as standalone drivers, while still supporting
> > old style transports, defined as built into the SCMI core stack.
> >
> > No functional change.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > NOTE: old style transport support will be removed later in this series.
> >
> > v1 --> v2
> > - fixed comit message
> > ---
> > drivers/firmware/arm_scmi/common.h | 84 ++++++++++++++++++++++++++++++
> > drivers/firmware/arm_scmi/driver.c | 44 +++++++++++++++-
> > drivers/firmware/arm_scmi/msg.c | 5 ++
> > drivers/firmware/arm_scmi/shmem.c | 5 ++
> > 4 files changed, 136 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> > index 8e5751aaa600..4af06810eb39 100644
> > --- a/drivers/firmware/arm_scmi/common.h
> > +++ b/drivers/firmware/arm_scmi/common.h
> > @@ -349,6 +349,8 @@ struct scmi_shared_mem_operations {
> > bool tx, struct resource *res);
> > };
> >
> > +const struct scmi_shared_mem_operations *scmi_shared_mem_operations_get(void);
> > +
> > /* declarations for message passing transports */
> > struct scmi_msg_payld;
> >
> > @@ -376,6 +378,88 @@ struct scmi_message_operations {
> > size_t max_len, struct scmi_xfer *xfer);
> > };
> >
> > +const struct scmi_message_operations *scmi_message_operations_get(void);
> > +
> > +/**
> > + * struct scmi_transport_core_operations - Transpoert core operations
> > + *
> > + * @bad_message_trace: An helper to report a malformed/unexpected message
> > + * @rx_callback: Callback to report received messages
> > + * @shmem: Datagram operations for shared memory based transports
> > + * @msg: Datagram operations for message based transports
> > + */
> > +struct scmi_transport_core_operations {
> > + void (*bad_message_trace)(struct scmi_chan_info *cinfo,
> > + u32 msg_hdr, enum scmi_bad_msg err);
> > + void (*rx_callback)(struct scmi_chan_info *cinfo, u32 msg_hdr,
> > + void *priv);
> > + const struct scmi_shared_mem_operations *shmem;
> > + const struct scmi_message_operations *msg;
> > +};
> > +
> > +/**
> > + * struct scmi_transport - A structure representing a configured transport
> > + *
> > + * @supplier: Device representimng the transport and acting as a supplier for
>
> typo: s/representimng/representing/
>
Fixed in V3. (...still to be posted)
> > + * the core SCMI stack
> > + * @desc: Transport descriptor
> > + * @core_ops: A pointer to a pointer used by the core SCMI stack to make the
> > + * core transport operations accessible to the transports.
> > + */
> > +struct scmi_transport {
> > + struct device *supplier;
> > + const struct scmi_desc *desc;
> > + struct scmi_transport_core_operations **core_ops;
> > +};
> > +
> > +#define DEFINE_SCMI_TRANSPORT_DRIVER(__trans, __match_table, __core_ptr)\
> > +static int __trans##_probe(struct platform_device *pdev) \
> > +{ \
> > + struct scmi_transport *scmi_trans; \
> > + struct platform_device *scmi_pdev; \
> > + struct device *dev = &pdev->dev; \
> > + \
> > + scmi_trans = devm_kzalloc(dev, sizeof(*scmi_trans), GFP_KERNEL);\
> > + if (!scmi_trans) \
> > + return -ENOMEM; \
> > + \
> > + scmi_pdev = devm_kzalloc(dev, sizeof(*scmi_pdev), GFP_KERNEL); \
> > + if (!scmi_pdev) \
> > + return -ENOMEM; \
> > + \
> > + scmi_trans->supplier = dev; \
> > + scmi_trans->desc = &__trans##_desc; \
>
> It's a bit weird the scmi_desc shall be specifically labeled __trans##_desc
> in the transport driver source file while match table and transport core
> operations instances references are passed as arguments. I think it's
> worth having the scmi_desc label also passed as an argument to
> DEFINE_SCMI_TRANSPORT_DRIVER() macro.
Yes, I agree, I was unsure about this so I have reworked all of these in
V3 to pass as explicit parameter the driver name and desc name.
>
> > + scmi_trans->core_ops = __core_ptr; \
> > + \
> > + scmi_pdev->name = "arm-scmi"; \
> > + scmi_pdev->id = PLATFORM_DEVID_AUTO; \
> > + scmi_pdev->dev.platform_data = scmi_trans; \
> > + \
> > + device_set_of_node_from_dev(&scmi_pdev->dev, dev); \
> > + \
> > + dev_set_drvdata(dev, scmi_pdev); \
> > + \
> > + return platform_device_register(scmi_pdev); \
> > +} \
> > + \
> > +static void __trans##_remove(struct platform_device *pdev) \
> > +{ \
> > + struct platform_device *scmi_pdev; \
> > + \
> > + scmi_pdev = dev_get_drvdata(&pdev->dev); \
> > + \
> > + platform_device_unregister(scmi_pdev); \
> > +} \
> > + \
> > +static struct platform_driver __trans##_driver = { \
>
> Same here. I think __trans##_driver label should be also explicitly
> passed as an argument to DEFINE_SCMI_TRANSPORT_DRIVER().
>
Fixed in V3.
Thanks,
Cristian
next prev parent reply other threads:[~2024-07-26 15:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 17:31 [PATCH 0/8] Make SCMI transport as standalone drivers Cristian Marussi
2024-07-10 17:31 ` [PATCH v2 1/8] firmware: arm_scmi: Introduce setup_shmem_iomap Cristian Marussi
2024-07-12 19:44 ` kernel test robot
2024-07-26 15:18 ` Cristian Marussi
2024-07-10 17:31 ` [PATCH v2 2/8] firmware: arm_scmi: Introduce packet handling helpers Cristian Marussi
2024-07-11 10:43 ` Peng Fan
2024-07-11 14:08 ` Cristian Marussi
2024-07-23 13:41 ` Etienne CARRIERE
2024-07-26 14:57 ` Cristian Marussi
2024-07-10 17:31 ` [PATCH v2 3/8] firmware: arm_scmi: Add support for standalone transport drivers Cristian Marussi
2024-07-11 12:54 ` Peng Fan
2024-07-11 14:18 ` Cristian Marussi
2024-07-23 13:39 ` Etienne CARRIERE
2024-07-26 14:59 ` Cristian Marussi [this message]
2024-07-10 17:31 ` [PATCH v2 4/8] firmware: arm_scmi: Make MBOX transport a standalone driver Cristian Marussi
2024-07-11 12:56 ` Peng Fan
2024-07-23 13:41 ` Etienne CARRIERE
2024-07-26 15:00 ` Cristian Marussi
2024-07-10 17:31 ` [PATCH v2 5/8] firmware: arm_scmi: Make SMC " Cristian Marussi
2024-07-10 21:04 ` Nikunj Kela
2024-07-11 10:09 ` Cristian Marussi
2024-07-10 17:31 ` [PATCH v2 6/8] firmware: arm_scmi: Make OPTEE " Cristian Marussi
2024-07-11 12:57 ` Peng Fan
2024-07-11 14:20 ` Cristian Marussi
2024-07-26 15:01 ` Cristian Marussi
2024-07-10 17:31 ` [PATCH v2 7/8] firmware: arm_scmi: Make VirtIO " Cristian Marussi
2024-07-10 17:31 ` [PATCH v2 8/8] firmware: arm_scmi: Remove legacy transport-layer code Cristian Marussi
2024-07-11 13:26 ` [PATCH 0/8] Make SCMI transport as standalone drivers Peng Fan
2024-07-11 14:22 ` Cristian Marussi
2024-07-23 13:36 ` Etienne CARRIERE
2024-07-26 15:14 ` Cristian Marussi
2024-07-12 21:02 ` Florian Fainelli
2024-07-26 15:17 ` 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=ZqO54KACyHUUYEXj@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=etienne.carriere@st.com \
--cc=f.fainelli@gmail.com \
--cc=james.quinlan@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=peng.fan@oss.nxp.com \
--cc=ptosi@google.com \
--cc=quic_nkela@quicinc.com \
--cc=quic_sibis@quicinc.com \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).