Re: [net-next,PATCH 2/2] net: phy: micrel: Add KSZ87XX Switch LED control

[Andrew Lunn]

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