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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
