[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