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

Kumar Gala galak at kernel.crashing.org
Sat May 19 03:33:48 EST 2007


On May 18, 2007, at 12:17 PM, Scott Wood wrote:

> Kumar Gala wrote:
>> On May 18, 2007, at 11:35 AM, Scott Wood wrote:
>>> Kumar Gala wrote:
>>>
>>>> I guess my gripe is about proposing a solution and not willing  
>>>> to   extend it in light of people providing issues with it.
>>>
>>>
>>> I'm perfectly willing to extend it if you let me know what you   
>>> think is needed, rather than just saying "switches and muxes".    
>>> What *specifically* would they need beyond what I proposed?
>> I provided you an example device and asked you to explain how it   
>> would be described in what you are proposing.
>
> And I did.  What did you find lacking in the device tree fragment I  
> suggested?

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.

>> I never said don't bother because you didn't cover the switch/mux   
>> case.  I said don't bother because I don't see what the value is   
>> creating a namespace that no one is going to manage and thus will  
>> end  up most likely being linux specific, and linux already  
>> provides a  solution for the problem.
>
> 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.

>> 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?

- k



More information about the Linuxppc-dev mailing list