All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2024-07-26 14:59 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 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.