linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	Jonathan Corbet <corbet@lwn.net>,
	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>,
	Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.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-doc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-leds@vger.kernel.org
Subject: [net-next PATCH v7 16/16] Documentation: LEDs: Describe good names for network LEDs
Date: Mon, 17 Apr 2023 17:17:38 +0200	[thread overview]
Message-ID: <20230417151738.19426-17-ansuelsmth@gmail.com> (raw)
In-Reply-To: <20230417151738.19426-1-ansuelsmth@gmail.com>

From: Andrew Lunn <andrew@lunn.ch>

Network LEDs can exist in both the MAC and the PHY. Naming is
difficult because the netdev name is neither stable or unique, do to
commands like ip link set name eth42 dev eth0, and network
namesspaces.

Give some example names where the MAC and the PHY have unique names
based on device tree nodes, or PCI bus addresses.

Since the LED can be used for anything which Linux supports for LEDs,
avoid using names like activity or link, rather describe the location
on the RJ-45, of what the RJ-45 is expected to be used for, WAN/LAN
etc.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 Documentation/leds/well-known-leds.txt | 30 ++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt
index 2160382c86be..e9c30dc75884 100644
--- a/Documentation/leds/well-known-leds.txt
+++ b/Documentation/leds/well-known-leds.txt
@@ -70,3 +70,33 @@ Good: "platform:*:charging" (allwinner sun50i)
 * Screen
 
 Good: ":backlight" (Motorola Droid 4)
+
+* 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.
-- 
2.39.2


  parent reply	other threads:[~2023-04-17 15:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17 15:17 [net-next PATCH v7 00/16] net: Add basic LED support for switch/phy Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 01/16] net: dsa: qca8k: move qca8k_port_to_phy() to header Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 02/16] net: dsa: qca8k: add LEDs basic support Christian Marangi
2023-04-17 18:28   ` Florian Fainelli
2023-04-17 15:17 ` [net-next PATCH v7 03/16] net: dsa: qca8k: add LEDs blink_set() support Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 04/16] leds: Provide stubs for when CLASS_LED & NEW_LEDS are disabled Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 05/16] net: phy: Add a binding for PHY LEDs Christian Marangi
2023-04-17 18:26   ` Florian Fainelli
2023-04-17 15:17 ` [net-next PATCH v7 06/16] net: phy: phy_device: Call into the PHY driver to set LED brightness Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 07/16] net: phy: marvell: Add software control of the LEDs Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 08/16] net: phy: phy_device: Call into the PHY driver to set LED blinking Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 09/16] net: phy: marvell: Implement led_blink_set() Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 10/16] dt-bindings: net: ethernet-controller: Document support for LEDs node Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 11/16] dt-bindings: net: dsa: qca8k: add LEDs definition example Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 12/16] ARM: dts: qcom: ipq8064-rb3011: Drop unevaluated properties in switch nodes Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 13/16] ARM: dts: qcom: ipq8064-rb3011: Add Switch LED for each port Christian Marangi
2023-04-19 12:53   ` Krzysztof Kozlowski
2023-04-19 14:38     ` Christian Marangi
2023-04-19 18:15       ` Krzysztof Kozlowski
2023-04-17 15:17 ` [net-next PATCH v7 14/16] dt-bindings: net: phy: Document support for LEDs node Christian Marangi
2023-04-17 15:17 ` [net-next PATCH v7 15/16] arm: mvebu: dt: Add PHY LED support for 370-rd WAN port Christian Marangi
2023-04-17 15:17 ` Christian Marangi [this message]
2023-04-19  4:27 ` [net-next PATCH v7 00/16] net: Add basic LED support for switch/phy Jakub Kicinski
2023-04-19 12:20   ` Andrew Lunn
2023-04-19 12:21   ` Andrew Lunn
2023-04-19 12:00 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230417151738.19426-17-ansuelsmth@gmail.com \
    --to=ansuelsmth@gmail.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=gregory.clement@bootlin.com \
    --cc=hkallweit1@gmail.com \
    --cc=john@phrozen.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).