Re: [PATCH v6 1/2] i2c: core: Add i2c_update_timeout() helper for dynamic transfer timeouts

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

Thanks a lot Wolfram !

On 7/28/2026 3:12 PM, Wolfram Sang wrote:
> Hi,
> 
>> My thinking was that we are trying to derive a timeout for transfer
>> completion, so the transfer length and bus frequency should already give
>> us the theoretical on-the-wire transfer time.
> 
> With my experience in all these years with I2C, this is exactly true. It
> is a _theoretical_ value, and the practical value is at least board(!)
> dependant. It may also depend on the environment in other cases. So, the
> theoretical value may supply a minimum but IMO this doesn't help.
> Because we want a precise value, but we don't know it.
> 
I agree that the precise timeout is platform dependent and cannot be 
derived exactly from the transfer parameters alone. My intention is not 
to determine the perfect value, but rather to provide a reasonable 
kernel-side default for cases where no timeout has been configured 
explicitly.

Since kernel-space clients have no generic mechanism to tune adapter 
timeouts on a per-system basis, deriving a baseline from the transfer 
length and bus frequency, combined with a conservative margin, seems 
preferable to relying solely on a fixed constant.

I am also suggesting let userspace add something on top of this if the 
core derived final timeout is not sufficient.

>> On top of that, we could add a fixed margin to account for interrupt and
>> system scheduling latency before converting the result to jiffies.
>>
>> The exact margin is open for discussion. I was considering something on
>> the order of a few hundred milliseconds (e.g. 500 ms), but perhaps that
>> is still too optimistic on some systems?
> 
> See, you simply cannot know. So, why not leaving it to those who do know
> for their system?
> 

This is an option for userspace. Should we expose device attributes for 
kernel space ? if no, then there has to be some calculated value with 
reasonable offset.

>> Alternatively, the core could provide a calculated baseline timeout
>> (transfer time + fixed margin) and allow userspace to add an optional
>> extra offset when needed. That way the default behavior remains automatic
>> and works for most clients, while systems with unusual latency
>> requirements can still increase the timeout without every userspace client
>> having to determine an appropriate value itself.
> 
> We already have a mechanism for userspace to set a timeout.
> 

Yes, and I fully support keeping I2C_TIMEOUT as the mechanism for 
userspace adjustment. What I am proposing is complementary rather than a 
replacement. The core could calculate a baseline timeout from the 
transfer characteristics and apply a conservative margin, while 
I2C_TIMEOUT would remain available for systems that require additional 
headroom beyond the default calculation.

>> Do you see cases where a transfer-time-based timeout with a generous
>> system-latency margin would still be insufficient?
> 
> Regressions. You could time out too early on boards which worked before.
> 

That is a valid concern. My assumption is that any calculated timeout 
would include a sufficiently conservative margin, based on measurements 
across a range of systems, so that existing working platforms would not 
regress. If a platform still requires significantly larger values due to 
exceptional latency characteristics, I would expect that requirement to 
be addressed through the existing timeout override mechanism rather than 
by forcing every client to use a large fixed timeout.

Looking further for common approach to be finalized considering both 
userspace, kernel space.

> Happy hacking,
> 
>     Wolfram
>