Date:   Thu, 9 Mar 2023 16:22:23 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Christian Marangi <ansuelsmth@...il.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Jonathan Corbet <corbet@....net>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        John Crispin <john@...ozen.org>, linux-leds@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, linux-doc@...r.kernel.org,
        Tim Harvey <tharvey@...eworks.com>,
        Alexander Stein <alexander.stein@...tq-group.com>,
        Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Arun.Ramadoss@...rochip.com
Subject: Re: [PATCH v8 00/13] Adds support for PHY LEDs with offload triggers

> 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.

Hi Linus

There will need to be a device tree binding for the default
trigger. That is what nearly all the rejected hacks so far have been
about, write registers in the PHYs LEDs registers to put it into a
specific mode. I don't see that part of the overall problem too
problematic, apart from the old issue, is it describing configuration,
not hardware.

As to 'how a certain trigger on a certain LED is going to associate
itself with, say, a certain port' is clearly a property of the
hardware, when offloading is supported. I've not seen a switch you can
arbitrarily assign LEDs to ports. The Marvell switches have the LED
registers within the port registers, for example, two LEDs per 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.

Interesting. Thanks for pointing this out. But i don't think it is of
interest in our use case, which is hardware offload. For a purely
software controlled LED, where the LED could be anywhere,
devm_led_get() makes sense. But in our case, the LED is in a well
defined place, either the MAC or the PHY, where it has access to the
RX and TX packets, link status etc. So we don't have the problem of
finding it in an arbitrary location.

There is also one additional problem we have, both for MAC and PHY
LEDs. The trigger is ledtrig-netdev. All trigger state revolves around
a netdev. A DSA port is not a netdev. A PHY is not a netdev. Each of
these three things have there own life cycle. Often, a PHY does not
know what netdev it is associated to until the interface is opened,
ie. ip link set eth0 up. But once it is associated, phylib knows this
information, so can return it, without any additional configuration
data in DT. A DSA switch port can be created before the netdev
associated to it is created. But again, the DSA core does know the
mapping between a netdev and a port. Using devm_led_get() does not
gain us anything.

	Andrew

Powered by blists - more mailing lists