LED devices

[Richard Purdie]

On Fri, 2007-06-01 at 14:31 +0100, Richard Hughes wrote:
> On Fri, 2007-06-01 at 13:59 +0100, Richard Purdie wrote:
> > > Then we can use apple_power_on, thinkpad_charging, logitech_low_power.
> > > The colour of the led is not always the best descriptor.
> > 
> > Agreed, which is why I've said I'll accept some optional notion of
> > function in the name by extending the API as discussed previously.
> 
> You are _changing_ the API. This is something you would not have to do
> if you just used standard sysfs attributes.

Which completes a circle. We'll just have to disagree on this. 

> > Of course by your own argument we'll have to provide a property
> > attribute for that too since conveying that information in the name only
> > isn't allowed.
> 
> Sure, an optional attribute called "description" would also be good.

But don't you see the circular argument that creates?

> > > > * If we remove colour from the names we break the existing API as
> > > > documented.
> > > 
> > Look harder, there are at least the following users using that naming
> > scheme just in drivers/leds:
> > 
> > leds-corgi
> > leds-tosa
> > leds-spitz
> > leds-h1940
> > leds-locomo
> > leds-gpio
> > leds-ixp4xx-gpio
> 
> Yes, most added by you or John, I'm looking at the common case.

Meaning drivers written by me are worth less than someone elses? Thats
an interesting view.

> > > > * Drivers should only specify the colour in one place.
> > > 
> > > Yup. Agree, which to me suggests that a descriptor to the led
> > > "discharging" is better than "amber", and then if the led colour ever
> > > changes from model to model (like the thinklight) then we only have to
> > > change one property and not the device name.
> > 
> > The LED function changes model to model too. The spitz driver works on
> > two models, one where the green LED is marked as mail, the other where
> > it is marked as HDD activity. So no, that argument doesn't stand up.
> 
> How does this help userspace? Two devices where the led is the same
> device name with two completely different purposes.

It doesn't. Its one reason I'm in favour of the 'function' style
attribute.

My point was that function is no better or worse than colour and both
are of potential value.

> The sysfs classes are _not_ just a convenient way for you to talk to
> LEDs using a specific bit of software, they are meant to be general
> purpose abstractions to be used by userspace interacting with hardware. 

I think I've demonstrated awareness of this and there is a certain irony
of being accused otherwise ;-).

> You've not explained any good reasons for not doing the same as 99% of
> the other sysfs class abstractions, i.e. using attributes (that are
> supported using libsysfs), 

No, you don't agree with my reasons which is somewhat different.

> and I am beginning to loose patience with this discussion.

Evidently.

> The sysfs maintainer has asked you not to use ":" in the device name to
> separate properties and I haven't found one person who thinks this is a
> good idea.

The sysfs maintainer said that it should export any property data as a
class attribute. I've done this.

He also said that the only requirement on bus id naming was that it was
unique. I'm therefore choosing the maintain the LED naming scheme as
documented for the reasons I've given.

HAL can now go ahead and ignore the device name, all the attributes are
there in the fashion it needs. Thanks for pointing out the problem but
I'm now considering the issue resolved.

Regards,

Richard