linux-kernel - Re: [PATCH 5/6] firmware: arm_scmi: Use the term 'message' instead of 'command'

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]

Message-ID: <a04dfc00-9c7a-8321-859d-7a12e7b84ea6@arm.com>
Date:   Mon, 8 Jul 2019 17:21:29 +0100
From:   Steven Price <steven.price@....com>
To:     Sudeep Holla <sudeep.holla@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Peng Fan <peng.fan@....com>, linux-kernel@...r.kernel.org,
        Bo Zhang <bozhang.zhang@...adcom.com>,
        Jim Quinlan <james.quinlan@...adcom.com>,
        Volodymyr Babchuk <volodymyr_babchuk@...m.com>
Subject: Re: [PATCH 5/6] firmware: arm_scmi: Use the term 'message' instead of
 'command'

On 08/07/2019 16:43, Sudeep Holla wrote:
> In preparation to adding support for other two types of messages that
> SCMI specification mentions, let's replace the term 'command' with the
> correct term 'message'.
> 
> As per the specification the messages are of 3 types:
> commands(synchronous or asynchronous), delayed responses and notifications.
> 
> Signed-off-by: Sudeep Holla <sudeep.holla@....com>
> ---
>  drivers/firmware/arm_scmi/common.h | 10 +++++-----
>  drivers/firmware/arm_scmi/driver.c |  6 +++---
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 44fd4f9404a9..4349d836b392 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -48,11 +48,11 @@ struct scmi_msg_resp_prot_version {
>  /**
>   * struct scmi_msg_hdr - Message(Tx/Rx) header
>   *
> - * @id: The identifier of the command being sent
> - * @protocol_id: The identifier of the protocol used to send @id command
> - * @seq: The token to identify the message. when a message/command returns,
> - *	the platform returns the whole message header unmodified including
> - *	the token
> + * @id: The identifier of the message being sent
> + * @protocol_id: The identifier of the protocol used to send @id message
> + * @seq: The token to identify the message. when a message returns, the]

Stray ']' at the end of the line.

Steve

> + *	platform returns the whole message header unmodified including the
> + *	token
>   * @status: Status of the transfer once it's complete
>   * @poll_completion: Indicate if the transfer needs to be polled for
>   *	completion or interrupt mode is used
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index cac255c418b2..69bf85fea967 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -182,7 +182,7 @@ static inline int scmi_to_linux_errno(int errno)
>  static inline void scmi_dump_header_dbg(struct device *dev,
>  					struct scmi_msg_hdr *hdr)
>  {
> -	dev_dbg(dev, "Command ID: %x Sequence ID: %x Protocol: %x\n",
> +	dev_dbg(dev, "Message ID: %x Sequence ID: %x Protocol: %x\n",
>  		hdr->id, hdr->seq, hdr->protocol_id);
>  }
>  
> @@ -241,7 +241,7 @@ static void scmi_rx_callback(struct mbox_client *cl, void *m)
>   * @hdr: pointer to header containing all the information on message id,
>   *	protocol id and sequence id.
>   *
> - * Return: 32-bit packed command header to be sent to the platform.
> + * Return: 32-bit packed message header to be sent to the platform.
>   */
>  static inline u32 pack_scmi_header(struct scmi_msg_hdr *hdr)
>  {
> @@ -280,7 +280,7 @@ static void scmi_tx_prepare(struct mbox_client *cl, void *m)
>   *
>   * @handle: Pointer to SCMI entity handle
>   *
> - * Helper function which is used by various command functions that are
> + * Helper function which is used by various message functions that are
>   * exposed to clients of this driver for allocating a message traffic event.
>   *
>   * This function can sleep depending on pending requests already in the system
>