How to encode being an I2C slave in DT?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux