[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ef933bd4-b9ae-4f78-8f05-abd1d2832bf8@lunn.ch>
Date: Thu, 16 Jan 2025 14:23:39 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Marek Vasut <marex@...x.de>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
Russell King <linux@...linux.org.uk>,
Tristram Ha <tristram.ha@...rochip.com>,
UNGLinuxDriver@...rochip.com, Vladimir Oltean <olteanv@...il.com>,
Woojung Huh <woojung.huh@...rochip.com>,
linux-kernel@...r.kernel.org
Subject: Re: [net-next,PATCH 2/2] net: phy: micrel: Add KSZ87XX Switch LED
control
On Thu, Jan 16, 2025 at 10:58:38AM +0100, Paolo Abeni wrote:
> On 1/13/25 1:15 AM, Marek Vasut wrote:
> > The KSZ87xx switch contains LED control registers. There is one shared
> > global control register bitfield which affects behavior of all LEDs on
> > all ports, the Register 11 (0x0B): Global Control 9 bitfield [5:4].
> > There is also one per-port Register 29/45/61 (0x1D/0x2D/0x3D): Port 1/2/3
> > Control 10 bit 7 which controls enablement of both LEDs on each port
> > separately.
> >
> > Expose LED brightness control and HW offload support for both of the two
> > programmable LEDs on this KSZ87XX Switch. Note that on KSZ87xx there are
> > three or more instances of simple KSZ87XX Switch PHY, one for each port,
> > however, the registers which control the LED behavior are mostly shared.
> >
> > Introduce LED brightness control using Register 29/45/61 (0x1D/0x2D/0x3D):
> > Port 1/2/3 Control 10 bit 7. This bit selects between LEDs disabled and
> > LEDs set to Function mode. In case LED brightness is set to 0, both LEDs
> > are turned off, otherwise both LEDs are configured to Function mode which
> > follows the global Register 11 (0x0B): Global Control 9 bitfield [5:4]
> > setting.
>
> @Andrew, @Russel: can the above problem be address with the current phy
> API? or does phy device need to expose a new brightness_get op?
Coupled LEDs cause issues. Because vendors do all sorts of weird
things with LEDs, i don't want to fully support everything every
vendor has, or the code is just going to be unmaintanable. So we have
the core support a subset, and some features of the hardware go
unused.
In this case, i would say software control of the LEDs is
impossible. You cannot individually turn an LED on/off. The core
supports this, Heiner added support for a PHY with similar issues. I
think it is as simple as not implementing led_brightness_set().
Andrew
---
pw-bot: cr
Powered by blists - more mailing lists