Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.

[Scott Wood <scottwood@freescale.com>]

Kumar Gala wrote:
> Once you expand the beyond just a root node for the controller I'd  like 
> to see how you suggest we handle the case where a particular  child ends 
> up having children as well.  You example, is sufficient  the majority of 
> devices, but I'd like to know that we'll be able to  handle the case 
> where a node is both a device and controller.

The example I gave *was* a controller and an i2c device at the same time 
(note the i2c-style reg = <70>).  Just take the fragment and stick it in 
an existing i2c controller node; I omitted the latter for brevity, as a 
result of making the mistake of typing it in Mozilla rather than mutt, 
and thus having no autoindent.

>> Given that power.org is attempting to do further standardization of  
>> the device tree for embedded applications, I'd be surprised if  there 
>> weren't a way we could have them act as a registry.
> 
> If/when they sign up for this I'd be more inclined to have kernel  
> support for it.

Fair enough.  I'm still interested in what you think would need to be 
done to support switches and muxes, from the context of standardizing it 
in ePAPR.  The bus numbering shouldn't be an issue as long as you keep 
the bus numbers local to the switch/mux, and don't pretend that they 
have anything to do with any global i2c bus number that the OS may or 
may not have.

>>> For I2C specifically we already have both a dynamic way (kernel  cmd  
>>> line) and static (i2c_board_info) to specify the i2c devices,  why 
>>> do  we need yet another?
>>
>>
>> This uses i2c_board_info; it doesn't replace it.
> 
> 
> Ok, but what functionality does it give us that we dont already have  
> today?

The convenience of putting the data in a dts rather than in 
board-specific code/structs.  It's not a huge deal, but I find the 
former to be a more pleasant way of doing things, and others have 
similarly expressed interest in it.

It would be significantly more useful as an ePAPR standard that can be 
used by multiple OSes, but they seem to be in 
standardize-what-Linux-does mode, hence why I proposed it here first.

-Scott