Re: [PATCH v8 0/2] i2c: Add dynamic transfer timeout based on message length and frequency

[Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>]

On 8/27/2026 5:57 PM, Aniket Randive wrote:
> The I2C core and many controller drivers currently rely on a fixed
> timeout value that does not account for transfer characteristics such as
> message length or bus frequency. This can make the timeout unnecessarily
> large for short transfers, while longer transfers at lower bus
> frequencies may require a timeout that better matches the expected
> transfer duration.
> 
> Introduce a generic helper API in the I2C core to calculate a
> transfer-specific timeout from the expected wire time of a transaction.
> Store the computed value in adap->timeout so that both the I2C core retry
> logic and controller drivers use a timeout value that reflects the
> current transfer.
> 
> Keep timeout policy decisions within individual controller drivers. Let
> drivers provide their own safety margins and minimum timeout floors, and
> avoid exposing those driver-specific policy values as part of the
> generic API.
> 
> Convert the Qualcomm GENI I2C driver to use the helper while preserving
> its existing timeout policy. Preserve the static timeout behaviour when
> CONFIG_I2C_DYNAMIC_TIMEOUT is disabled, and let a userspace-configured
> I2C_TIMEOUT value take precedence over the computed timeout.
> 
> Suggested-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
> 

Keep demarcation here ---

> Changes in v8:
> - Compute GPI multi-descriptor timeout using the total length of all
>    messages in the batch, since completion is reported only after the
>    entire batch finishes.
> - Guard against zero bus frequency in i2c_update_timeout() with
>    WARN_ON_ONCE() and retain the existing timeout as a safe fallback.
> - Link to v7: https://patch.msgid.link/20260813-master-v7-0-3f9010cf9229@oss.qualcomm.com
> 
[...]