On 01/03/2017 09:52 PM, Rob Herring wrote:
On Thu, Dec 29, 2016 at 02:03:04PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki <ra...@milecki.pl>
Some LEDs can be related to particular USB ports (common case for home
routers). This property allows describing such a relation.
Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
---
This patch is based on top of commit 52e847dc431 ("DT: leds: Improve examples
by adding some context") sitting in the linux-leds.git (for-4.11).
---
Documentation/devicetree/bindings/leds/common.txt | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index 24b6560..fcfe661 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -49,6 +49,14 @@ Optional properties for child nodes:
- panic-indicator : This property specifies that the LED should be used,
if at all possible, as a panic indicator.
+- usb-ports : List of USB ports related to this LED. Some devices have LEDs
that
+ should be used to indicate USB device activity. This can be
+ described with this property.
+ There can be more than one LED like this, e.g. some vendors use
+ one controller per USB version. It's then common to use different
+ color LEDs depending on device USB standard (like USB 2.0 vs.
+ USB 3.0).
I don't like this being USB specific. Either we should have a generic
way to link triggers to other DT nodes or the existing trigger property
should be used (and be capable of listing more than 1 port). I'd prefer
the latter as I don't think we need another way to specify triggers.
Hi Rob & thanks for your review.
Could you point me to "the existing trigger property" you meant, please? It's
not clear to me, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
