[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <796d0096-1cf9-4234-9117-440469c4e9d9@lunn.ch>
Date: Thu, 3 Oct 2024 14:05:15 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Marek Vasut <marex@...x.de>
Cc: linux-leds@...r.kernel.org,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Christian Marangi <ansuelsmth@...il.com>,
Christophe Roullier <christophe.roullier@...s.st.com>,
Daniel Golle <daniel@...rotopia.org>,
Heiner Kallweit <hkallweit1@...il.com>, Lee Jones <lee@...nel.org>,
Lukasz Majewski <lukma@...x.de>, Pavel Machek <pavel@....cz>,
kernel@...electronics.com, linux-stm32@...md-mailman.stormreply.com,
netdev@...r.kernel.org
Subject: Re: [PATCH] leds: trigger: netdev: Check offload ability on
interface up
> > Nice use of udev. I had not thought about using it for this.
> Is there some other way to configure the netdev-triggered PHY LEDs ?
> I still feel the udev rule is somewhat brittle and fragile, and also not
> available early enough for default PHY LED configuration, i.e. the LEDs are
> not blinking when I use e.g. ip=/nfsroot= when booting from NFS root until
> the userspace started, which is not nice. The only alternative I can imagine
> is default configuration in DT, which was already rejected a few years ago.
Device tree is the only early way i can think of, especially for NFS
root.
What has clearly been rejected is each vendor having their own DT
binding. But i think we might have more success with one generic
binding for all MAC/PHY LEDs.
The way i was thinking about it, was to describe the label on the
front panel. That is hardware you are describing, so fits DT.
We are clearly in the grey area for DT, so i can understand some push
back on this from the DT Maintainers.
Andrew
Powered by blists - more mailing lists