> Not if you define enough addresses in the pool. E.g. the DS90UB954 > hardware can have 8 aliases per port, so if you have (n_ports * 8) > addresses in the pool the problem is solved. And then you plug-in somewhere another board with another need for ATR and you are out of addresses. > > And another add-on module with > > non-repogrammable devices may occupy addresses from the defined pool > > above. > > You mean a new device on the local (SoC-to-ATR) bus? Well, it could as > well occupy a non-described address that the ATR has already picked as > an alias. Nope, I mean a seperate add-on which has a hardcoded I2C address on the bus of the ATR parent. Then this hardcoded address needs to be removed from the pool if it is in the wrong range. > > I am not perfectly happy with the assumption that all undescribed > > addresses are automatically free. That also might need DTS updates to > > describe all clients properly. But this change only needs to be done > > once, and it will improve the description of the hardware. > > Right, but I still suspect some users won't do their homework and > discover address conflicts at runtime, maybe months later, in a painful > way. Also a chip might be undocumented on a given board, so they could > do their homework and still have problems. Yes, we probably need a binding to mark an address as used even though we don't know the device or don't have a driver for it. Don't get me wrong, I know what you mean. One of my boards has a client soldered in a way so that it is still in debug mode. That means it listens to addresses 0x03-0x07 to provide debug information. Took me a while to find out what is happening there. But still, 'i2cdetect' showed all of these. > Despite my comments, I'm not strongly against your proposal. To me it > doesn't seem to solve any problem, while it does introduce some degree > of risk. Could you elaborate more on but what benefit it introduces? I'd think the risk of running out of defined addresses is somewhere equal to running into (after a while) an unexpectedly used address. I like the fix for the latter better because describing what is on the bus is more helpful and generic than updating the pool-property every time you need it. Plus, as mentioned above, other add-on hardware may disturb your pool allocation. I expect this topic to be one of the discussion points of the BoF.
Attachment:
signature.asc
Description: PGP signature
