lkml.org 
[lkml]   [2020]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] firmware: arm_scmi: Make scmi core independent of transport type
On Fri, Nov 29, 2019 at 10:32 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> The SCMI specification is fairly independent of the transport protocol,
> which can be a simple mailbox (already implemented) or anything else.
> The current Linux implementation however is very much dependent of the
> mailbox transport layer.
>
> This patch makes the SCMI core code (driver.c) independent of the
> mailbox transport layer and moves all mailbox related code to a new
> file: mailbox.c.
>
> We can now implement more transport protocols to transport SCMI
> messages.
>
> The transport protocols just need to provide struct scmi_transport_ops,
> with its version of the callbacks to enable exchange of SCMI messages.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Conceptually I think this is fine, but as others have said, it would be
better to have another transport implementation posted along with this
to see if the interfaces actually work out.

> +/**
> + * struct scmi_chan_info - Structure representing a SCMI channel information
> + *
> + * @payload: Transmit/Receive payload area
> + * @dev: Reference to device in the SCMI hierarchy corresponding to this
> + * channel
> + * @handle: Pointer to SCMI entity handle
> + * @transport_info: Transport layer related information
> + */
> +struct scmi_chan_info {
> + void __iomem *payload;
> + struct device *dev;
> + struct scmi_handle *handle;
> + void *transport_info;
> +};

I would assume that with another transport, the 'payload' pointer would
not be __iomem

> +static int scmi_set_transport_ops(struct scmi_info *info)
> +{
> + struct scmi_transport_ops *ops;
> + struct device *dev = info->dev;
> +
> + /* Only mailbox method supported for now */
> + ops = scmi_mailbox_get_ops(dev);
> + if (!ops) {
> + dev_err(dev, "Transport protocol not found in %pOF\n",
> + dev->of_node);
> + return -EINVAL;
> + }
> +
> + info->transport_ops = ops;
> + return 0;
> +}

This looks odd: rather than guessing the transport type based on
random DT properties, I would prefer to have it determined by
the device compatible string, and have different drivers bind
to one of them each, with each driver linking against a common
base implementation, either as separate modules or in one file.

> +static int mailbox_chan_free(int id, void *p, void *data)
> +{
> + struct scmi_chan_info *cinfo = p;
> + struct scmi_mailbox *smbox = cinfo->transport_info;
> +
> + if (!IS_ERR_OR_NULL(smbox->chan)) {
> + mbox_free_channel(smbox->chan);
> + cinfo->transport_info = NULL;
> + smbox->chan = NULL;
> + smbox->cinfo = NULL;
> + }

There is something wrong if smbox->chan can be be one of
three things (a valid pointer, a NULL pointer, or an error value).

I see this is a preexisting problem, but please add a patch to
make it consistently use either NULL pointers or error codes
and remove all instances of IS_ERR_OR_NULL() from this
subsystem.

Arnd

\
 
 \ /
  Last update: 2020-01-09 09:18    [W:0.131 / U:2.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site