linux-kernel - [PATCH 3/9] firmware: arm_scmi: add basic driver infrastructure for SCMI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri,  7 Jul 2017 22:22:21 +0530
From:   Jassi Brar <jassisinghbrar@...il.com>
To:     linux-kernel@...r.kernel.org
Cc:     robh@...nel.org, alexey.klimov@....com, lho@....com,
        mark.rutland@....com, arnd@...db.de, sudeep.holla@....com,
        Jassi Brar <jaswinder.singh@...aro.org>
Subject: [PATCH 3/9] firmware: arm_scmi: add basic driver infrastructure for SCMI

Hi Arnd, Hi Rob, Hi Mark,

[CC'ing only those who I have the email id of]

>+/**
>+ * scmi_do_xfer() - Do one transfer
>+ *
>+ * @info: Pointer to SCMI entity information
>+ * @xfer: Transfer to initiate and wait for response
>+ *
>+ * Return: -ETIMEDOUT in case of no response, if transmit error,
>+ *   return corresponding error, else if all goes well,
>+ *   return 0.
>+ */
>+int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)
>+{
>+	int ret;
>+	int timeout;
>+	struct scmi_info *info = handle_to_scmi_info(handle);
>+	struct device *dev = info->dev;
>+
>+	ret = mbox_send_message(info->tx_chan, xfer);
>+
>
The api is

    int mbox_send_message(struct mbox_chan *chan, void *mssg)

where each controller driver defines its own format in which it accepts
the 'mssg' to be transmitted.

For example :-
ti_msgmgr_send_data(struct mbox_chan *, struct ti_msgmgr_message *)
rockchip_mbox_send_data(struct mbox_chan *, struct rockchip_mbox_msg *)
....and so on...  you get the idea.

Some controller driver may ignore the 'mssg' because only an interrupt line
is shared with the remote and not some register/fifo.
For example,
  sti_mbox_send_data(struct mbox_chan *, void *ignored)

Out of 14 controller drivers today, this SCMI implementation will work with
only 5 (and that too by abusing the api). The other 9 controllers (and many
in future) are perfectly able to support SCMI (its just another protocol).
All we need is what the SCMI specification calls "Transport Layer".
Of course that will be a thin platform/controller specific code that will
encapsulate the 'struct scmi_xfer *xfer' from SCMI, into controller specified
format and actually call the mbox_send_message().

 To achieve that, we can either do similar to what platforms with DWC3
do - generic dwc3 child node of platform specific parent node. Or we can have
the SCMI protocol implemented as a library that platforms can init and use.
Or any other better way.

 I just think it is a bad idea to rule out all but one classes of mailbox controllers.

Regards.