[GIT PULL] LED updates

[GIT PULL] LED updates

[Richard Purdie]

Hi Linus,

Could you please pull from:

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

This adds two new LED drivers (in my capacity as LEDs maintainer).

Thanks,

Richard

 drivers/leds/Kconfig       |   12 +++
 drivers/leds/Makefile      |    2
 drivers/leds/leds-cobalt.c |   43 +++++++++++
 drivers/leds/leds-h1940.c  |  163
+++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 220 insertions(+)

Arnaud Patard (1):
      leds: Add IPAQ h1940 LEDs support

Florian Fainelli (1):
      leds: Add support for Cobalt Server front LED

[GIT PULL] LED updates

[Richard Purdie]

Hi Linus,

Could you please pull from:

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

This adds a couple of new LED drivers and converts the LED class away
from struct class_device as well as some bug fixes. Most of this has
been in -mm for a while.

Thanks,

Richard

 arch/avr32/boards/atngw100/setup.c    |   31 +++++
 arch/avr32/configs/atngw100_defconfig |   16 ++
 drivers/leds/Kconfig                  |   22 ++-
 drivers/leds/Makefile                 |    1 
 drivers/leds/led-class.c              |   49 +++-----
 drivers/leds/led-triggers.c           |   27 +++-
 drivers/leds/leds-gpio.c              |  199 ++++++++++++++++++++++++++++++++++
 drivers/leds/leds-locomo.c            |    2 
 drivers/leds/leds.h                   |    8 -
 drivers/leds/ledtrig-timer.c          |   49 +++-----
 include/linux/leds.h                  |   17 ++
 11 files changed, 343 insertions(+), 78 deletions(-)

David Brownell (2):
      leds: Teach leds-gpio to handle timer-unsafe GPIOs
      leds: leds-gpio for ngw100

Jan Engelhardt (1):
      leds: Use menuconfig objects II - LED

Raphael Assenat (1):
      leds: Add generic GPIO LED driver

Richard Purdie (3):
      leds: Fix trigger unregister_simple if register_simple fails
      leds: Add warning printks in error paths
      leds: Convert from struct class_device to struct device

[GIT PULL] LED updates

[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.24. Just some changes to the cobalt
driver really.

Thanks, Richard

 drivers/leds/Kconfig            |   13 ++-
 drivers/leds/Makefile           |    3 
 drivers/leds/leds-cobalt-qube.c |  102 +++++++++++++++++++++++++++++
 drivers/leds/leds-cobalt-raq.c  |  138 ++++++++++++++++++++++++++++++++++++++++
 drivers/leds/leds-cobalt.c      |   43 ------------
 5 files changed, 252 insertions(+), 47 deletions(-)

Yoichi Yuasa (3):
      leds: Rename leds-cobalt driver
      leds: Add Cobalt Raq series LEDs support
      leds: Update Cobalt Qube series front LED support

[GIT PULL] LED updates

[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.25. This includes a couple of new
drivers, removal of a now superseded driver, some extensions to some
existing drivers and some LED class enhancements/bugfixes. Most of this
has been testing in -mm for quite a while.

Thanks, Richard

 Documentation/leds-class.txt         |   29 +++-
 arch/arm/mach-ixp4xx/dsmg600-setup.c |    4 
 arch/arm/mach-ixp4xx/nas100d-setup.c |    6 
 arch/arm/mach-ixp4xx/nslu2-setup.c   |    8 -
 drivers/hwmon/applesmc.c             |    2 
 drivers/input/misc/wistron_btns.c    |    4 
 drivers/leds/Kconfig                 |   48 ++++++-
 drivers/leds/Makefile                |    3 
 drivers/leds/leds-ams-delta.c        |   12 -
 drivers/leds/leds-clevo-mail.c       |  219 +++++++++++++++++++++++++++++++++++
 drivers/leds/leds-corgi.c            |    4 
 drivers/leds/leds-gpio.c             |    2 
 drivers/leds/leds-hp6xx.c            |  120 +++++++++++++++++++
 drivers/leds/leds-ixp4xx-gpio.c      |  214 ----------------------------------
 drivers/leds/leds-locomo.c           |    4 
 drivers/leds/leds-net48xx.c          |    2 
 drivers/leds/leds-spitz.c            |    8 -
 drivers/leds/leds-tosa.c             |    4 
 drivers/leds/leds-wrap.c             |   47 ++++++-
 drivers/leds/ledtrig-timer.c         |   41 +++++-
 drivers/misc/asus-laptop.c           |    2 
 drivers/net/wireless/b43/leds.c      |    8 -
 include/linux/leds.h                 |    5 
 23 files changed, 519 insertions(+), 277 deletions(-)

Kristoffer Ericson (1):
      leds: Add HP Jornada 6xx driver

Michael Loeffler (1):
      leds: Add power LED to the wrap driver

Márton Németh (3):
      leds: Add clevo notebook LED driver
      leds: Add support for hardware accelerated LED flashing
      leds: hw acceleration for Clevo mail LED driver

Raphael Assenat (1):
      leds: Fix led-gpio active_low default brightness

Richard Purdie (1):
      leds: Standardise LED naming scheme

Rod Whitby (1):
      leds: Remove the now uneeded ixp4xx driver

Re: [GIT PULL] LED updates

[Henrique de Moraes Holschuh]

On Thu, 07 Feb 2008, Richard Purdie wrote:
> Márton Németh:
>       leds: Add support for hardware accelerated LED flashing
>       leds: hw acceleration for Clevo mail LED driver

This one has a loose end: when you call brightness_set on a led with
hardware flash acceleration, you will leave the trigger armed, BUT the led
won't blink anymore.  That's just wrong.

Either we should always remove *any* (hardware accelerated or not!) active
trigger when a write to brightness_set is done, or the stuff about "calling
brightness_set will disable the hardware accelerated blink" has to go.

I personally prefer that we would always remove any active trigger if
brightness_set is to be called.  IMHO, it is neater, and it is also the
least-surprise-behaviour from an user perspective with the LED_OFF:LED_FULL
triggers we have right now.

Which one will be?  If it is "remove any active trigger", I'd not mind
writing the patch.

> Richard Purdie:
>       leds: Standardise LED naming scheme

This one causes trouble (at least on 2.6.23 -- I backported the patch) due
to the 20-byte length limit on sysfs names.  I had to use "tp::<somecrap>"
instead of "thinkpad::<somecrap>" to name LEDs, and still had to reduce
ultrabase_battery to ultrabase_batt :-)

Anyway, IMHO, the LED function should come first, and we should not even
need the led driver name anywhere.  In case of clashes in the class sysfs
dir, just tack a .# to the end or somesuch.  The device the LED is tied to
already differentiates them.  That would save a lot of chars for something
much more useful (the function).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [GIT PULL] LED updates

[Richard Purdie]

On Thu, 2008-02-07 at 19:38 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 07 Feb 2008, Richard Purdie wrote:
> > Márton Németh:
> >       leds: Add support for hardware accelerated LED flashing
> >       leds: hw acceleration for Clevo mail LED driver
> 
> This one has a loose end: when you call brightness_set on a led with
> hardware flash acceleration, you will leave the trigger armed, BUT the led
> won't blink anymore.  That's just wrong.

Agreed.

> Either we should always remove *any* (hardware accelerated or not!) active
> trigger when a write to brightness_set is done, or the stuff about "calling
> brightness_set will disable the hardware accelerated blink" has to go.
> 
> I personally prefer that we would always remove any active trigger if
> brightness_set is to be called.  IMHO, it is neater, and it is also the
> least-surprise-behaviour from an user perspective with the LED_OFF:LED_FULL
> triggers we have right now.

Even without the hardware acceleration, a user write to set_brightness
leaves any active trigger active and isn't really intuitive or right
either. 

> Which one will be?  If it is "remove any active trigger", I'd not mind
> writing the patch.

I'll accept a patch for that :).

> > Richard Purdie:
> >       leds: Standardise LED naming scheme
> 
> This one causes trouble (at least on 2.6.23 -- I backported the patch) due
> to the 20-byte length limit on sysfs names.  I had to use "tp::<somecrap>"
> instead of "thinkpad::<somecrap>" to name LEDs, and still had to reduce
> ultrabase_battery to ultrabase_batt :-)
> 
> Anyway, IMHO, the LED function should come first, and we should not even
> need the led driver name anywhere.  In case of clashes in the class sysfs
> dir, just tack a .# to the end or somesuch.  The device the LED is tied to
> already differentiates them.  That would save a lot of chars for something
> much more useful (the function).

Ouch, I'm looking into this. I wish I'd known about it earlier. I agree
function is more important but didn't want to break the existing
convention. I guess this limitation comes from the kobjects involved...

Richard

Re: [GIT PULL] LED updates

[Németh Márton]

Richard Purdie wrote:
> On Thu, 2008-02-07 at 19:38 -0200, Henrique de Moraes Holschuh wrote:
>> On Thu, 07 Feb 2008, Richard Purdie wrote:
>>> Márton Németh:
>>>       leds: Add support for hardware accelerated LED flashing
>>>       leds: hw acceleration for Clevo mail LED driver
>> This one has a loose end: when you call brightness_set on a led with
>> hardware flash acceleration, you will leave the trigger armed, BUT the led
>> won't blink anymore.  That's just wrong.
> 
> Agreed.

My only question is that do you know any LED hardware which can blink _and_
can set the brightness independently? If there would be such a LED I could
imagine that the brightness can be changed while the LED remains blinking at
some low frequency. For example a simple LED with brightness set possibility and
blinking directed by software is an example where the blinking and the brightness
setting are completely independent.

I agree, however, that if the brightness is set to LED_OFF, the trigger
should be also removed.

>> Either we should always remove *any* (hardware accelerated or not!) active
>> trigger when a write to brightness_set is done, or the stuff about "calling
>> brightness_set will disable the hardware accelerated blink" has to go.
>>
>> I personally prefer that we would always remove any active trigger if
>> brightness_set is to be called.  IMHO, it is neater, and it is also the
>> least-surprise-behaviour from an user perspective with the LED_OFF:LED_FULL
>> triggers we have right now.
> 
> Even without the hardware acceleration, a user write to set_brightness
> leaves any active trigger active and isn't really intuitive or right
> either. 
> 
>> Which one will be?  If it is "remove any active trigger", I'd not mind
>> writing the patch.

Re: [GIT PULL] LED updates

[Henrique de Moraes Holschuh]

On Fri, 08 Feb 2008, Németh Márton wrote:
> Richard Purdie wrote:
> >>>       leds: Add support for hardware accelerated LED flashing
> >> This one has a loose end: when you call brightness_set on a led with
> >> hardware flash acceleration, you will leave the trigger armed, BUT the led
> >> won't blink anymore.  That's just wrong.
> > 
> > Agreed.
> 
> My only question is that do you know any LED hardware which can blink _and_
> can set the brightness independently? If there would be such a LED I could

Several, but none on laptops or other stuff that runs Linux.  That behaviour
is not common on indicator LEDs.  I have seen standby LEDs on laptops which
"blink" by slowly fading from full to off, and then back to full, though.

> imagine that the brightness can be changed while the LED remains blinking at
> some low frequency. For example a simple LED with brightness set possibility and
> blinking directed by software is an example where the blinking and the brightness
> setting are completely independent.

Sure, it is perfectly possible.  I am not sure it is *desireable*, though.
The way we have triggers work make what you describe impossible right now,
the software triggers are LED_OFF:LED_FULL, not LED_OFF:old-brightness.

And so are the common hardware triggers on laptops, for that matter.

If we go and fix every trigger to use the current brightness (as long as it
is non-zero) as the "turn LED on" trigger event, then the documentation has
to be changed accordingly to do what you said above, and we would stop the
trigger only by setting brightness to zero or by explicitly removing it.

I don't think it is worth the hassle, though.  But we better decide that
*now*, because all this changing of the LED class ABI (even if it is, IMHO,
a big improvement) is not a good idea.  We better do it all during the
2.6.25 cycle.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [GIT PULL] LED updates

[Németh Márton]

Henrique de Moraes Holschuh wrote:
> On Fri, 08 Feb 2008, Németh Márton wrote:
>> Richard Purdie wrote:
>>>>>       leds: Add support for hardware accelerated LED flashing
>>>> This one has a loose end: when you call brightness_set on a led with
>>>> hardware flash acceleration, you will leave the trigger armed, BUT the led
>>>> won't blink anymore.  That's just wrong.
>>> Agreed.
>> My only question is that do you know any LED hardware which can blink _and_
>> can set the brightness independently? If there would be such a LED I could
> 
> Several, but none on laptops or other stuff that runs Linux.  That behaviour
> is not common on indicator LEDs.  I have seen standby LEDs on laptops which
> "blink" by slowly fading from full to off, and then back to full, though.
> 
>> imagine that the brightness can be changed while the LED remains blinking at
>> some low frequency. For example a simple LED with brightness set possibility and
>> blinking directed by software is an example where the blinking and the brightness
>> setting are completely independent.
> 
> Sure, it is perfectly possible.  I am not sure it is *desireable*, though.
> The way we have triggers work make what you describe impossible right now,
> the software triggers are LED_OFF:LED_FULL, not LED_OFF:old-brightness.
> 
> And so are the common hardware triggers on laptops, for that matter.
> 
> If we go and fix every trigger to use the current brightness (as long as it
> is non-zero) as the "turn LED on" trigger event, then the documentation has
> to be changed accordingly to do what you said above, and we would stop the
> trigger only by setting brightness to zero or by explicitly removing it.
> 
> I don't think it is worth the hassle, though.  But we better decide that
> *now*, because all this changing of the LED class ABI (even if it is, IMHO,
> a big improvement) is not a good idea.  We better do it all during the
> 2.6.25 cycle.

I investigated what would have to be changed if we decide that the
brightness and the blinking parameters can be set independently. There
are not much too change I think, please have a look at my next mail.

	Márton Németh

Re: [GIT PULL] LED updates

[Henrique de Moraes Holschuh]

On Thu, 07 Feb 2008, Richard Purdie wrote:
> > > Richard Purdie:
> > >       leds: Standardise LED naming scheme
> > 
> > This one causes trouble (at least on 2.6.23 -- I backported the patch) due
> > to the 20-byte length limit on sysfs names.  I had to use "tp::<somecrap>"
> > instead of "thinkpad::<somecrap>" to name LEDs, and still had to reduce
> > ultrabase_battery to ultrabase_batt :-)
> > 
> > Anyway, IMHO, the LED function should come first, and we should not even
> > need the led driver name anywhere.  In case of clashes in the class sysfs
> > dir, just tack a .# to the end or somesuch.  The device the LED is tied to
> > already differentiates them.  That would save a lot of chars for something
> > much more useful (the function).
> 
> Ouch, I'm looking into this. I wish I'd known about it earlier. I agree
> function is more important but didn't want to break the existing
> convention. I guess this limitation comes from the kobjects involved...

Richard, any ideas for that?  It *is* still time to change this for 2.6.25,
if required.  If you changed it once already, changing it again won't cause
further damage.

I need to know if the current naming scheme will hold or not, I do NOT want
an ABI issue on thinkpad-acpi, and I know for a fact at least Debian will
want to use the thinkpad-acpi LED interface as soon as I deploy it.  I want
to send the thinkpad-acpi LED interface patches to the users as soon as
possible.

Sincerely?  I think you should make it <function>:[color][.instance] and
drop device name compleley, ASAP.

I will write the patches for mainline and your for-mm branch, if that would
speed up things.  But I need to know what you have decided, first.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [GIT PULL] LED updates

[Richard Purdie]

On Sun, 2008-03-16 at 15:18 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 07 Feb 2008, Richard Purdie wrote:
> > > This one causes trouble (at least on 2.6.23 -- I backported the patch) due
> > > to the 20-byte length limit on sysfs names.  I had to use "tp::<somecrap>"
> > > instead of "thinkpad::<somecrap>" to name LEDs, and still had to reduce
> > > ultrabase_battery to ultrabase_batt :-)
> > > 
> > > Anyway, IMHO, the LED function should come first, and we should not even
> > > need the led driver name anywhere.  In case of clashes in the class sysfs
> > > dir, just tack a .# to the end or somesuch.  The device the LED is tied to
> > > already differentiates them.  That would save a lot of chars for something
> > > much more useful (the function).
> > 
> > Ouch, I'm looking into this. I wish I'd known about it earlier. I agree
> > function is more important but didn't want to break the existing
> > convention. I guess this limitation comes from the kobjects involved...
> 
> Richard, any ideas for that?  It *is* still time to change this for 2.6.25,
> if required.  If you changed it once already, changing it again won't cause
> further damage.
> 
> I need to know if the current naming scheme will hold or not, I do NOT want
> an ABI issue on thinkpad-acpi, and I know for a fact at least Debian will
> want to use the thinkpad-acpi LED interface as soon as I deploy it.  I want
> to send the thinkpad-acpi LED interface patches to the users as soon as
> possible.
> 
> Sincerely?  I think you should make it <function>:[color][.instance] and
> drop device name compleley, ASAP.
> 
> I will write the patches for mainline and your for-mm branch, if that would
> speed up things.  But I need to know what you have decided, first.

As I understand it 2.6.26 will lose the limitation on the name size
entirely so the problem will go away soon. I don't want to change the
existing ABI so changing to what you describe above isn't possible. You
could leave the devicename empty if you wish although I'd prefer you not
to. Keeping it short might be the best option for 2.6.25.

Your other patch looks ok btw although I'm not sure why you sent it
twice. I'll queue that tomorrow.

Cheers,

Richard

Re: [GIT PULL] LED updates

[Henrique de Moraes Holschuh]

On Sun, 16 Mar 2008, Richard Purdie wrote:
> As I understand it 2.6.26 will lose the limitation on the name size
> entirely so the problem will go away soon. I don't want to change the
> existing ABI so changing to what you describe above isn't possible. You
> could leave the devicename empty if you wish although I'd prefer you not
> to. Keeping it short might be the best option for 2.6.25.

Hmm, that means I will have to keep the short names, since I can't very
much have two different ABIs across several kernel versions... or I will
have to backport whatever is needed to expand this name size restriction
(and who knows if that's doable... I better start digging).

This won't be easy on my side :(

Well, might as well claim tpacpi as a thinkpad-acpi short handle and use it
on workqueue and kthread naming (and document it) as well as the led class.
Yuck.

> Your other patch looks ok btw although I'm not sure why you sent it
> twice. I'll queue that tomorrow.

I screwed up the prefix on the first one (used LED instead of leds). The
patches are the same.  I wrote the reason for the resend after the first
"---" separator.

Anyway, thanks for the fast reply.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh