[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200420172013.GZ25745@shell.armlinux.org.uk>
Date: Mon, 20 Apr 2020 18:20:13 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Michael Walle <michael@...le.cc>
Cc: Andrew Lunn <andrew@...n.ch>, linux-hwmon@...r.kernel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 3/3] net: phy: bcm54140: add hwmon support
On Mon, Apr 20, 2020 at 05:10:19PM +0200, Michael Walle wrote:
> Hi Andrew,
>
> Am 2020-04-19 23:55, schrieb Andrew Lunn:
> > > But what does that have to do with the shared structure? I don't think
> > > you have to "bundle" the shared structure with the "access the global
> > > registers" method.
> >
> > We don't need to. But it would be a good way to clean up code which
> > locks the mdio bus, does a register access on some other device, and
> > then unlocks the bus.
>
> I'd like do an RFC for that. But how should I proceed with the original
> patch series? Should I send an updated version; you didn't reply to the
> LED stuff. That is the last remark for now.
The LED stuff is something that there isn't a solution for at the
moment. There's been talk about coming up with some generic way
to describe the PHY LED configuration in DT, but given that almost
every PHY has quite different ways to configure LEDs, I fear such
a task is virtually impossible.
Very few PHYs under Linux have their LEDs operating "correctly" or
in a meaningful or sensible way because of this, and it's been this
way for years.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
Powered by blists - more mailing lists