Re: [PATCH 6/8] platform: arm64: qcom-hamoa-ec: Retry I2C transfers on NACK

[Konrad Dybcio]

On 7/28/26 7:44 PM, Anvesh Jain P wrote:
> The EC firmware NACKs the bus instead of clock-stretching while it is
> busy servicing internal work (e.g. right after boot, when it is also
> emitting a burst of SCI events). A transfer issued in that window fails
> with -ENXIO even though the EC is otherwise healthy.
> 
> This isn't visible with the smbus-only command set used previously; it
> surfaced while stress-testing the new fan LUT command on Hamoa, which
> issues raw i2c_transfer() calls more aggressively and is thus more
> likely to land in the NACK window right after boot or during an SCI
> event burst.
> 
> Retry qcom_ec_write() and qcom_ec_read() a bounded number of times with
> a short delay when the EC NACKs the transfer, before giving up.
> 
> Signed-off-by: Anvesh Jain P <anvesh.p@xxxxxxxxxxxxxxxx>
> ---

[...]

>  enum qcom_ec_sci_events {
>  	EC_FAN1_STATUS_CHANGE_EVT = 0x30,
>  	EC_FAN2_STATUS_CHANGE_EVT,
> @@ -233,11 +245,20 @@ static int qcom_ec_write(struct qcom_ec *ec, u8 cmd, const u8 *data, size_t len)
>  	msg.buf[0] = cmd;
>  	memcpy(&msg.buf[1], data, len);
>  
> -	ret = i2c_transfer(ec->client->adapter, &msg, 1);
> +	for (int i = 0; i < EC_I2C_NACK_MAX_ATTEMPTS; i++) {
> +		ret = i2c_transfer(ec->client->adapter, &msg, 1);
> +		ret = ret == 1 ? 0 : (ret < 0 ? ret : -EIO);

Please break this monster up. I know it already exists in-tree, but
since you're moving it around, we might as well.

Konrad