From: Rob Herring <robh@kernel.org>
To: Christian Marangi <ansuelsmth@gmail.com>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: 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>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Jonathan Corbet <corbet@lwn.net>, Pavel Machek <pavel@ucw.cz>,
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
John Crispin <john@phrozen.org>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-leds@vger.kernel.org, Tim Harvey <tharvey@gateworks.com>,
Alexander Stein <alexander.stein@ew.tq-group.com>,
Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Subject: Re: [PATCH v7 11/11] dt-bindings: net: dsa: qca8k: add LEDs definition example
Date: Wed, 21 Dec 2022 09:29:15 -0600 [thread overview]
Message-ID: <CAL_JsqLOvCJ_aHk4jSp64u1LbGyoeTjY_vRgVkvvVNCOp=3NmA@mail.gmail.com> (raw)
In-Reply-To: <63a30221.050a0220.16e5f.653a@mx.google.com>
On Wed, Dec 21, 2022 at 6:55 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> On Wed, Dec 21, 2022 at 02:41:50AM +0100, Andrew Lunn wrote:
> > > > > + };
> > > > > +
> > > > > + led@1 {
> > > > > + reg = <1>;
> > > > > + color = <LED_COLOR_ID_AMBER>;
> > > > > + function = LED_FUNCTION_LAN;
> > > > > + function-enumerator = <1>;
> > > >
> > > > Typo? These are supposed to be unique. Can't you use 'reg' in your case?
> > >
> > > reg in this context is the address of the PHY on the MDIO bus. This is
> > > an Ethernet switch, so has many PHYs, each with its own address.
> >
> > Actually, i'm wrong about that. reg in this context is the LED number
> > of the PHY. Typically there are 2 or 3 LEDs per PHY.
> >
> > There is no reason the properties need to be unique. Often the LEDs
> > have 8 or 16 functions, identical for each LED, but with different
> > reset defaults so they show different things.
> >
>
> Are we taking about reg or function-enumerator?
>
> For reg it's really specific to the driver... My idea was that since a
> single phy can have multiple leds attached, reg will represent the led
> number.
>
> This is an example of the dt implemented on a real device.
>
> mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> phy_port1: phy@0 {
> reg = <0>;
>
> leds {
> #address-cells = <1>;
> #size-cells = <0>;
>
> lan1_led@0 {
> reg = <0>;
> color = <LED_COLOR_ID_WHITE>;
> function = LED_FUNCTION_LAN;
> function-enumerator = <1>;
> linux,default-trigger = "netdev";
> };
>
> lan1_led@1 {
> reg = <1>;
> color = <LED_COLOR_ID_AMBER>;
> function = LED_FUNCTION_LAN;
> function-enumerator = <1>;
> linux,default-trigger = "netdev";
> };
> };
> };
>
> phy_port2: phy@1 {
> reg = <1>;
>
> leds {
> #address-cells = <1>;
> #size-cells = <0>;
>
>
> lan2_led@0 {
> reg = <0>;
> color = <LED_COLOR_ID_WHITE>;
> function = LED_FUNCTION_LAN;
> function-enumerator = <2>;
> linux,default-trigger = "netdev";
> };
>
> lan2_led@1 {
> reg = <1>;
> color = <LED_COLOR_ID_AMBER>;
> function = LED_FUNCTION_LAN;
> function-enumerator = <2>;
> linux,default-trigger = "netdev";
> };
> };
> };
>
> phy_port3: phy@2 {
> reg = <2>;
>
> leds {
> #address-cells = <1>;
> #size-cells = <0>;
>
> lan3_led@0 {
> reg = <0>;
> color = <LED_COLOR_ID_WHITE>;
> function = LED_FUNCTION_LAN;
> function-enumerator = <3>;
> linux,default-trigger = "netdev";
> };
>
> lan3_led@1 {
> reg = <1>;
> color = <LED_COLOR_ID_AMBER>;
> function = LED_FUNCTION_LAN;
> function-enumerator = <3>;
> linux,default-trigger = "netdev";
> };
> };
> };
>
> In the following implementation. Each port have 2 leds attached (out of
> 3) one white and one amber. The driver parse the reg and calculate the
> offset to set the correct option with the regs by also checking the phy
> number.
Okay, the full example makes more sense. But I still thought
'function-enumerator' values should be globally unique within a value
of 'function'. Maybe Jacek has an opinion on this?
You are using it to distinguish phys/ports, but there's already enough
information in the DT to do that. You have the parent nodes and I
assume you have port numbers under 'ethernet-ports'. For each port,
get the phy node and then get the LEDs.
> An alternative way would be set the reg to be the global led number in
> the switch and deatch the phy from the calculation.
>
> Something like
> port 0 led 0 = reg 0
> port 0 led 1 = reg 1
> port 1 led 0 = reg 2
> port 1 led 1 = reg 3
> ...
No.
Rob
next prev parent reply other threads:[~2022-12-21 15:34 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 23:54 [PATCH v7 00/11] Adds support for PHY LEDs with offload triggers Christian Marangi
2022-12-14 23:54 ` [PATCH v7 01/11] leds: add support for hardware driven LEDs Christian Marangi
2022-12-15 4:40 ` kernel test robot
2022-12-15 5:10 ` kernel test robot
2022-12-15 16:13 ` Russell King (Oracle)
2022-12-16 16:45 ` Christian Marangi
2022-12-16 16:51 ` Russell King (Oracle)
2022-12-20 23:35 ` Andrew Lunn
2023-01-03 5:40 ` Bagas Sanjaya
2022-12-14 23:54 ` [PATCH v7 02/11] leds: add function to configure hardware controlled LED Christian Marangi
2022-12-15 16:30 ` Russell King (Oracle)
2022-12-16 16:58 ` Christian Marangi
2022-12-14 23:54 ` [PATCH v7 03/11] leds: trigger: netdev: drop NETDEV_LED_MODE_LINKUP from mode Christian Marangi
2022-12-14 23:54 ` [PATCH v7 04/11] leds: trigger: netdev: rename and expose NETDEV trigger enum modes Christian Marangi
2022-12-20 23:48 ` Andrew Lunn
2022-12-14 23:54 ` [PATCH v7 05/11] leds: trigger: netdev: convert device attr to macro Christian Marangi
2022-12-14 23:54 ` [PATCH v7 06/11] leds: trigger: netdev: add hardware control support Christian Marangi
2022-12-15 5:31 ` kernel test robot
2022-12-15 15:27 ` Alexander Stein
2022-12-16 17:00 ` Christian Marangi
2023-01-02 12:44 ` Alexander Stein
2022-12-15 17:07 ` Russell King (Oracle)
2022-12-16 17:09 ` Christian Marangi
2022-12-20 23:59 ` Andrew Lunn
2022-12-21 9:54 ` Russell King (Oracle)
2022-12-21 13:00 ` Christian Marangi
2022-12-21 13:10 ` Andrew Lunn
2022-12-14 23:54 ` [PATCH v7 07/11] leds: trigger: netdev: use mutex instead of spinlocks Christian Marangi
2022-12-14 23:54 ` [PATCH v7 08/11] leds: trigger: netdev: add available mode sysfs attr Christian Marangi
2022-12-14 23:54 ` [PATCH v7 09/11] leds: trigger: netdev: add additional hardware only triggers Christian Marangi
2022-12-15 17:35 ` Russell King (Oracle)
2022-12-16 17:17 ` Christian Marangi
2022-12-21 0:12 ` Andrew Lunn
2022-12-21 12:56 ` Christian Marangi
2022-12-14 23:54 ` [PATCH v7 10/11] net: dsa: qca8k: add LEDs support Christian Marangi
2022-12-15 3:50 ` kernel test robot
2022-12-15 3:54 ` Arun.Ramadoss
2022-12-15 17:49 ` Russell King (Oracle)
2022-12-16 17:48 ` Christian Marangi
2022-12-20 23:11 ` Andrew Lunn
2022-12-14 23:54 ` [PATCH v7 11/11] dt-bindings: net: dsa: qca8k: add LEDs definition example Christian Marangi
2022-12-20 17:39 ` Rob Herring
2022-12-20 23:20 ` Andrew Lunn
2022-12-21 1:41 ` Andrew Lunn
2022-12-21 12:54 ` Christian Marangi
2022-12-21 12:59 ` Andrew Lunn
2022-12-21 15:29 ` Rob Herring [this message]
2023-01-29 20:43 ` Sander Vanheule
2023-01-29 22:02 ` Andrew Lunn
2023-01-30 10:59 ` Sander Vanheule
2023-01-30 13:48 ` Andrew Lunn
2022-12-20 23:23 ` Andrew Lunn
2022-12-15 15:34 ` [PATCH v7 00/11] Adds support for PHY LEDs with offload triggers Alexander Stein
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='CAL_JsqLOvCJ_aHk4jSp64u1LbGyoeTjY_vRgVkvvVNCOp=3NmA@mail.gmail.com' \
--to=robh@kernel.org \
--cc=alexander.stein@ew.tq-group.com \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=jacek.anaszewski@gmail.com \
--cc=john@phrozen.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=pavel@ucw.cz \
--cc=rasmus.villemoes@prevas.dk \
--cc=rmk+kernel@armlinux.org.uk \
--cc=tharvey@gateworks.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).