On Sun, Apr 27, 2008 at 8:25 PM, Sean MacLennan <[EMAIL PROTECTED]> wrote: > On Sun, 27 Apr 2008 19:51:57 -0600 > "Grant Likely" <[EMAIL PROTECTED]> wrote: > > > Actually, it looks like he's trying to find the second gpio node in > > the tree. > > Correct. > > > > Sean, if that is true, then this is a very fragile way to do it. > > Really, you should have a phandle somewhere that points to the GPIO > > node that your LEDs are attached to. Others have been addressing the > > same problem and the consensus seems to be to add a 'leds' node for > > each of your leds with a phandle and gpio descriptor to the gpio node. > > > > See the documentation added by this patch (section 't'): > > http://patchwork.ozlabs.org/linuxppc/patch?id=18156 > > I saw that earlier. I thought that that method relied on the gpio_led > driver? I want to use the gpio_led driver, but I believe the underlying > gpio code for the 440EP is not done yet.
Something very important to remember: The device tree is simply a description of the hardware. Its layout *must* *not* be driven by device driver design. Driver design can and will change over time; hardware description conventions should be relatively stable. If your LEDs are attached to gpio pins, then you should use the current draft led->gpio bindings as shown in the above patch. Then, let your platform code extract whatever data it needs from the device tree to set up the LEDs. It is irrelevant that the 44EP GPIO driver doesn't support that binding. Just make sure that the warp platform code doesn't register warp's linux,gpio-led device tree nodes onto the of_platform bus. That way your platform code can do whatever it wants to handle the LEDs itself. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev