Hi!

> > > > 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.

> > 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?)

> > 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