stuff through my tree with the goal of
> .36 merge window just to minimize potential merge issues. This is a
> simple cleanup patch that has no dependencies, so there is little gain
> from doing it all in one go.
How about asking Linus to take this one now, then its done and we can
all mo
On Sun, 2009-01-11 at 04:58 -0800, Trent Piepho wrote:
> It doesn't seem right to merge someone's patches together, make a very
> small change, and then no longer credit them as the author. Seems like it
> defeats the purpose of the SOB lines for tracing the train of custody too.
> If someone look
On Sat, 2009-01-10 at 21:43 -0800, Trent Piepho wrote:
> On Sun, 11 Jan 2009, Richard Purdie wrote:
> > On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote:
> > > The LED tree makes more sense for what's left I think. There was a
> > > openfirmware gpio p
On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote:
> On Fri, 9 Jan 2009, Richard Purdie wrote:
> > On Fri, 2009-01-09 at 12:37 -0800, Trent Piepho wrote:
> > > On Fri, 9 Jan 2009, Richard Purdie wrote:
> > > > for the LED tree updates for 2.6.29.
On Sun, 2008-11-23 at 13:31 +0100, Pavel Machek wrote:
> On Thu 2008-11-20 17:05:56, Trent Piepho wrote:
> > On Mon, 17 Nov 2008, Richard Purdie wrote:
> > > On Fri, 2008-10-24 at 16:09 -0700, Trent Piepho wrote:
> > >> +if (template->keep_sta
On Fri, 2008-10-24 at 16:09 -0700, Trent Piepho wrote:
> Let GPIO LEDs get their initial value from whatever the current state of
> the GPIO line is. On some systems the LEDs are put into some state by the
> firmware or hardware before Linux boots, and it is desired to have them
> keep this state
On Tue, 2008-07-15 at 18:23 +0400, Anton Vorontsov wrote:
> > Spell out openfirmware :). I initially had no idea "of == openfirmware"
> > and I suspect others won't either...
>
> This would be unusually long name, that is
>
> $ find . -iname '*openfirmware*' | wc -l
> 0
>
> And in contrast:
>
>
On Tue, 2008-07-15 at 17:24 +0400, Anton Vorontsov wrote:
> On Tue, Jul 15, 2008 at 01:54:30PM +0100, Richard Purdie wrote:
> > I don't have any issue with the driver itself, just the name which is
> > going to confuse people no end.
> >
> > Can we come up wi
On Tue, 2008-07-15 at 16:40 +0400, Anton Vorontsov wrote:
> Despite leds-gpio and leds-of-gpio similar names and purposes, there
> is not much code can be shared between the two drivers (both are mostly
> driver bindings anyway).
I don't have any issue with the driver itself, just the name which i
On Mon, 2008-04-28 at 17:24 -0400, Sean MacLennan wrote:
> On Mon, 28 Apr 2008 21:44:05 +0100
> "Richard Purdie" <[EMAIL PROTECTED]> wrote:
>
> > You can leave sections blank but it pays to leave the separator in so
> > use ":red:" or ":red"
x LED naming guidelines. I think
> > this is covered in Documentation/leds-class.c. You can also as
> > Richard Purdie; the LED subsystem maintainer.
>
> The leds name is "devicename:colour:function" where you are allowed to
> leave sections blank. So I only fille
On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
> > Grant,
> >
> > Yes, the Motion-PRO LED driver has been reworked and posted:
> > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
> Okay, I'
; http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
> > I need to look at it again,
> > but it is a lot of code for a very simple thing and I wasn't sure if I
> > should be the one to pick it up because it is in drivers/leds which
> > has a differen
13 matches
Mail list logo
