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 <rafal@xxxxxxxxxx> 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 <rafal@xxxxxxxxxx> --- 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
