On 10/05/2016 02:22 PM, Rob Herring wrote:
On Wed, Oct 5, 2016 at 3:09 AM, Jacek Anaszewski
<j.anaszewski@xxxxxxxxxxx> wrote:
Hi Matt,
On 10/05/2016 04:29 AM, Matt Ranostay wrote:
Allow the LED subsystem to blank the LEDS on suspend.
Cc: Richard Purdie <rpurdie@xxxxxxxxx>
Cc: Jacek Anaszewski <j.anaszewski@xxxxxxxxxxx>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
Documentation/devicetree/bindings/leds/pca963x.txt | 1 +
drivers/leds/leds-pca963x.c | 9 +++++++++
include/linux/platform_data/leds-pca963x.h | 6 ++++++
3 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt
b/Documentation/devicetree/bindings/leds/pca963x.txt
index dafbe9931c2b..61b1f037ebd0 100644
--- a/Documentation/devicetree/bindings/leds/pca963x.txt
+++ b/Documentation/devicetree/bindings/leds/pca963x.txt
@@ -7,6 +7,7 @@ Optional properties:
- nxp,totem-pole : use totem pole (push-pull) instead of open-drain
(pca9632 defaults
to open-drain, newer chips to totem pole)
- nxp,hw-blink : use hardware blinking instead of software blinking
+- nxp,leds-suspend : turn off LEDS on system suspend
How about making this property generic and adding it to the common LED
bindings?
Cc Rob.
Fine with me though seems like keeping on would be less common. Maybe
"keep-in-suspend". Also, if this is a user decision, then it should be
a sysfs attr and shouldn't be in DT.
Matt, did you have any specific reason for making it configurable?
I like the idea of adding generic sysfs attribute for that, which
would allow for customizing behaviour for a LED used as torch.
I believe that in most use cases the user doesn't want that the LED
used as torch went off on suspend.
--
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
