Message ID | 20230327141031.11904-17-ansuelsmth@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1566440vqo; Mon, 27 Mar 2023 07:48:18 -0700 (PDT) X-Google-Smtp-Source: AKy350bTXKYL3POCrQh+CqwjtkTF6lpYwikW3Q7hwfrmlkkhT1QYWUKc9w8g+5U1fd6QXghScqDE X-Received: by 2002:a17:907:6e22:b0:930:3916:df1d with SMTP id sd34-20020a1709076e2200b009303916df1dmr17214490ejc.0.1679928498495; Mon, 27 Mar 2023 07:48:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679928498; cv=none; d=google.com; s=arc-20160816; b=pciKUKRYHERjwWzF0L6CAw+dr79OBDN1np4jXKT4kYC+6INQOcP+KVte+7Ocqs042H mFst+3EXw80o7JDvDoITQQxKlVMLpd+Mbi4G4KJocODvSbzbYeKr1G2n9LmHQc2OCQaN MUb3iEic6Fio441nrZRwiSOczfWBFrq4bEC0uVjSS64Q9JMYJaBMD1ksLfX4ylojphNt 0kXXf+Wg+kHfVD8p/9wyvbODMx/NwWt8ZLAlsI2moaFBlduVI0oEy5SizpOkGPdxeIA5 SkHsuE+dyN9gKzM5uUmBCvYFhFtb8Vk5lPI4lW+bqFLHpmMQDJY2QeaROGwWNBTj74An 8N+w== 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=oy4rJp/0zV8uQx96aqdFOna+cm21IPd+B8/oErRDE1c=; b=rej1i3u94fnVWyC9taXrfw1ZTS1oh0Fb6uXD/XjbPItsZ5kOGUJX0jgaCPx+u8BlK+ gxksWJ3aUPDIJFLXNqT4rSmOFXW5If3zguobgioK4JoSIuvDO0jpbwkt+XJSIkl3wUoT d5H3CBrCwseipf9ai+27P4Pne1Nh+jRELVM4Wabbf+MVbmY9SEHKWb7Y8dK4ekZtuguc fwytmKU9MAKr8rbJjoFH0kvdOYSPeRW7aIccmMkzu8B4ho9j7GNDNyqLIVKkAXeSUybu KE3RR3WKxQRIIYqMsU0c0qVwzod5TUUTF5fs0GpEDdkrm1keuUit+gXLlR/OeQYIzpw+ oyuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=N1+9G3Tu; 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 nc24-20020a1709071c1800b00945c481efd8si1587227ejc.110.2023.03.27.07.47.55; Mon, 27 Mar 2023 07:48:18 -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=N1+9G3Tu; 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 S233051AbjC0ONe (ORCPT <rfc822;makky5685@gmail.com> + 99 others); Mon, 27 Mar 2023 10:13:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232866AbjC0OMo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 27 Mar 2023 10:12:44 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 725CE658D; Mon, 27 Mar 2023 07:11:29 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id i9so8959448wrp.3; Mon, 27 Mar 2023 07:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679926285; 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=oy4rJp/0zV8uQx96aqdFOna+cm21IPd+B8/oErRDE1c=; b=N1+9G3TumKrPZKtDgnUYD6HDreYZGrsnCsG3x6VR1o6zsdlKygYn5Z2B/6MK7uSEib /66G9qTuGKBx/QqmSMP7T42XAs/7GFQk8nHeM2yzmROF/lCWibWpheeY7B2GIYdPhN1b 9GOlfffc+AZNhfrEsFIJ3yAaWe0xtdGPgJ7Kl/Hxs1k3JTD2gzvl09ggMzmHbEwGGjX0 5zZz5BzkFOFGFyvfTTjuPhvEr8tGjp/IpmshsxkTYQ/MxRyhYQnC07KfzFJlhNkTtrfr U+DjoUUgEiUUffoufrfwBWTA2WZQ8MQAdVmgCLlpPjCWptllhVOFI+HVVbkY+10eJdED 7MAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679926285; 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=oy4rJp/0zV8uQx96aqdFOna+cm21IPd+B8/oErRDE1c=; b=FMq992CpDPrMpcuoNU7v2pHnJ5WKkCjoRtruPc5m3muB4eg9xCAjexKkTsEroi+5hA durhU+5iBGOl/FoytHyGN6pLTqSDuY/4oc/vvpXD/yiORs9XLlExHXAFxEoVc8L4An/G +i61vETMfq9ZVUVG0vFD5rqTdjroN+gwJx2tmmH6zzDJZsXG0In7PZQKEk1cOmWrcK1u lqFFSjWFvUcKg/TBdi4lENPhFWZwAD+ogrU07Prv5zqlTQ+F/eC3wTnfl+jpwj86RfOh jr5rHMMI5fZZqc+W/WHSHoTm/Vq876gIIEmaHN3OH7NB8RINqn+WicFilTAO6HzRXXZ2 dlKg== X-Gm-Message-State: AAQBX9cRRe04NsHN3WvViu0vNRBelz/muQ6LV/Mpp7RhuKm7OiKkH2KZ qdll3xKrzazm0df3Kq7B0nA= X-Received: by 2002:adf:e5d1:0:b0:2ce:a7f5:ff10 with SMTP id a17-20020adfe5d1000000b002cea7f5ff10mr8517757wrn.57.1679926285261; Mon, 27 Mar 2023 07:11:25 -0700 (PDT) Received: from localhost.localdomain (93-34-89-197.ip49.fastwebnet.it. [93.34.89.197]) by smtp.googlemail.com with ESMTPSA id p17-20020adfcc91000000b002c71dd1109fsm25307591wrj.47.2023.03.27.07.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Mar 2023 07:11:24 -0700 (PDT) From: Christian Marangi <ansuelsmth@gmail.com> To: Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, 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>, 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>, linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: [net-next PATCH v6 16/16] arm: mvebu: dt: Add PHY LED support for 370-rd WAN port Date: Mon, 27 Mar 2023 16:10:31 +0200 Message-Id: <20230327141031.11904-17-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230327141031.11904-1-ansuelsmth@gmail.com> References: <20230327141031.11904-1-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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?1761532705251800896?= X-GMAIL-MSGID: =?utf-8?q?1761532705251800896?= |
Series |
net: Add basic LED support for switch/phy
|
|
Commit Message
Christian Marangi
March 27, 2023, 2:10 p.m. UTC
From: Andrew Lunn <andrew@lunn.ch> The WAN port of the 370-RD has a Marvell PHY, with one LED on the front panel. List this LED in the device tree. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> --- arch/arm/boot/dts/armada-370-rd.dts | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
Comments
On Mon 2023-03-27 16:10:31, Christian Marangi wrote: > From: Andrew Lunn <andrew@lunn.ch> > > The WAN port of the 370-RD has a Marvell PHY, with one LED on > the front panel. List this LED in the device tree. > @@ -135,6 +136,19 @@ &mdio { > pinctrl-names = "default"; > phy0: ethernet-phy@0 { > reg = <0>; > + leds { > + #address-cells = <1>; > + #size-cells = <0>; > + > + led@0 { > + reg = <0>; > + label = "WAN"; > + color = <LED_COLOR_ID_WHITE>; > + function = LED_FUNCTION_LAN; > + function-enumerator = <1>; > + linux,default-trigger = "netdev"; > + }; /sys/class/leds/WAN is not acceptable. Best regards, Pavel
On Tue, Mar 28, 2023 at 10:31:16AM +0200, Pavel Machek wrote: > On Mon 2023-03-27 16:10:31, Christian Marangi wrote: > > From: Andrew Lunn <andrew@lunn.ch> > > > > The WAN port of the 370-RD has a Marvell PHY, with one LED on > > the front panel. List this LED in the device tree. > > > @@ -135,6 +136,19 @@ &mdio { > > pinctrl-names = "default"; > > phy0: ethernet-phy@0 { > > reg = <0>; > > + leds { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + led@0 { > > + reg = <0>; > > + label = "WAN"; > > + color = <LED_COLOR_ID_WHITE>; > > + function = LED_FUNCTION_LAN; > > + function-enumerator = <1>; > > + linux,default-trigger = "netdev"; > > + }; > > /sys/class/leds/WAN is not acceptable. As i said here, that is not what it gets called: https://lore.kernel.org/netdev/aa2d0a8b-b98b-4821-9413-158be578e8e0@lunn.ch/T/#m6c72bd355df3fcf8babc0d01dd6bf2697d069407 > It can be found in /sys/class/leds/f1072004.mdio-mii:00:WAN. But when > we come to using it for ledtrig-netdev, the user is more likely to follow > /sys/class/net/eth0/phydev/leds/f1072004.mdio-mii\:00\:WAN/ Is that acceptable? What are the acceptance criteria? Andrew
On Mon, Mar 27, 2023 at 04:10:31PM +0200, Christian Marangi wrote: > From: Andrew Lunn <andrew@lunn.ch> > > The WAN port of the 370-RD has a Marvell PHY, with one LED on > the front panel. List this LED in the device tree. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > arch/arm/boot/dts/armada-370-rd.dts | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts > index be005c9f42ef..15b36aa34ef4 100644 > --- a/arch/arm/boot/dts/armada-370-rd.dts > +++ b/arch/arm/boot/dts/armada-370-rd.dts > @@ -20,6 +20,7 @@ > /dts-v1/; > #include <dt-bindings/input/input.h> > #include <dt-bindings/interrupt-controller/irq.h> > +#include <dt-bindings/leds/common.h> > #include <dt-bindings/gpio/gpio.h> > #include "armada-370.dtsi" > > @@ -135,6 +136,19 @@ &mdio { > pinctrl-names = "default"; > phy0: ethernet-phy@0 { > reg = <0>; > + leds { > + #address-cells = <1>; > + #size-cells = <0>; > + > + led@0 { > + reg = <0>; > + label = "WAN"; WAN or > + color = <LED_COLOR_ID_WHITE>; > + function = LED_FUNCTION_LAN; LAN? > + function-enumerator = <1>; > + linux,default-trigger = "netdev"; > + }; > + }; > }; > > switch: switch@10 { > -- > 2.39.2 >
> > + leds { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + led@0 { > > + reg = <0>; > > + label = "WAN"; > > WAN or > > > + color = <LED_COLOR_ID_WHITE>; > > + function = LED_FUNCTION_LAN; > > LAN? Hi Rob I did not know there was LED_FUNCTION_WAN. I just blindly copied it from some other DT fragment. I will change this, thanks. Andrew
Hi! > > > The WAN port of the 370-RD has a Marvell PHY, with one LED on > > > the front panel. List this LED in the device tree. > > > > > @@ -135,6 +136,19 @@ &mdio { > > > pinctrl-names = "default"; > > > phy0: ethernet-phy@0 { > > > reg = <0>; > > > + leds { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + led@0 { > > > + reg = <0>; > > > + label = "WAN"; > > > + color = <LED_COLOR_ID_WHITE>; > > > + function = LED_FUNCTION_LAN; > > > + function-enumerator = <1>; > > > + linux,default-trigger = "netdev"; > > > + }; > > > > /sys/class/leds/WAN is not acceptable. > > As i said here, that is not what it gets called: > > https://lore.kernel.org/netdev/aa2d0a8b-b98b-4821-9413-158be578e8e0@lunn.ch/T/#m6c72bd355df3fcf8babc0d01dd6bf2697d069407 > > > It can be found in /sys/class/leds/f1072004.mdio-mii:00:WAN. But when > > we come to using it for ledtrig-netdev, the user is more likely to follow > > /sys/class/net/eth0/phydev/leds/f1072004.mdio-mii\:00\:WAN/ > > Is that acceptable? > > What are the acceptance criteria? Acceptance criteria would be "consistent with documentation and with other similar users". If the LED is really white, it should be f1072004.mdio-mii\:white\:WAN, but you probably want f1072004.mdio-mii\:white\:LAN (or :activity), as discussed elsewhere in the thread. Documentation is in Documentation/leds/well-known-leds.txt , so you should probably add a new section about networking, and explain naming scheme for network activity LEDs. When next users appear, I'll point them to the documentation. Does that sound ok? Best regards, Pavel
> Acceptance criteria would be "consistent with documentation and with > other similar users". If the LED is really white, it should be > f1072004.mdio-mii\:white\:WAN, but you probably want > f1072004.mdio-mii\:white\:LAN (or :activity), as discussed elsewhere in the thread. Hi Pavel What i ended up with is: f1072004.mdio-mii:00:white:wan The label on the box is WAN, since it is meant to be a WiFi routers, and this port should connected to your WAN. And this is what the LED code came up with, given my DT description for this device. > Documentation is in Documentation/leds/well-known-leds.txt , so you > should probably add a new section about networking, and explain naming > scheme for network activity LEDs. When next users appear, I'll point > them to the documentation. I added a patch with the following text: * Ethernet LEDs Currently two types of Network LEDs are support, those controlled by the PHY and those by the MAC. In theory both can be present at the same time for one Linux netdev, hence the names need to differ between MAC and PHY. Do not use the netdev name, such as eth0, enp1s0. These are not stable and are not unique. They also don't differentiate between MAC and PHY. ** MAC LEDs Good: f1070000.ethernet:white:WAN Good: mdio_mux-0.1:00:green:left Good: 0000:02:00.0:yellow:top The first part must uniquely name the MAC controller. Then follows the colour. WAN/LAN should be used for a single LED. If there are multiple LEDs, use left/right, or top/bottom to indicate their position on the RJ45 socket. ** PHY LEDs Good: f1072004.mdio-mii:00: white:WAN Good: !mdio-mux!mdio@2!switch@0!mdio:01:green:right Good: r8169-0-200:00:yellow:bottom The first part must uniquely name the PHY. This often means uniquely identifying the MDIO bus controller, and the address on the bus. Andrew
Hi! > > Acceptance criteria would be "consistent with documentation and with > > other similar users". If the LED is really white, it should be > > f1072004.mdio-mii\:white\:WAN, but you probably want > > f1072004.mdio-mii\:white\:LAN (or :activity), as discussed elsewhere in the thread. > > Hi Pavel > > What i ended up with is: > > f1072004.mdio-mii:00:white:wan > > The label on the box is WAN, since it is meant to be a WiFi routers, > and this port should connected to your WAN. And this is what the LED > code came up with, given my DT description for this device. Ok, thanks for explanation. > > Documentation is in Documentation/leds/well-known-leds.txt , so you > > should probably add a new section about networking, and explain naming > > scheme for network activity LEDs. When next users appear, I'll point > > them to the documentation. > > I added a patch with the following text: > > * Ethernet LEDs > > Currently two types of Network LEDs are support, those controlled by > the PHY and those by the MAC. In theory both can be present at the > same time for one Linux netdev, hence the names need to differ between > MAC and PHY. > > Do not use the netdev name, such as eth0, enp1s0. These are not stable > and are not unique. They also don't differentiate between MAC and PHY. > > ** MAC LEDs > > Good: f1070000.ethernet:white:WAN > Good: mdio_mux-0.1:00:green:left > Good: 0000:02:00.0:yellow:top > The first part must uniquely name the MAC controller. Then follows the > colour. WAN/LAN should be used for a single LED. If there are > multiple LEDs, use left/right, or top/bottom to indicate their > position on the RJ45 socket. I don't think basing stuff on position is reasonable. (And am not sure if making difference between MAC and PHY leds is good idea). Normally, there's ethernet port with two LEDs, one is usually green and indicates link, second being yellow and indicates activity, correct? On devices like ADSL modems, there is one LED per port, typically on with link and blinking with activity. Could we use that distinction instead? (id):green:link, (id):yellow:activity, (id):?:linkact -- for combined LED as it seems. Are there any other common leds? I seem to remember "100mbps" lights from time where 100mbit was fast...? Best regards, Pavel
> I don't think basing stuff on position is reasonable. (And am not sure > if making difference between MAC and PHY leds is good idea). > > Normally, there's ethernet port with two LEDs, one is usually green > and indicates link, second being yellow and indicates activity, > correct? Nope. I have machines with 1, 2 or 3 LEDs. I have green, yellow, white and red LEDs. Part of the problem is 802.3 says absolutely nothing about LEDs. So every vendor is free to do whatever why want. There is no standardisation at all. So we have to assume every vendor does something different. > On devices like ADSL modems, there is one LED per port, typically on > with link and blinking with activity. > > Could we use that distinction instead? (id):green:link, > (id):yellow:activity, (id):?:linkact -- for combined LED as it seems. > > Are there any other common leds? I seem to remember "100mbps" lights > from time where 100mbit was fast...? But what about 2.5G, 5G, 10G, 40G... And 10Mbps for automotive. And collision for 1/2 duplex, which is making a bit of a comeback in automotive. Plus, we are using ledtrig-netdev. A wifi device is a netdev. A CAN bus devices is a netdev. Link speed has a totally different meaning for 802.11 and CAN. You are also assuming the LEDs have fixed meaning. But they are not fixed, they mean whatever the ledtrig-netdev is configured to make them blink. I even have one of my boxes blinking heartbeat, because if has a habit of crashing... And i think for Linux LEDs in general, we should not really tie an LED to a meaning. Maybe tie it to a label on the case, but the meaning of an LED is all about software, what ledtrig- is controlling it. As to differentiating MAC and PHY, we need to, because as i said, both could offer LEDs. Generally, Ethernet switches have LED controllers per MAC port. Most switches have internal PHYs, and those PHYs don't have LED controllers. However, not all ports have internal PHYs, there can be external PHYs with its own LED controller. So in that case, both the MAC and the PHY could register an LED controller for the same netdev. It comes down to DT to indicate what LED controllers are actually wired to an LED. Andrew
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts index be005c9f42ef..15b36aa34ef4 100644 --- a/arch/arm/boot/dts/armada-370-rd.dts +++ b/arch/arm/boot/dts/armada-370-rd.dts @@ -20,6 +20,7 @@ /dts-v1/; #include <dt-bindings/input/input.h> #include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/leds/common.h> #include <dt-bindings/gpio/gpio.h> #include "armada-370.dtsi" @@ -135,6 +136,19 @@ &mdio { pinctrl-names = "default"; phy0: ethernet-phy@0 { reg = <0>; + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + label = "WAN"; + color = <LED_COLOR_ID_WHITE>; + function = LED_FUNCTION_LAN; + function-enumerator = <1>; + linux,default-trigger = "netdev"; + }; + }; }; switch: switch@10 {