Here are my patches for the OF bindings. The first is just a tiny change to
the leds code to silence a warning. The second is the real patch.
The leds-gpio driver gets two sub-options in Kconfig, one for platform
device support and one for openfirmware platform device support.
There is support
On Fri, Jul 18, 2008 at 02:20:42AM -0700, Trent Piepho wrote:
> On Fri, 18 Jul 2008, Anton Vorontsov wrote:
> > On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
> >> Basically what I did then in my patch then, refactor leds-gpio so most of
> >> it is shared and there is a block of code
On Fri, 18 Jul 2008, Anton Vorontsov wrote:
> On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
>> Basically what I did then in my patch then, refactor leds-gpio so most of
>> it is shared and there is a block of code that does platform binding and
>> another block that does of_platform
On Fri, Jul 18, 2008 at 03:42:01AM +0400, Anton Vorontsov wrote:
>
> So..
>
> Trent, I encourage you to collect your patch snippets into complete patch,
> and post it so it could slip into 2.6.27 (the bad thing is that your
> approach involves changes to the existing drivers, not just adding new
On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
> On Thu, 17 Jul 2008, Grant Likely wrote:
> > 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. T
On Tue, 2008-07-15 at 19:19 +0400, Anton Vorontsov wrote:
> + led->cdev.name = of_get_property(np, "label", NULL);
> + if (!led->cdev.name)
> + led->cdev.name = dev_name(&ofdev->dev);
How about also supporting a "trigger" property which would set
cdev.default_trigger in t
On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
> On Thu, 17 Jul 2008, Grant Likely wrote:
> > 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. T
On Thu, 17 Jul 2008, Grant Likely wrote:
> 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 a
On Thu, 17 Jul 2008, Anton Vorontsov wrote:
> On Wed, Jul 16, 2008 at 10:13:06PM -0700, Trent Piepho wrote:
>> Ok, how about adding code the existing leds-gpio driver so that it can
>> creates
>> LEDs from of_platform devices too?
>
> Few comments below.
>
>> I've made a patch to do this and it wo
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
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
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
> > >
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
On Wed, Jul 16, 2008 at 10:15:31PM -0600, Grant Likely wrote:
> On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> > On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> > > Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> > > is not much code can be shared between the t
On Wed, Jul 16, 2008 at 10:13:06PM -0700, Trent Piepho wrote:
> on Wed, 16 Jul 2008, Grant Likely wrote:
> > On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> >> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> >>> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> >>
on Wed, 16 Jul 2008, Grant Likely wrote:
> On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
>> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
>>> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
>>> is not much code can be shared between the two drivers (both are mostl
On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> > Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> > is not much code can be shared between the two drivers (both are mostly
> > driver bindings anyway).
>
> Why can'
On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> is not much code can be shared between the two drivers (both are mostly
> driver bindings anyway).
Why can't this driver use the existing gpio-led driver? Basically, do
something l
Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
is not much code can be shared between the two drivers (both are mostly
driver bindings anyway).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
- dropped Documentation/powerpc/ changes, since Kumar applied them via
pow
19 matches
Mail list logo
