On 2016-07-28 11:39, Peter Rosin wrote: > 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). Ok, I see what they are doing. They register a slave device AND a driver and then they are able to communicate with themselves since the adapter supports loopback. But that seems like the odd case which is not really useful for anything but debugging (or maybe for cases where other code expects an i2c device that is then emulated this way). If you really have a separate device on the bus with the same address that you want to add slave support for, then there really is a conflict, and the kernel knows it. I think it would be nice if such mistakes were prevented. Agreed? After all, the kernel prevents other obvious i2c address conflicts and consistency is nice. 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
