Re: best way to handle LEDs

[Pavel Machek]

Hi!

> >> I just looked, and
> >> http://www.cs.wisc.edu/~lenz/zaurus/files/patch-2.6.7-jl2.diff.gz
> >> contins
> >> the implementation of the arm led interface for collie.... not sure if
> >> it
> >> will still work anymore, but...
> >
> > It does, after kconfig fixups. Do you think we could get that merged?
> > Some led driver is better than none at all.
> 
> I wonder, because we are exporting an API to userspace.  I don't think the
> openembedded people want to use this API, and will hold off doing anything
> with the leds till we get something else straigtend out.  If we have this
> API now, we will have issues breaking it later (or we will have to do some
> wierd locking scheme to allow both interfaces control, and crap like
> that).

* they are 9 users of "old" interface already, one more does not seem
like a big deal.

* arm maintainer does not want anything more complex than "old"
interface. And I can see his point. It is not clear if "new" interface
will get into mainline.

* there are very little users of collie, currently. Changing LED API
on myself does not seem like a big deal. [I'm trying hard to get _two
more_ users :-)]

* if openembedded people do not like current interface, they should a)
convince rmk API needs to change and b) convert all the drivers.

> Secondly, leds aren't that importent unless they are supported by the
> userspace programs (to do things like blink when email shows up).  And
> before the userspace starts using leds, I think they might want to clear
> up the interface API issue first.

I'd say charger LED is somehow important, and I liked CPU usage LED a lot.

								Pavel
-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/