* Re: [GIT PULL] LED updates for 2.6.29
@ 2009-01-11 0:33 ` Richard Purdie
0 siblings, 0 replies; 18+ messages in thread
From: Richard Purdie @ 2009-01-11 0:33 UTC (permalink / raw)
To: Trent Piepho
Cc: linuxppc-dev, Andrew Morton, Guennadi Liakhovetski, Linus Torvalds, LKML
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. This includes some new drivers,
> > > > bugfixes and a core improvement resulting in nicer code.
> > > >
> > >
> > > Any chance of these patches getting accepted? They've been going back and
> > > forth for months now.
> > >
> > > [v2,1/4] leds: Support OpenFirmware led bindings
> > > http://patchwork.ozlabs.org/patch/13581/
> > >
> > > [v2,2/4] leds: Add option to have GPIO LEDs start on
> > > http://patchwork.ozlabs.org/patch/13580/
> > >
> > > [v2,3/4] leds: Let GPIO LEDs keep their current state
> > > http://patchwork.ozlabs.org/patch/13583/
> > >
> > > [v2,4/4] leds: Use tristate property in platform data
> > > http://patchwork.ozlabs.org/patch/13584/
> >
> > I think there was some confusion as to who was going to take them. Are
> > the PPC people happy with them? If so I'll merge through the LED tree.
> > There are these and a couple of other patches around which have got lost
> > in the system. If there is time which I'm hoping there might be, I'll
> > try and get a second LED tree merge in.
>
> The LED tree makes more sense for what's left I think. There was a
> openfirmware gpio patch, but that's already gone in. What's left only
> touches led files and the device tree binding docs.
>
> AFAIK, there were no objections to the patches left.
Ok, these are now queued in the LED tree:
http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
I did merge the last three patches in one and make some changes to deal
with some other outstanding issues. Let me know ASAP if there are any
problems.
Cheers,
Richard
--
Richard Purdie
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
2009-01-11 0:33 ` Richard Purdie
@ 2009-01-11 1:20 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 18+ messages in thread
From: Guennadi Liakhovetski @ 2009-01-11 1:20 UTC (permalink / raw)
To: Richard Purdie
Cc: Trent Piepho, Linus Torvalds, Andrew Morton, LKML, linuxppc-dev
On Sun, 11 Jan 2009, Richard Purdie wrote:
> Ok, these are now queued in the LED tree:
>
> http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
>
> I did merge the last three patches in one and make some changes to deal
> with some other outstanding issues. Let me know ASAP if there are any
> problems.
As already replied off-list, looks good mostly to me. Just have to keep in
mind, that this version relies on drivers initialising their struct
led_classdev instances to 0. Maybe it would be better to set the new
max_brightness to 0 (or to LED_FULL) explicitly for them, as I was doing
in my v2 of the patch.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
@ 2009-01-11 1:20 ` Guennadi Liakhovetski
0 siblings, 0 replies; 18+ messages in thread
From: Guennadi Liakhovetski @ 2009-01-11 1:20 UTC (permalink / raw)
To: Richard Purdie
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, Trent Piepho, LKML
On Sun, 11 Jan 2009, Richard Purdie wrote:
> Ok, these are now queued in the LED tree:
>
> http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
>
> I did merge the last three patches in one and make some changes to deal
> with some other outstanding issues. Let me know ASAP if there are any
> problems.
As already replied off-list, looks good mostly to me. Just have to keep in
mind, that this version relies on drivers initialising their struct
led_classdev instances to 0. Maybe it would be better to set the new
max_brightness to 0 (or to LED_FULL) explicitly for them, as I was doing
in my v2 of the patch.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
2009-01-11 0:33 ` Richard Purdie
@ 2009-01-11 5:43 ` Trent Piepho
-1 siblings, 0 replies; 18+ messages in thread
From: Trent Piepho @ 2009-01-11 5:43 UTC (permalink / raw)
To: Richard Purdie
Cc: Linus Torvalds, Andrew Morton, LKML, Guennadi Liakhovetski, linuxppc-dev
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 patch, but that's already gone in. What's left only
> > touches led files and the device tree binding docs.
> >
> > AFAIK, there were no objections to the patches left.
>
> Ok, these are now queued in the LED tree:
>
> http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
>
> I did merge the last three patches in one and make some changes to deal
> with some other outstanding issues. Let me know ASAP if there are any
> problems.
Since the last patch looks like it's just my three patches folded into one,
shouldn't I be listed as the author and the primary signed off by?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
@ 2009-01-11 5:43 ` Trent Piepho
0 siblings, 0 replies; 18+ messages in thread
From: Trent Piepho @ 2009-01-11 5:43 UTC (permalink / raw)
To: Richard Purdie
Cc: linuxppc-dev, Andrew Morton, Guennadi Liakhovetski, Linus Torvalds, LKML
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 patch, but that's already gone in. What's left only
> > touches led files and the device tree binding docs.
> >
> > AFAIK, there were no objections to the patches left.
>
> Ok, these are now queued in the LED tree:
>
> http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
>
> I did merge the last three patches in one and make some changes to deal
> with some other outstanding issues. Let me know ASAP if there are any
> problems.
Since the last patch looks like it's just my three patches folded into one,
shouldn't I be listed as the author and the primary signed off by?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
2009-01-11 5:43 ` Trent Piepho
@ 2009-01-11 11:49 ` Richard Purdie
-1 siblings, 0 replies; 18+ messages in thread
From: Richard Purdie @ 2009-01-11 11:49 UTC (permalink / raw)
To: Trent Piepho
Cc: Linus Torvalds, Andrew Morton, LKML, Guennadi Liakhovetski, linuxppc-dev
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 patch, but that's already gone in. What's left only
> > > touches led files and the device tree binding docs.
> > >
> > > AFAIK, there were no objections to the patches left.
> >
> > Ok, these are now queued in the LED tree:
> >
> > http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
> >
> > I did merge the last three patches in one and make some changes to deal
> > with some other outstanding issues. Let me know ASAP if there are any
> > problems.
>
> Since the last patch looks like it's just my three patches folded into one,
> shouldn't I be listed as the author and the primary signed off by?
I made changes other than just merging the three together (the
syspend/resume change and the bitfield parts in leds.h) so putting you
as signed off by/authorship would not have been "correct" and I credited
you in the commit message instead. I wanted to get the missing patches
queued ASAP so I went with the way that does fit in the rules as you'd
not have been happy if a modified patch was attributed to you. I'll put
you as author and a signoff if you confirm thats acceptable.
Cheers,
Richard
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
@ 2009-01-11 11:49 ` Richard Purdie
0 siblings, 0 replies; 18+ messages in thread
From: Richard Purdie @ 2009-01-11 11:49 UTC (permalink / raw)
To: Trent Piepho
Cc: linuxppc-dev, Andrew Morton, Guennadi Liakhovetski, Linus Torvalds, LKML
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 patch, but that's already gone in. What's left only
> > > touches led files and the device tree binding docs.
> > >
> > > AFAIK, there were no objections to the patches left.
> >
> > Ok, these are now queued in the LED tree:
> >
> > http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
> >
> > I did merge the last three patches in one and make some changes to deal
> > with some other outstanding issues. Let me know ASAP if there are any
> > problems.
>
> Since the last patch looks like it's just my three patches folded into one,
> shouldn't I be listed as the author and the primary signed off by?
I made changes other than just merging the three together (the
syspend/resume change and the bitfield parts in leds.h) so putting you
as signed off by/authorship would not have been "correct" and I credited
you in the commit message instead. I wanted to get the missing patches
queued ASAP so I went with the way that does fit in the rules as you'd
not have been happy if a modified patch was attributed to you. I'll put
you as author and a signoff if you confirm thats acceptable.
Cheers,
Richard
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
2009-01-11 11:49 ` Richard Purdie
@ 2009-01-11 12:58 ` Trent Piepho
-1 siblings, 0 replies; 18+ messages in thread
From: Trent Piepho @ 2009-01-11 12:58 UTC (permalink / raw)
To: Richard Purdie
Cc: Linus Torvalds, Andrew Morton, LKML, Guennadi Liakhovetski, linuxppc-dev
On Sun, 11 Jan 2009, Richard Purdie wrote:
> 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 patch, but that's already gone in. What's left only
> > > > touches led files and the device tree binding docs.
> > > >
> > > > AFAIK, there were no objections to the patches left.
> > >
> > > Ok, these are now queued in the LED tree:
> > >
> > > http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
> > >
> > > I did merge the last three patches in one and make some changes to deal
> > > with some other outstanding issues. Let me know ASAP if there are any
> > > problems.
> >
> > Since the last patch looks like it's just my three patches folded into one,
> > shouldn't I be listed as the author and the primary signed off by?
>
> I made changes other than just merging the three together (the
> syspend/resume change and the bitfield parts in leds.h) so putting you
> as signed off by/authorship would not have been "correct" and I credited
> you in the commit message instead. I wanted to get the missing patches
> queued ASAP so I went with the way that does fit in the rules as you'd
> not have been happy if a modified patch was attributed to you. I'll put
> you as author and a signoff if you confirm thats acceptable.
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 looks to see where the code came from, it will look like you
wrote it. Maybe Freescale will say Intel stole our code? Without the SOB,
what record is there in git that Freescale gave permission to put the code
in the kernel?
I also put some significant effort into writing informative commit
messages, which have been lost. Along with Grant's acks for my patches.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
@ 2009-01-11 12:58 ` Trent Piepho
0 siblings, 0 replies; 18+ messages in thread
From: Trent Piepho @ 2009-01-11 12:58 UTC (permalink / raw)
To: Richard Purdie
Cc: linuxppc-dev, Andrew Morton, Guennadi Liakhovetski, Linus Torvalds, LKML
On Sun, 11 Jan 2009, Richard Purdie wrote:
> 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 patch, but that's already gone in. What's left only
> > > > touches led files and the device tree binding docs.
> > > >
> > > > AFAIK, there were no objections to the patches left.
> > >
> > > Ok, these are now queued in the LED tree:
> > >
> > > http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/
> > >
> > > I did merge the last three patches in one and make some changes to deal
> > > with some other outstanding issues. Let me know ASAP if there are any
> > > problems.
> >
> > Since the last patch looks like it's just my three patches folded into one,
> > shouldn't I be listed as the author and the primary signed off by?
>
> I made changes other than just merging the three together (the
> syspend/resume change and the bitfield parts in leds.h) so putting you
> as signed off by/authorship would not have been "correct" and I credited
> you in the commit message instead. I wanted to get the missing patches
> queued ASAP so I went with the way that does fit in the rules as you'd
> not have been happy if a modified patch was attributed to you. I'll put
> you as author and a signoff if you confirm thats acceptable.
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 looks to see where the code came from, it will look like you
wrote it. Maybe Freescale will say Intel stole our code? Without the SOB,
what record is there in git that Freescale gave permission to put the code
in the kernel?
I also put some significant effort into writing informative commit
messages, which have been lost. Along with Grant's acks for my patches.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
2009-01-11 12:58 ` Trent Piepho
@ 2009-01-11 13:39 ` Richard Purdie
-1 siblings, 0 replies; 18+ messages in thread
From: Richard Purdie @ 2009-01-11 13:39 UTC (permalink / raw)
To: Trent Piepho
Cc: Linus Torvalds, Andrew Morton, LKML, Guennadi Liakhovetski, linuxppc-dev
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 looks to see where the code came from, it will look like you
> wrote it. Maybe Freescale will say Intel stole our code? Without the SOB,
> what record is there in git that Freescale gave permission to put the code
> in the kernel?
>
> I also put some significant effort into writing informative commit
> messages, which have been lost. Along with Grant's acks for my patches.
It also doesn't make sense to make three changes adding different
interfaces and rearranging the same section of code three different
times. I'm dropping the patch, please send me a merged version of those
patches with a commit message you're happy with. If you want Acked-by
lines, we'll have to wait for them on the new patch as I'm going to do
this exactly by the book regardless of time pressures now. Please
indicate who you want Ack-ed by lines from so I know who to wait for.
Also, you'd better exclude the suspend/resume change and credit me for
the bitfield change, just to be 100% sure this is all legally accurate.
Regards,
Richard
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL] LED updates for 2.6.29
@ 2009-01-11 13:39 ` Richard Purdie
0 siblings, 0 replies; 18+ messages in thread
From: Richard Purdie @ 2009-01-11 13:39 UTC (permalink / raw)
To: Trent Piepho
Cc: linuxppc-dev, Andrew Morton, Guennadi Liakhovetski, Linus Torvalds, LKML
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 looks to see where the code came from, it will look like you
> wrote it. Maybe Freescale will say Intel stole our code? Without the SOB,
> what record is there in git that Freescale gave permission to put the code
> in the kernel?
>
> I also put some significant effort into writing informative commit
> messages, which have been lost. Along with Grant's acks for my patches.
It also doesn't make sense to make three changes adding different
interfaces and rearranging the same section of code three different
times. I'm dropping the patch, please send me a merged version of those
patches with a commit message you're happy with. If you want Acked-by
lines, we'll have to wait for them on the new patch as I'm going to do
this exactly by the book regardless of time pressures now. Please
indicate who you want Ack-ed by lines from so I know who to wait for.
Also, you'd better exclude the suspend/resume change and credit me for
the bitfield change, just to be 100% sure this is all legally accurate.
Regards,
Richard
^ permalink raw reply [flat|nested] 18+ messages in thread