linux-kernel - Re: [PATCH] firmware: ti_sci: Always request response from firmware

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] [day] [month] [year] [list]

Date:   Mon, 29 Apr 2019 09:40:49 -0500
From:   Nishanth Menon <nm@...com>
To:     "Andrew F. Davis" <afd@...com>
CC:     Tero Kristo <t-kristo@...com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: ti_sci: Always request response from firmware

On 09:15-20190429, Andrew F. Davis wrote:
> TI-SCI firmware will only respond to messages when the
> TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages already do
> this, set this for the ones that do not.
> 
> This will be enforced in future firmware that better match the TI-SCI
> specifications, this patch will not break users of existing firmware.
> 
> Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
> Signed-off-by: Andrew F. Davis <afd@...com>
> Acked-by: Nishanth Menon <nm@...com>

yep, the patch allows backward and forward compatibility with TISCI
compliant firmware.

Thanks for doing the patch.

> Tested-by: Alejandro Hernandez <ajhernandez@...com>
> ---
>  drivers/firmware/ti_sci.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index 3fbbb61012c4..3f202c63b9a6 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -448,9 +448,9 @@ static int ti_sci_cmd_get_revision(struct ti_sci_info *info)
>  	struct ti_sci_xfer *xfer;
>  	int ret;
>  
> -	/* No need to setup flags since it is expected to respond */
>  	xfer = ti_sci_get_one_xfer(info, TI_SCI_MSG_VERSION,
> -				   0x0, sizeof(struct ti_sci_msg_hdr),
> +				   TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
> +				   sizeof(struct ti_sci_msg_hdr),
>  				   sizeof(*rev_info));
>  	if (IS_ERR(xfer)) {
>  		ret = PTR_ERR(xfer);
> @@ -578,9 +578,9 @@ static int ti_sci_get_device_state(const struct ti_sci_handle *handle,
>  	info = handle_to_ti_sci_info(handle);
>  	dev = info->dev;
>  
> -	/* Response is expected, so need of any flags */
>  	xfer = ti_sci_get_one_xfer(info, TI_SCI_MSG_GET_DEVICE_STATE,
> -				   0, sizeof(*req), sizeof(*resp));
> +				   TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
> +				   sizeof(*req), sizeof(*resp));
>  	if (IS_ERR(xfer)) {
>  		ret = PTR_ERR(xfer);
>  		dev_err(dev, "Message alloc failed(%d)\n", ret);
> -- 
> 2.21.0
> 

-- 
Regards,
Nishanth Menon