Re: led_class: storing a value can act but return -EINVAL

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

On Sun, 2006-04-30 at 12:57 +0100, Richard Purdie wrote:

> echo 255> brightness works, returns success.

??
For me (bash) that doesn't do anything useful.
Were you looking for "echo -n 255 > brightness"?

> echo 255 > brightness works but then returns -EINVAL.

> So we currently do b, quite strictly. Its the trailing space thats the
> problem. It also shouldn't have altered the brightness value if it ends
> up returning -EINVAL.

Yes, but you do change the actual value, which IMHO you shouldn't when
it will return -EINVAL. I should have said

b) reject anything that isn't *only* a number and take no action

instead.

> I've looked around other implementations and it would appear we should
> accept an optional space. Most sysfs attributes seem to handle this
> differently, each with its own "bugs".

Yeah, unfortunately that is true. Maybe there should've been helper
functions like when you have a sysfs-int attribute that is set directly
without get/set calls. I'd suggest looking at that code.

> I've some fixes in mind both for the led and backlight classes which
> I'll post once I've done a little more testing. I'd be interested to
> know the official view on what the attributes should/shouldn't accept
> is.

I have a question about the backlight class: I'm writing a patch
currently to control the *keyboard* backlight on powerbooks, is that
appropriate for the backlight class (setting the fbdev callback to
reject everything)?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]