Re: [PATCH v5 1/2] dt: add cap11xx LED documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 06/23/2015 08:07 PM, Dmitry Torokhov wrote:
On Tue, Jun 23, 2015 at 10:23:57AM -0700, Matt Ranostay wrote:
On Tue, Jun 23, 2015 at 1:36 AM, Jacek Anaszewski
<j.anaszewski@xxxxxxxxxxx> wrote:
On 06/22/2015 07:59 PM, Dmitry Torokhov wrote:

On Wed, Jun 17, 2015 at 08:58:16PM -0700, Matt Ranostay wrote:

Signed-off-by: Matt Ranostay <mranostay@xxxxxxxxx>
---
   .../devicetree/bindings/input/cap11xx.txt          | 25
++++++++++++++++++++++
   1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/cap11xx.txt
b/Documentation/devicetree/bindings/input/cap11xx.txt
index 7d0a300..09cdc43 100644
--- a/Documentation/devicetree/bindings/input/cap11xx.txt
+++ b/Documentation/devicetree/bindings/input/cap11xx.txt
@@ -38,6 +38,11 @@ Optional properties:
                                 defaults. The array must have exactly six
                                 entries.

+       linux,led-brightness:   Defines the ON brightness when the
optional LED
+                               functionality is used. Valid values are
1-15.
+                               By default a value of 15 is set.


Please mention the device does not allow controlling brightness of leds
individually and that is why this property is at device level, not
individual led level.


I've just noticed that we have drivers/leds/leds-netxbig.c driver, which
also doesn't allow controlling the LEDs on extension board individually,
but it still does allow changing their brightness. I am leaning towards
allowing this also for this driver and adding similar comment in the
source code like at the line 218 of the aforementioned driver.
As a result this property wouldn't be required.


Ok that should be pretty simple to do. But seems kind weird to have
each led channel to be changing the brightness of all.  Wouldn't the
brightness sysfs entries of the other led channels be showing
incorrect values?

If you implemented brightness_get op it would show proper value.
Assuming that the device allows reading current brightness.

I agree, this is kind of weird. Maybe we should have a device-specific
attribute (on the platform device level) that allows controlling overall
brightness, but I think LEDs should be just on/off with max brightness
of 1. Userspace should not have to be aware about the fact that on that
particular device LEDs are not completely independent as far as their
brightness goes.

This way we are removing the possibility of controlling LED brightness
at all, the feature that the hardware supports. Anyway, we will have to
add a mechanism to the LED subsystem for detecting which LED class
devices are controlled by the same hardware. This will allow for
describing this type of dependencies. This is on "to do" list.

--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux