Re: [PATCH] i2c-tools: i2ctransfer: Set I2C adapter timeout using I2C_TIMEOUT ioctl

On 7/21/2026 3:40 AM, Wolfram Sang wrote:
> Hi,
> 
> thank you for this patch!
> 
> On Mon, Jul 20, 2026 at 10:04:01PM +0530, Vasantha Likitha T wrote:
>> Add a -t TIMEOUT option that calls ioctl(I2C_TIMEOUT) before the
>> I2C_RDWR transfer. This allows the adapter timeout to be set from
>> user space at runtime, controlling how long the I2C core waits for
Why userspace need to decide and set the timeout values for adapter ?
Adapter knows the transfer frequency and transfer data length, it can be 
calculated by core layer itself and can set.

Retrials can be fixed and hard coded for everyone.

Is there any other purpose which is missing with the core layer deciding 
timeout ?

Review here @ 
https://lore.kernel.org/all/[email protected]/ 
discussion ongoing to add timeout by i2c-core-base.c

>> a transfer to complete before returning an error. Drivers that rely
>> on the adapter timeout will use the value set by this ioctl.
>>
>> The timeout value is specified in units of 10 ms, as this is the unit
>> the Linux kernel expects for the I2C_TIMEOUT ioctl: i2c-dev converts it
>> with adapter->timeout = msecs_to_jiffies(arg * 10). Omitting -t leaves
>> the driver default unchanged.
> 
> I agree that reading/setting TIMEOUT is missing in i2c-tools (same with
> RETRIES) and it would be nice to have.
> 
> I don't think 'i2ctransfer' is the right place for it, though. One might
> also want a different timeout with 'i2cget' or so.
> 
> My suggestion is to add it to 'i2cdetect'. It already has '-F' to list
> the features of an adapter. We could add '-T' to read the timeout value
> and '-R' to read the retries value. If '-T' or '-R' parameters also
> contain a value, then this value will be written to the adapter.
> 
> Was this undestandable? Do you agree?
> 
> Another option would be to write a dedicated tool ('i2cconfig'?) for
> handling extra parameters, but it feels a bit bloated IMHO.
> 
> Opinions?
> 
> All the best,
> 
>     Wolfram
>