linux-kernel - Re: [PATCH net-next,v2 2/2] net: phy: mxl-gpy: add LED dimming support

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: <ne2yghzgmsvmucepsvdfpcobumucoijtbgczdhb64kuvkbk7d3@3s5xew72bri4>
Date: Sun, 6 Apr 2025 14:20:49 +0200
From: Marek Behún <kabel@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Aleksander Jan Bajkowski <olek2@...pl>, lxu@...linear.com, 
	hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, lee@...nel.org, linux-leds@...r.kernel.org, 
	Daniel Golle <daniel@...rotopia.org>
Subject: Re: [PATCH net-next,v2 2/2] net: phy: mxl-gpy: add LED dimming
 support

On Sat, Apr 05, 2025 at 09:52:43PM +0200, Andrew Lunn wrote:
> On Sat, Apr 05, 2025 at 09:09:54PM +0200, Aleksander Jan Bajkowski wrote:
> > Some PHYs support LED dimming. The use case is a router that dims LEDs
> > at night. In the GPY2xx series, the PWM control register is common to
> > all LEDs. To avoid confusing users, only the first LED used has
> > brightness control enabled.
> 
> I don't know the LED subsystem very well. But struct led_classdev has:
> 
>         /* Get LED brightness level */
>         enum led_brightness (*brightness_get)(struct led_classdev *led_cdev);
> 
> The fact this exists, suggests the LED brightness can change outside
> of the control of Linux. Maybe even your very use cases of one PWM for
> multiple LEDs? You might get a more consistent user experience if you
> allow the brightness bet set with all the LEDs, and implement this
> callback so the current brightness can be reported per LED?
> 
> Lets see what the LED subsystem people say?

Regardless of whether LED class device blinking is offloaded to HW or
not, it should behave the same way as it does when controlled by
software.

The sysfs brightness file controls the brightness of the LED.
When no trigger is enabled on the LED, this is very simple:
- setting brightness to 0 disables the LED
- setting brightness to the value max_brightness lights the LED
  to maximum possible brightness
- values between 0 and max_brightness can be also used, to light
  the LED in some in-between value

When a trigger is set, this can get a little bit more complicated,
but not for the netdev trigger. The netdev trigger only blinks
the LED, which means that it changes it between two states:
- disabled
- brightness that was set into sysfs brightness file

So if netdev is blinking with LED, you are supposed to be able to
change the ON state brightness by writing to the sysfs brightness
file.

If you enable the netdev trigger on a LED (echo netdev >trigger)
while current brightness is set to a non-zero value, then this
non-zero value should be used for the ON state when blinking.
If you enable it while current brightness is zero, then
max_brightness is used. This is done in the set_baseline_state()
function, the blinking brightness is stored into the
led_cdev->blink_brightness member.

And also, when writing new code, or refactoring old one, stop using
the LED_OFF, LED_ON and LED_HALF and LED_FULL constants.
They are deprecated.

We should get rid of the whole enum led_brightness and use an
unsigned int instead.

Marek