Hi!

quoted

quoted

quoted

First two patches are taking care of -ENOTSUPP error code too  prevent its
appearance in the user space.

Pavel, any comments on this bug fix series?

I took these:

Thanks!

What branch/tree should I rebase the rest on?

git@gitolite.kernel.org:pub/scm/linux/kernel/git/pavel/linux-leds.git
for-next would do the trick.

As would linux-next, I guess. This area should not be changing.

quoted

For the "remove depends on OF"... I'd preffer not to take those. We
don't need to ask the user for configurations that never happen.

What do you mean by this? ACPI is quite a good configuration to make use
of it on the corresponding platforms. By default any discrete LED driver
(in hardware term here) IC should be considered independent from the type
of the platform description. Do you agree? If so, it means that

The drivers are independend, I guess. But I'm also very sure you will
not find some of the chips in a ACPI based machine. el15203000 is such
example.

I don't want people configuring for normal PCs to be asked if they
want el15203000 support.

If you know particular chip is present in ACPI-based machine, I'm okay
with removing the dependency.

(Maybe some of these chould depend on ARM || COMPILE_TEST instead?)

quoted

dropping

OF dependency is a right thing to do to allow users of those ICs to be happy
even on ACPI based platforms.

Note, entire IIO subsystem is a good example of this activity. All the sensors
can be used now in ACPI environment without explicit requirement to have an
ACPI ID, although it's highly recommended to acquire for the real products
(not DIY ones).

Well. I'm not sure that is good step forward. It will result in
useless questions being asked.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek