Re: [PATCH i2c-tools v2 0/2] Add support for message modifier flags

["Benoît Monin" <benoit.monin@bootlin.com>]

Hi Jean,

On Tuesday, 20 January 2026 at 15:15:36 CET, Jean Delvare wrote:
> Hi Benoït, hi Wolfram,
> 
> On Tue, 23 Dec 2025 14:22:41 +0100, Benoît Monin wrote:
> > I2C messages can be modified with a set of flags covered by the protocol
> > mangling and the skip repeated start functionalities. This series add
> > support for such flags to i2cdetect and i2ctransfer.
> > 
> > The first patch shows the support of protocol mangling and repeated
> > start skipping in the output of 'i2cdetect -F'.
> > 
> > The second patch adds the parsing of optional flags to i2ctransfer
> > message description. Those command-line flags then set the i2c message
> > flags alongside the read/write flag.
> > 
> > I wrote these changes to test the insertion of I2C_M_STOP flag in
> > multi-message transactions with i2ctransfer, but the other flags can be
> > useful for various test scenarios.
> 
> Out of curiosity, did you have an actual scenario where you needed to
> do this? Protocol mangling is supposed to be rarely needed and avoided
> as much as possible.
> 
My only need was to have a way to set the I2C_M_STOP flag, but since I
started modifying i2ctransfer, adding the other flags was not much
additional work.

If you think that some of the flags should not be exposed by i2ctransfer, I
can remove them.

> > The patches use defines that have been present in the kernel since
> > v3.6 released in 2012. If compatibility with older kernel is required,
> > we will need to wrap some of them with #ifndef ... #endif.
> > 
> > Maybe a minimum kernel version can be documented in the README?
> 
> Be careful if you do. Kernel versions are a very broad indicator,
> distribution kernel maintainers keep backporting features so an older
> kernel can actually support something when its version suggests it
> wouldn't. A kernel version should always be complemented with the actual
> feature or flag so that users can look it up if needed.
> 
True. I will go with #ifdef instead, as you and Wolfram proposed. And I will
add a check against the adapter functionalities.

[...]

Thanks for the review!
-- 
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com