Re: [patch] Move led attributes out of device name and into sysfs attributes, was Re: LED devices

[Richard Hughes <hughsient@gmail.com>]

On Fri, 2007-06-01 at 16:43 +0100, Richard Purdie wrote:
> On Fri, 2007-06-01 at 16:04 +0100, Richard Hughes wrote:
> > Patch attached corrects all the brokenness with the led class (encoding
> > some attributes in the device handle).
> 
> For the benefit of LKML, there has been some discussion of this
> elsewhere. My arguments do not particularly come across in Richard's
> choice of quoting and I'm a little annoyed he's chosen to do things this
> way, particularly before any further feedback from Greg/Kay but so be
> it.

To be honest, I didn't want to do this, but you would not accept my
argument - and you wanted to add _more_ properties into the device
handle.

> Greg said that the LEDs class should export any property data as a class
> attribute rather than this just being available in the device name. I
> added the patch in
> http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm to deal
> with this, without breaking the existing LED naming and documented API.

Yes, but as you'll notice with my patch, lots of the users that use the
led class do not use the handle:colour name, and so stripping off
second : parameter for the color attribute was just wrong. And ugly.

> Greg said that the only requirement on bus id naming was that it needed
> to be unique so this should therefore be compatible. HAL could then go
> ahead and ignore the device name, all the attributes are there in the
> fashion it needs which was the original complaint.

But when I was investigating adding led class support to thinkpad_acpi I
couldn't use the existing LED class, as some of the LED's did not have a
pre-defined colour, but did have a description. Again, adding support
into HAL was made more difficult until you proposed screenscaping the
led colour from the device name. This isn't very nice.

> I accept this is basically out of my hands now. Greg/Kay have the
> appropriate emails and if they'll let me know which approach they want
> to take, I'll apply an appropriate patch. I'd suggest not applying this
> patch directly as it introduces a race in the error path it alters.

Sure, I really wanted to convert the class to struct device (which I'm
more familiar with) but just tried to do minimal changes. What changes
need to be made to avoid a race? Thanks.

Richard.