Message ID | 20230317023125.486-11-ansuelsmth@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp106777wrt; Thu, 16 Mar 2023 19:35:05 -0700 (PDT) X-Google-Smtp-Source: AK7set/IPfuZv94sMT302XMnCbpxuF/hp+jfxSZijONJcNBbUASTfSIlyWLdnusRJUwtKiQcaqpo X-Received: by 2002:a05:6a20:bb12:b0:c0:53f7:7d16 with SMTP id fc18-20020a056a20bb1200b000c053f77d16mr5396772pzb.39.1679020504969; Thu, 16 Mar 2023 19:35:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679020504; cv=none; d=google.com; s=arc-20160816; b=iG2Is8CvX4p2g5S6/jcok1jTQ2aks6RI0dX8imqaME4NOBLcIgPWMigyAtWip0tjGh m7XBnIqGdwuLRu7RdyZxw0W6h3TUVJ8UYKQPhzXMszZYNR4vmOtf2V7Ju6h+fXmJwmj+ 6a/lrn0RW73AexDYZr+kHf1kT44QwpWAy7d0GMHKz+ye/uO0/wZRkKH70l83QCpdOrRd 6KT+IrygRb0fqck0hgOgRAdwu/GfwEClFA1KWKfmN/4N2sv/Jgrd/rIrfC/yZEQl37rL gsyF4O0rA6IjRYxD0fJVDIWXMZWppz5aG7XWUA8cvQ/7/Qn4vj4CJb9CWhD7IsH6J9EQ cJaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:to:from :dkim-signature; bh=YxutGMPJva579mmTcYCtLi8ZBTi3DvGd1nN+fb8Tx6U=; b=S+EhB19zPGoMjSzkj12rtHuB78JP5zGud7FuNSfoaMukuuYJLfZLNZlaI1Ee4/r0zB oEJ6iT3xNJwXdLWbPa/qRYVxe81iYQHfHGmIVtvSyT6aIj8lYu9O0jbs/DrTk2SAO+lo 1MF2RoTH6Ue+faCmYQNh8CVSQLuKiYaKPKhAoGEkMJOpmWEa7zXwjlceozBwUyo/+kOE B1qKnQJDOBRGLtbawOowYl5u6OB45nT94h+qsngFDGjtDxAOAGSuPVDnUgGcSpC5CgoI unG59aiqnGyS7SSTRbewTlhBBw39ROS3vrou8GtZVufocrmCqg0D8TdGNJISXn7VrIQG /R2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nDOcGQfT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 7-20020a631447000000b00508cd5d9f6dsi955494pgu.290.2023.03.16.19.34.52; Thu, 16 Mar 2023 19:35:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nDOcGQfT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230061AbjCQCeI (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Thu, 16 Mar 2023 22:34:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40690 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229848AbjCQCdm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Mar 2023 22:33:42 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FC2AD503; Thu, 16 Mar 2023 19:33:33 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id r18so3199936wrx.1; Thu, 16 Mar 2023 19:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679020413; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=YxutGMPJva579mmTcYCtLi8ZBTi3DvGd1nN+fb8Tx6U=; b=nDOcGQfTe+PWjvaki2Z3MC2j4Gqvodmqm+7lZRZfBxswVyOOJ2Qy3b92wZjiy2VYGa gtSBY5HVAYVJi3CdnEbkzurM4dpeyOSGV2SSw9WoAPzkS8HnBMtYRXjHLxnM66NrDbNi 3dD+IBQ1Bhp5EQAllKXtrSMI2EHiXXeBlcV9LzOdMrnj2acEkrnKOM/8AwPdXi3FhPWN sGsfjFpLDRnwjdntBMHxxfK0uale20WI1u0bO8rqvHjYeEV81P5byxamqURLHGCwXN1u vV3yMuRujrFvsGqUhTcJ9/jWbnhmxzU2C5AsReTXFZuayWEQR/XMsMIgCiMHdnxOXbey 7Xhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679020413; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YxutGMPJva579mmTcYCtLi8ZBTi3DvGd1nN+fb8Tx6U=; b=1q7S2XSZdd8A3tPmazgqLTCrz0h2jeCgIsORnc4Vglmb5D1jbHTC3obdJaUu7nyDR4 Cw9xT+szb/662dSAdtPm+8aP0jF46od/pThTXPMeHFlzbSyX9fkvgIIijcr16HskrrQA zjLoezWv1OKDoQMkVqUAERQYQ9mUXmjKsWqay31g1thbPNcjB/0vrA2Q/Md27ef27yUp lCEhrhi46F0bGUaxOTFqEAZ+zX193q1IHn2b85R8w4v5HgQ8LAbzKbTDv4aXqkB/cYzW UGceQocfIAkLfz5Rt59iHF4YSqvDqZOys7BZ0diIcgHpbvzCqwRYAUPFAuQxwlPjVndq FhpQ== X-Gm-Message-State: AO0yUKVTkbADeGbX6RhKyd8oSGrJnllzEPQyx6bA+d6t13lJMXUvSg7j VVspVMKu9Q9e/GGcXvLbqRw= X-Received: by 2002:a5d:510d:0:b0:2c5:540b:886c with SMTP id s13-20020a5d510d000000b002c5540b886cmr1086733wrt.31.1679020413009; Thu, 16 Mar 2023 19:33:33 -0700 (PDT) Received: from localhost.localdomain (93-34-89-197.ip49.fastwebnet.it. [93.34.89.197]) by smtp.googlemail.com with ESMTPSA id z15-20020a5d44cf000000b002ce9f0e4a8fsm782313wrr.84.2023.03.16.19.33.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Mar 2023 19:33:32 -0700 (PDT) From: Christian Marangi <ansuelsmth@gmail.com> To: Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, Gregory Clement <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Christian Marangi <ansuelsmth@gmail.com>, John Crispin <john@phrozen.org>, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, Lee Jones <lee@kernel.org>, linux-leds@vger.kernel.org Subject: [net-next PATCH v4 10/14] dt-bindings: net: dsa: qca8k: add LEDs definition example Date: Fri, 17 Mar 2023 03:31:21 +0100 Message-Id: <20230317023125.486-11-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230317023125.486-1-ansuelsmth@gmail.com> References: <20230317023125.486-1-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760580605079745998?= X-GMAIL-MSGID: =?utf-8?q?1760580605079745998?= |
Series |
net: Add basic LED support for switch/phy
|
|
Commit Message
Christian Marangi
March 17, 2023, 2:31 a.m. UTC
Add LEDs definition example for qca8k Switch Family to describe how they
should be defined for a correct usage.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
.../devicetree/bindings/net/dsa/qca8k.yaml | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
Comments
Hello Christian, also Rob Herring, Andrew Lunn and Pavel Machek, On Fri, 17 Mar 2023 03:31:21 +0100 Christian Marangi <ansuelsmth@gmail.com> wrote: > Add LEDs definition example for qca8k Switch Family to describe how they > should be defined for a correct usage. > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > .../devicetree/bindings/net/dsa/qca8k.yaml | 24 +++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml > index 389892592aac..2e9c14af0223 100644 > --- a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml > @@ -18,6 +18,8 @@ description: > PHY it is connected to. In this config, an internal mdio-bus is registered and > the MDIO master is used for communication. Mixed external and internal > mdio-bus configurations are not supported by the hardware. > + Each phy has at least 3 LEDs connected and can be declared > + using the standard LEDs structure. > > properties: > compatible: > @@ -117,6 +119,7 @@ unevaluatedProperties: false > examples: > - | > #include <dt-bindings/gpio/gpio.h> > + #include <dt-bindings/leds/common.h> > > mdio { > #address-cells = <1>; > @@ -226,6 +229,27 @@ examples: > label = "lan1"; > phy-mode = "internal"; > phy-handle = <&internal_phy_port1>; > + > + leds { > + #address-cells = <1>; > + #size-cells = <0>; > + > + led@0 { > + reg = <0>; > + color = <LED_COLOR_ID_WHITE>; > + function = LED_FUNCTION_LAN; > + function-enumerator = <1>; > + default-state = "keep"; > + }; > + > + led@1 { > + reg = <1>; > + color = <LED_COLOR_ID_AMBER>; > + function = LED_FUNCTION_LAN; > + function-enumerator = <1>; > + default-state = "keep"; > + }; > + }; > }; I have nothing against this, but I would like to point out the existence of the trigger-sources DT property, and I would like to discuss how this property should be used by the LED subsystem to choose default behaviour of a LED. Consider that we want to specify in device-tree that a PHY LED (or any other LED) should blink on network activity of the network device connected to this PHY (let's say the attached network device is eth0). (Why would we want to specify this in devicetree? Because currently the drivers either keep the behaviour from boot or change it to something specific that is not configurable.) We could specify in DT something like: eth0: ethernet-controller { ... } ethernet-phy { leds { led@0 { reg = <0>; color = <LED_COLOR_ID_GREEN>; trigger-sources = <ð0>; function = LED_FUNCTION_ ?????? ; } } } The above example specifies that the LED has a trigger source (eth0), but we still need to specify the trigger itself (for example that the LED should blink on activity, or the different kinds of link). In my opinion, this should be specified by the function property, but this property is currently used in other way: it is filled in with something like "wan" or "lan" or "wlan", an information which, IMO, should instead come from the devicename part of the LED, not the function part. Recall that the LED names are of the form devicename:color:function where the devicename part is supposed to be something like mmc0 or sda1. With LEDs that are associated with network devices I think the corresponding name should be the name of the network device (like eth0), but there is the problem of network namespaces and also that network devices can be renamed :(. So one option how to specify the behaviour of the LED to blink on activity would be to set function = LED_FUNCTION_ACTIVITY; but this would conflict with how currently some devicetrees use "lan", "wlan" or "wan" as the function (which is IMO incorrect, as I said above). Another option would be to ignore the function and instead use additional argument in the trigger-source property, something like trigger-sources = <ð0 TRIGGER_SOURCE_ACTIVITY>; I would like to start a discussion on this and hear about your opinions, because I think that the trigger-sources and function properties were proposed in good faith, but currently the implementation and usage is a mess. Marek
On Fri, Mar 17, 2023 at 09:14:10AM +0100, Marek BehĂșn wrote: > Hello Christian, also Rob Herring, Andrew Lunn and Pavel Machek, > > On Fri, 17 Mar 2023 03:31:21 +0100 > Christian Marangi <ansuelsmth@gmail.com> wrote: > > > Add LEDs definition example for qca8k Switch Family to describe how they > > should be defined for a correct usage. > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > --- > > .../devicetree/bindings/net/dsa/qca8k.yaml | 24 +++++++++++++++++++ > > 1 file changed, 24 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml > > index 389892592aac..2e9c14af0223 100644 > > --- a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml > > +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml > > @@ -18,6 +18,8 @@ description: > > PHY it is connected to. In this config, an internal mdio-bus is registered and > > the MDIO master is used for communication. Mixed external and internal > > mdio-bus configurations are not supported by the hardware. > > + Each phy has at least 3 LEDs connected and can be declared > > + using the standard LEDs structure. > > > > properties: > > compatible: > > @@ -117,6 +119,7 @@ unevaluatedProperties: false > > examples: > > - | > > #include <dt-bindings/gpio/gpio.h> > > + #include <dt-bindings/leds/common.h> > > > > mdio { > > #address-cells = <1>; > > @@ -226,6 +229,27 @@ examples: > > label = "lan1"; > > phy-mode = "internal"; > > phy-handle = <&internal_phy_port1>; > > + > > + leds { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + led@0 { > > + reg = <0>; > > + color = <LED_COLOR_ID_WHITE>; > > + function = LED_FUNCTION_LAN; > > + function-enumerator = <1>; > > + default-state = "keep"; > > + }; > > + > > + led@1 { > > + reg = <1>; > > + color = <LED_COLOR_ID_AMBER>; > > + function = LED_FUNCTION_LAN; > > + function-enumerator = <1>; > > + default-state = "keep"; > > + }; > > + }; > > }; > > I have nothing against this, but I would like to point out the > existence of the trigger-sources DT property, and I would like to > discuss how this property should be used by the LED subsystem to choose > default behaviour of a LED. > > Consider that we want to specify in device-tree that a PHY LED (or any > other LED) should blink on network activity of the network device > connected to this PHY (let's say the attached network device is eth0). > (Why would we want to specify this in devicetree? Because currently the > drivers either keep the behaviour from boot or change it to something > specific that is not configurable.) > > We could specify in DT something like: > eth0: ethernet-controller { > ... > } > > ethernet-phy { > leds { > led@0 { > reg = <0>; > color = <LED_COLOR_ID_GREEN>; > trigger-sources = <ð0>; > function = LED_FUNCTION_ ?????? ; > } > } > } > > The above example specifies that the LED has a trigger source (eth0), > but we still need to specify the trigger itself (for example that > the LED should blink on activity, or the different kinds of link). In my > opinion, this should be specified by the function property, but this > property is currently used in other way: it is filled in with something > like "wan" or "lan" or "wlan", an information which, IMO, > should instead come from the devicename part of the LED, not the > function part. > > Recall that the LED names are of the form > devicename:color:function > where the devicename part is supposed to be something like mmc0 or > sda1. With LEDs that are associated with network devices I think the > corresponding name should be the name of the network device (like eth0), > but there is the problem of network namespaces and also that network > devices can be renamed :(. > > So one option how to specify the behaviour of the LED to blink on > activity would be to set > function = LED_FUNCTION_ACTIVITY; > but this would conflict with how currently some devicetrees use "lan", > "wlan" or "wan" as the function (which is IMO incorrect, as I said > above). > > Another option would be to ignore the function and instead use > additional argument in the trigger-source property, something like > trigger-sources = <ð0 TRIGGER_SOURCE_ACTIVITY>; > > I would like to start a discussion on this and hear about your opinions, > because I think that the trigger-sources and function properties were > proposed in good faith, but currently the implementation and usage is a > mess. > I think we should continue and make this discussion when we start implementing the hw contro for these LEDs to configure them in DT. Currently we are implementing very basic support so everything will be in sw. Anyway just to give some ideas. Yes it sound a good idea to use the trigger-sources binding. My idea would be that trigger needs to have specific support for them. If this in mind netdev can be configured in DT and setup hw control to offload blink with the required interface passed. The current implementation still didn't include a way to configure the blink in DT as the series are already a bit big... (currently we have 3: - This series that already grow from 10 patch to 14 - A cleanup series for netdev trigger that is already 7 patch - hw control that is another big boy with 12 patch ) So our idea was to first implement the minor things and then polish and improve it. (to make it easier to review) But agree with you that it would be a nice idea to have a correct and good implementation for trigger-sources.
> We could specify in DT something like: > eth0: ethernet-controller { > ... > } > > ethernet-phy { > leds { > led@0 { > reg = <0>; > color = <LED_COLOR_ID_GREEN>; > trigger-sources = <ð0>; > function = LED_FUNCTION_ ?????? ; > } > } > } For generic case, where you just have an LED on some random bus, you need to know what netdev it should represent. And in effect, this patch series gives you just that. However, when we get to offload, which is the ultimate goal, things are different. We cannot expect an LED inside the PHY connected to eth42 to offload blinking for eth24. There is a clear hardware relationship between the LED and the netdev. And in the more general case, there will always be a hardware relationship, be it wifi activity, or hard disk activity. phylib knows this relationship, and the DSA core also knows this relationship. Probably the SATA core will know the relationship. So i have a patchset which adds an op to the cdev to ask it, what struct device do you HW blink for? trigger-sources then becomes optional. And in fact, if it is used, you need to verify if it fits to this relationship, and if not, refuse to offload blinking, so software blinking only. Anyway, that is an aside to your main question. But the Day Job is calling. I will address your question later today. Andrew
> I would like to start a discussion on this and hear about your opinions, > because I think that the trigger-sources and function properties were > proposed in good faith, but currently the implementation and usage is a > mess. Hi Marek We are pushing the boundaries of the LED code here, doing things which have not been done before, as far as i know. So i expect some discussion about this. However, that discussion should not really affect this patchset, which is just adding plain boring software controlled LEDs. A quick recap about ledtrig-netdev. If you have a plain boring LED, you have: root@370rd:/sys/class/net/eth0/phydev/leds/f1072004.mdio-mii:00:WAN# ls brightness device max_brightness power subsystem trigger uevent You can turn the LED on with root@370rd:/sys/class/net/eth0/phydev/leds/f1072004.mdio-mii:00:WAN# echo 1 > brightness and turn it off with: root@370rd:/sys/class/net/eth0/phydev/leds/f1072004.mdio-mii:00:WAN# echo 0 > brightness You select the trigger via the trigger sysfs file: root@370rd:/sys/class/net/eth0/phydev/leds/f1072004.mdio-mii:00:WAN# cat trigger [none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer heartbeat netdev mmc0 root@370rd:/sys/class/net/eth0/phydev/leds/f1072004.mdio-mii:00:WAN# echo netdev > trigger root@370rd:/sys/class/net/eth0/phydev/leds/f1072004.mdio-mii:00:WAN# ls activity brightness device_name half_duplex link link_100 max_brightness rx trigger uevent available_mode device full_duplex interval link_10 link_1000 power subsystem tx When you select a trigger, that trigger can add additional sysfs files. For the netdev trigger we gain link, link_10, link_100, link_1000, rx & tx. Nothing special here, if you selected the timer trigger you get delay_off delay_on. The oneshot trigger has invert, delay_on, delay_off etc. You then configure the trigger via setting values in the sysfs files. If you want the LED to indicate if there is link, you would do: echo 1 > link The LED would then light up if the netdev has carrier. If you want link plus RX packets echo 1 > link echo 1 > rx The LED will then be on if there is link, and additionally blink if the netdev stats indicate received frames. For the netdev trigger, all the configuration values are boolean. So a simple way to represent this in DT would be boolean properties: netdev-link = <1>; netdev->rx = <1>; We probably want these properties name spaced, because we have oneshot delay_on and timer delay_on for example. The same sysfs name could have different types, bool vs milliseconds, etc. I would make it, that when the trigger is activated, the values are read from DT and used. There is currently no persistent state for triggers. If you where to swap to the timer trigger and then return to the netdev trigger, all state is lost, so i would re-read DT. Offloading to hardware should not make an difference here. All we are going to do is pass the current configuration to the LED and ask it, can you do this? If it says no, we keep blinking in software. If yes, we leave the blinking to the hardware. There is the open question of if DT should be used like this. It is not describing hardware, it is describing configuration of hardware. So it could well get rejected. You then need to configure it in software. Andrew
diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml index 389892592aac..2e9c14af0223 100644 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml @@ -18,6 +18,8 @@ description: PHY it is connected to. In this config, an internal mdio-bus is registered and the MDIO master is used for communication. Mixed external and internal mdio-bus configurations are not supported by the hardware. + Each phy has at least 3 LEDs connected and can be declared + using the standard LEDs structure. properties: compatible: @@ -117,6 +119,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> mdio { #address-cells = <1>; @@ -226,6 +229,27 @@ examples: label = "lan1"; phy-mode = "internal"; phy-handle = <&internal_phy_port1>; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_WHITE>; + function = LED_FUNCTION_LAN; + function-enumerator = <1>; + default-state = "keep"; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_AMBER>; + function = LED_FUNCTION_LAN; + function-enumerator = <1>; + default-state = "keep"; + }; + }; }; port@2 {