Re: i2c: slave support framework improvements

[Peter Rosin <peda@axentia.se>]

On 2016-07-28 11:15, Wolfram Sang wrote:
> 
>> What I mean is that it is possible to have an i2c bus with some random
>> i2c device at e.g. address 0x48, say some eeprom, and then register to
>> be a slave device also at address 0x48, e.g. slave-24c02. If there is
>> another master on the bus, it cannot sanely use any of these two devices
>> at i2c address 0x48 since there is an address conflict.
> 
> That is an address conflict, yes. Even for a single-master system. You
> need to make sure your slave address is unique on the bus. The kernel
> can't really help you with that, because it could only detect address
> conflicts if a driver would be attached to a device. If there is no
> driver and all communication is done via i2c-dev, for example, then
> I can't see a way to detect this.

Why do you talk about i2c-dev and other random i2c accesses?

I don't see where the conflict is prevented even if everything is
registered properly with in-kernel drivers, and it looks trivial to
prevent. Just stop accounting for the I2C_CLIENT_SLAVE flag when
comparing addresses would fix it, I think. I also don't see how the
tegra loopback has anything to do with this. Or rather, it has
everything to do with this. Because that actually makes this a
problem even without another master on the bus (but then registering
as a slave makes no sense, but that's beside the point).

Cheers,
Peter