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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <953ad608-8be7-42e6-9162-05a98a42eb21@denx.de>
Date: Mon, 20 Jan 2025 15:20:41 +0100
From: Marek Vasut <marex@...x.de>
To: Andrew Lunn <andrew@...n.ch>, Paolo Abeni <pabeni@...hat.com>
Cc: 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 1/16/25 2:23 PM, Andrew Lunn wrote:
> 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?

Sorry for the delayed reply.

> 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().
What about the LED functionality configuration ?

I think the main issue here is that multiple LEDs exposed in sysfs 
control the same bit(s) in hardware, and the sysfs attributes behind 
those LEDs can get out of sync.

One alternative that crossed my mind would be to register single LED in 
the KSZ87xx switch driver to control the LED functionality, and per-port 
LED to control the per-port LED enablement (=brightness). It does not 
model the hardware accurately, but it does avoid the complexity.

Otherwise, what is left would be custom sysfs attributes for this switch?