Re: [PATCH] i2c: core: Lock address during client device instantiation

[Heiner Kallweit <hkallweit1@gmail.com>]

On 14.08.2024 13:14, Wolfram Sang wrote:
> Hi Heiner,
> 
> thanks for tackling this!
> 
>> +static int i2c_lock_addr(struct i2c_adapter *adap, unsigned short addr,
>> +			 unsigned short flags)
> 
> What about just using 'struct i2c_client *client' here as an argument.
> It has all we need and it currently seems unlikely that we need to call
> it from somewhere else where we need this seperation.
> 
>> +	if (!(flags & I2C_CLIENT_TEN) && !(flags & I2C_CLIENT_SLAVE) &&
> 
> From a pedantic point of view, I don't see a reason for not handling
> those two cases above. I hate to be pedantic because 10-bit mode is
> practically unused (and I am tempted to remove support for it once in a
> while because it makes other solutions clumsy). And the other one is
> super unlikely to happen because the backends do not autoload. However,
> it is theoretically possible if someone loads a devicetree overlay and
> initiates via sysfs at the same time. I liked the solution with the
> bitfield and atomic access, but maybe a linked list is better?
> 
Wrt 10 bit addresses:
I didn't find a single dts(i) with a 10bit i2c device. Because you said
that you're tempted to remove 10 bit support: Could the device tree part
be a starting point?

> Happy hacking,
> 
>    Wolfram
> 
Heiner