Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards

["Grant Likely" <grant.likely@secretlab.ca>]

On Sun, Apr 27, 2008 at 8:25 PM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Sun, 27 Apr 2008 19:51:57 -0600
>  "Grant Likely" <grant.likely@secretlab.ca> 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.