Messages in this thread | | | Date | Tue, 8 Nov 2005 10:28:48 +0100 | From | Pavel Machek <> | Subject | Re: best way to handle LEDs |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |