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@xxxxxxxxxxxxxxxxxxx: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
Attachment:
signature.asc
Description: PGP signature
