Re: [PATCH v6 1/2] i2c: core: Add i2c_update_timeout() helper for dynamic transfer timeouts
From: Mukesh Savaliya
Date: Tue Jul 28 2026 - 06:33:16 EST
Thanks a lot Wolfram !
On 7/28/2026 3:12 PM, Wolfram Sang wrote:
Hi,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.
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.
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