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

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

 




On 06/24/2015 09:28 AM, Jacek Anaszewski wrote:
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.

Of course brightness_get wouldn't have to read the brightness
from the device, but return the value cached on on each call to
brightness_set for any LED class device exposed by the driver.

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