Re: [PATCH] firmware: arm_scmi: Make scmi core independent of transport type

[Arnd Bergmann]

On Fri, Nov 29, 2019 at 10:32 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> 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@xxxxxxxxxx>

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