[GIT PULL] LED updates for 2.6.29

[GIT PULL] LED updates for 2.6.29

[Richard Purdie]

Linus,

Could you please pull from:

git://git.o-hand.com/linux-rpurdie-leds for-linus

for the LED tree updates for 2.6.29. This includes some new drivers,
bugfixes and a core improvement resulting in nicer code.

Thanks, Richard

 drivers/leds/Kconfig                 |   15 +
 drivers/leds/Makefile                |    2 
 drivers/leds/led-class.c             |   24 ++
 drivers/leds/leds-alix2.c            |  181 ++++++++++++++++++++
 drivers/leds/leds-ams-delta.c        |   33 ---
 drivers/leds/leds-clevo-mail.c       |   21 --
 drivers/leds/leds-fsg.c              |   37 ----
 drivers/leds/leds-gpio.c             |   36 ----
 drivers/leds/leds-hp-disk.c          |   20 --
 drivers/leds/leds-hp6xx.c            |   22 --
 drivers/leds/leds-net48xx.c          |   21 --
 drivers/leds/leds-pca9532.c          |   77 ++++++--
 drivers/leds/leds-s3c24xx.c          |   25 --
 drivers/leds/leds-wm8350.c           |  311 +++++++++++++++++++++++++++++++++++
 drivers/leds/leds-wrap.c             |   27 ---
 drivers/leds/ledtrig-timer.c         |    5 
 drivers/mfd/wm8350-core.c            |    3 
 drivers/regulator/wm8350-regulator.c |   91 ++++++++++
 include/linux/leds-pca9532.h         |    2 
 include/linux/leds.h                 |    5 
 include/linux/mfd/wm8350/pmic.h      |   36 ++++
 21 files changed, 749 insertions(+), 245 deletions(-)

Constantin Baranov (1):
      leds: ALIX.2 LEDs driver

Mark Brown (1):
      leds: Add WM8350 LED driver

Richard Purdie (1):
      leds: Add suspend/resume to the core class

Riku Voipio (1):
      leds: leds-pcs9532 - Move i2c work to a workqueque

Rodolfo Giometti (1):
      leds: ledtrig-timer - on deactivation hardware blinking should be disabled

Sven Wegener (5):
      leds: eds-pca9532: mark pca9532_event() static
      leds: Fixup kdoc comment to match parameter names
      leds: Fix sparse warning in leds-ams-delta
      leds: Fix wrong loop direction on removal in leds-ams-delta
      leds: leds-pca9532 - fix memory leak and properly handle errors

Wolfram Sang (1):
      leds: Make header variable naming consistent

Yoichi Yuasa (1):
      leds: fix Cobalt Raq LED dependency


-- 
Richard Purdie
Intel Open Source Technology Centre

Re: [GIT PULL] LED updates for 2.6.29

[Trent Piepho]

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/

Re: [GIT PULL] LED updates for 2.6.29

[Richard Purdie]

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.

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre

Re: [GIT PULL] LED updates for 2.6.29

[Trent Piepho]

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.

Re: [GIT PULL] LED updates for 2.6.29

[Trent Piepho]

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.

Re: [GIT PULL] LED updates for 2.6.29

[Richard Purdie]

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

Re: [GIT PULL] LED updates for 2.6.29

[Richard Purdie]

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

Re: [GIT PULL] LED updates for 2.6.29

[Grant Likely]

On Fri, Jan 9, 2009 at 4:19 PM, Richard Purdie <rpurdie@rpsys.net> 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.

I'm cool with them going in from the ppc side.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [GIT PULL] LED updates for 2.6.29

[Guennadi Liakhovetski]

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

Re: [GIT PULL] LED updates for 2.6.29

[Guennadi Liakhovetski]

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

Re: [GIT PULL] LED updates for 2.6.29

[Trent Piepho]

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?

Re: [GIT PULL] LED updates for 2.6.29

[Trent Piepho]

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?

Re: [GIT PULL] LED updates for 2.6.29

[Richard Purdie]

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

Re: [GIT PULL] LED updates for 2.6.29

[Richard Purdie]

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

Re: [GIT PULL] LED updates for 2.6.29

[Trent Piepho]

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.

Re: [GIT PULL] LED updates for 2.6.29

[Trent Piepho]

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.

Re: [GIT PULL] LED updates for 2.6.29

[Richard Purdie]

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

Re: [GIT PULL] LED updates for 2.6.29

[Richard Purdie]

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