linux-kernel - Re: [PATCH v10 1/3] firmware: ti_sci: Support transfers without response

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: <20251113061334.wqluum2u4joye64z@lcpd911>
Date: Thu, 13 Nov 2025 11:43:34 +0530
From: Dhruva Gole <d-gole@...com>
To: "Markus Schneider-Pargmann (TI.com)" <msp@...libre.com>
CC: Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>, "Santosh
 Shilimkar" <ssantosh@...nel.org>, Vishal Mahaveer <vishalm@...com>, "Kevin
 Hilman" <khilman@...libre.com>, Sebin Francis <sebin.francis@...com>,
	"Kendall Willis" <k-willis@...com>, Akashdeep Kaur <a-kaur@...com>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v10 1/3] firmware: ti_sci: Support transfers without
 response

On Nov 03, 2025 at 13:42:19 +0100, Markus Schneider-Pargmann (TI.com) wrote:
> Check the header flags if an response is expected or not. If it is not
> expected skip the receive part of ti_sci_do_xfer(). This prepares the
> driver for one-way messages as prepare_sleep for Partial-IO.
> 
> Reviewed-by: Kendall Willis <k-willis@...com>
> Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@...libre.com>
> ---
>  drivers/firmware/ti_sci.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index 49fd2ae01055d0f425062147422471f0fd49e4bd..2585cb82d1ad8e3d79bca458a2b86cc81a3e627b 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -398,6 +398,9 @@ static void ti_sci_put_one_xfer(struct ti_sci_xfers_info *minfo,
>  static inline int ti_sci_do_xfer(struct ti_sci_info *info,
>  				 struct ti_sci_xfer *xfer)
>  {
> +	struct ti_sci_msg_hdr *hdr = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
> +	bool response_expected = !!(hdr->flags & (TI_SCI_FLAG_REQ_ACK_ON_PROCESSED |
> +						  TI_SCI_FLAG_REQ_ACK_ON_RECEIVED));
>  	int ret;
>  	int timeout;
>  	struct device *dev = info->dev;
> @@ -409,12 +412,12 @@ static inline int ti_sci_do_xfer(struct ti_sci_info *info,
>  
>  	ret = 0;
>  
> -	if (system_state <= SYSTEM_RUNNING) {
> +	if (response_expected && system_state <= SYSTEM_RUNNING) {
>  		/* And we wait for the response. */
>  		timeout = msecs_to_jiffies(info->desc->max_rx_timeout_ms);
>  		if (!wait_for_completion_timeout(&xfer->done, timeout))
>  			ret = -ETIMEDOUT;
> -	} else {
> +	} else if (response_expected) {

Makes sense to me for one sided communication messages like partial IO
which is essentially a power off.

Reviewed-by: Dhruva Gole <d-gole@...com>

-- 
Best regards,
Dhruva Gole
Texas Instruments Incorporated