I'm back in town. Sorry for the delay... > One thing where we need your help as a I2C maintainer is how to represent an > i2c slave device using device-tree. You may remember our discussion in the > past from here [1] where you suggested to just make a slave client by its > compatible name. Stephen Warren from NVIDIA raised some concerns about this > solution because it may not be appropriate in all possible future cases (which > is what a proper device-tree representation should take care off). He instead > suggested to mark a slave client by adding some flag to the reg property, to > be able to handle a situation where both master client and slave client have > the same i2c bus address forming a loopback (e.g. for testing purpose) on the > same bus. More details here [2]. Well... I can agree that we shouldn't prevent a loopback from a DT point of view. (Despite the fact that it is really for development and I wonder how many I2C IP cores can do this flawlessly) However, I am still against putting that information into the reg property. I see devices coming which have multiple addresses, so people somewhen want to encode this in DT as well. I'd like to have that a simple array of addresses. Adding flags, rarely used, will create a mess IMO. So what about adding a new property "i2c-slave-reg"? This does not only prevent the confusion above, but also makes it very clear that this node is an I2C slave without the need to encode that somehow in the compatible property (although it probably should be described there as well, still). > I hope with this post I can join the different discussions somehow so we are > able to find a common sense which is acceptable for all. Thanks for doing this! I changed the subject to maybe raise interest a bit more.
Attachment:
signature.asc
Description: Digital signature
