On Thu, Jul 17, 2008 at 9:20 AM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > On Thu, Jul 17, 2008 at 09:04:22AM -0600, Grant Likely wrote: >> On Thu, Jul 17, 2008 at 06:13:35PM +0400, Anton Vorontsov wrote: >> > On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote: >> > [...] >> > > > I think it would be better to have a module that scans the device tree >> > > > for LED nodes and registers a single leds-gpio platform device for the >> > > > whole lot. >> > > > >> > > > Thoughts? >> > > >> > > I like the idea, thanks. >> > >> > Ugh, no. The idea sounds good, but in practice it isn't, since we'll >> > have to handle suspend/resume ops ourselves. When we stick with the >> > device/driver model we're getting all this for free. >> >> Won't the leds-gpio driver give you suspend/resume support? > > Ah. I just wrongly read your message. You're purposing to use gpio > leds platform driver... I think this is doable, yes.
Alternately, I would also be okay with a scheme where all LED nodes have a common parent and an of_platform driver would bind against the parent node; not the individual children. Then the leds-gpio driver could be refactored to have both platform and of_platform bus bindings. 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
