[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YeGyFabsBAfzvnU+@lunn.ch>
Date: Fri, 14 Jan 2022 18:25:41 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc: peppe.cavallaro@...com, alexandre.torgue@...s.st.com,
joabreu@...opsys.com, "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Marek Behún <kabel@...nel.org>,
Ivan Bornyakov <i.bornyakov@...rotek.ru>,
Pali Rohár <pali@...nel.org>,
netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] stmmac: intel: Honor phy LED set by system firmware
on a Dell hardware
> > This is a PHY property. Why is the MAC involved?
>
> This is inspired by commit a93f7fe13454 ("net: phy: marvell: add new
> default led configure for m88e151x") which passes the flag from MAC to
> PHY.
But in this case, the MAC does not care what the LEDs are. The
platform wants them left alone, not the MAC.
> > Please also think about how to make this generic, so any ACPI based
> > system can use it, with any PHY.
...
> So the only approach I can think of is to use DMI match directly in PHY driver.
In the phylib core. And the core then asks the specific PHY driver to
not touch the LED configuration. It is then generic.
Andrew
Powered by blists - more mailing lists