linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Christian Marangi <ansuelsmth@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>
Cc: 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>,
	Jonathan Corbet <corbet@lwn.net>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	Jacek Anaszewski <jacek.anaszewski@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-doc@vger.kernel.org, Tim Harvey <tharvey@gateworks.com>,
	Alexander Stein <alexander.stein@ew.tq-group.com>,
	Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Arun.Ramadoss@microchip.com
Subject: Re: [PATCH v8 00/13] Adds support for PHY LEDs with offload triggers
Date: Thu, 9 Mar 2023 10:09:18 +0100	[thread overview]
Message-ID: <CACRpkda30Ky5oYPn_nGWGOzT5ntZYdE3gafrs7D27ZHxgGuO8A@mail.gmail.com> (raw)
In-Reply-To: <20230216013230.22978-1-ansuelsmth@gmail.com>

Hi Christian,

thanks for your patch!

On Thu, Feb 16, 2023 at 2:36 AM Christian Marangi <ansuelsmth@gmail.com> wrote:

> The current idea is:
> - LED driver implement 3 API (hw_control_status/start/stop).
>   They are used to put the LED in hardware mode and to configure the
>   various trigger.
> - We have hardware triggers that are used to expose to userspace the
>   supported hardware mode and set the hardware mode on trigger
>   activation.
> - We can also have triggers that both support hardware and software mode.
> - The LED driver will declare each supported hardware blink mode and
>   communicate with the trigger all the supported blink modes that will
>   be available by sysfs.
> - A trigger will use blink_set to configure the blink mode to active
>   in hardware mode.
> - On hardware trigger activation, only the hardware mode is enabled but
>   the blink modes are not configured. The LED driver should reset any
>   link mode active by default.

The series looks good as a start.
There are some drivers and HW definitions etc for switch-controlled
LEDs, which is great.

I am a bit reluctant on the ambition to rely on configuration from sysfs
for the triggers, and I am also puzzled to how a certain trigger on a
certain LED is going to associate itself with, say, a certain port.

I want to draw your attention to this recently merged patch series
from Hans de Goede:
https://lore.kernel.org/linux-leds/20230120114524.408368-1-hdegoede@redhat.com/

This adds the devm_led_get() API which works similar to getting
regulators, clocks, GPIOs or any other resources.

It is not yet (I think) hooked into the device tree framework, but it
supports software nodes so adding DT handling should be sort of
trivial.

I think the ambition should be something like this (conjured example)
for a DSA switch:

    platform {
            switch {
                    compatible = "foo";

                    leds {
                            #address-cells = <1>;
                            #size-cells = <0>;
                            led0: led@0 {
                                    reg = <0>;
                                    color =...
                                    function = ...
                                    function-enumerator = ...
                                    default-state = ...
                            };
                            led1: led@1 {
                                    reg = <1>;
                                    color =...
                                    function = ...
                                    function-enumerator = ...
                                    default-state = ...
                            };
                    };

                    ports {
                            #address-cells = <1>;
                            #size-cells = <0>;
                            port@0 {
                                    reg = <0>;
                                    label = "lan0";
                                    phy-handle = <&phy0>;
                                    leds = <&led0>;
                            };
                            port@1 {
                                    reg = <1>;
                                    label = "lan1";
                                    phy-handle = <&phy1>;
                                    leds = <&led0>;
                            };
                    };

                    mdio {
                            compatible = "foo-mdio";
                            #address-cells = <1>;
                            #size-cells = <0>;

                            phy0: ethernet-phy@0 {
                                    reg = <0>;
                            };
                            phy1: ethernet-phy@1 {
                                    reg = <1>;
                            };
                    };
            };
    };

I am not the man to tell whether the leds = <&led0>; phandle should be on
the port or actually on the phy, it may even vary. You guys know the answer
to this.

But certainly something like this resource phandle will be necessary to
assign the right LED to the right port or phy, I hope you were not going
to rely on strings and naming conventions?

Yours,
Linus Walleij

  parent reply	other threads:[~2023-03-09  9:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16  1:32 [PATCH v8 00/13] Adds support for PHY LEDs with offload triggers Christian Marangi
2023-02-16  1:32 ` [PATCH v8 01/13] leds: add support for hardware driven LEDs Christian Marangi
2023-02-16  1:32 ` [PATCH v8 02/13] leds: add function to configure hardware controlled LED Christian Marangi
2023-02-16  1:32 ` [PATCH v8 03/13] leds: trigger: netdev: drop NETDEV_LED_MODE_LINKUP from mode Christian Marangi
2023-02-16  1:32 ` [PATCH v8 04/13] leds: trigger: netdev: rename and expose NETDEV trigger enum modes Christian Marangi
2023-02-16  1:32 ` [PATCH v8 05/13] leds: trigger: netdev: convert device attr to macro Christian Marangi
2023-02-16  1:32 ` [PATCH v8 06/13] leds: trigger: netdev: add hardware control support Christian Marangi
2023-02-16  1:32 ` [PATCH v8 07/13] leds: trigger: netdev: use mutex instead of spinlocks Christian Marangi
2023-02-16  1:32 ` [PATCH v8 08/13] leds: trigger: netdev: add available mode sysfs attr Christian Marangi
2023-02-16  1:32 ` [PATCH v8 09/13] leds: trigger: netdev: add additional hardware only triggers Christian Marangi
2023-02-16  1:32 ` [PATCH v8 10/13] net: dsa: qca8k: add LEDs support Christian Marangi
2023-02-16  1:32 ` [PATCH v8 11/13] dt-bindings: leds: Document netdev trigger Christian Marangi
2023-02-17 23:03   ` Rob Herring
2023-02-17  5:58     ` Christian Marangi
2023-02-21  1:44       ` Rob Herring
2023-02-16  1:32 ` [PATCH v8 12/13] dt-bindings: net: phy: Document support for leds node Christian Marangi
2023-02-16  2:32   ` Rob Herring
2023-02-16 10:00     ` Christian Marangi
2023-02-17 23:10       ` Rob Herring
2023-02-16  1:32 ` [PATCH v8 13/13] dt-bindings: net: dsa: qca8k: add LEDs definition example Christian Marangi
2023-02-21  1:48   ` Rob Herring
2023-02-17 14:30 ` [PATCH v8 00/13] Adds support for PHY LEDs with offload triggers Andrew Lunn
2023-02-17  5:01   ` Christian Marangi
2023-02-22 15:02   ` Lee Jones
2023-03-06 18:43     ` Christian Marangi
2023-03-08 14:06       ` Lee Jones
2023-03-09  9:09 ` Linus Walleij [this message]
2023-03-09  9:32   ` Hans de Goede
2023-03-09 15:22   ` Andrew Lunn
2023-03-10  9:37     ` Linus Walleij
2023-03-10 15:15       ` Andrew Lunn
2023-03-13  9:28         ` Michael Walle

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=CACRpkda30Ky5oYPn_nGWGOzT5ntZYdE3gafrs7D27ZHxgGuO8A@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=Arun.Ramadoss@microchip.com \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=bagasdotme@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=hdegoede@redhat.com \
    --cc=hkallweit1@gmail.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=john@phrozen.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lee@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=rasmus.villemoes@prevas.dk \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robh+dt@kernel.org \
    --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).