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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 7 Aug 2020 11:06:53 +0200
From:   Pavel Machek <>
To:     Marek Behún <>
Cc:,,, Dan Murphy <>,
        Ondřej Jirman <>,
        Russell King <>,
        Thomas Petazzoni <>,
        Gregory Clement <>,
        Andrew Lunn <>,
Subject: Re: [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on
 Marvell PHYs


> this is v4 of my RFC adding support for LEDs connected to Marvell PHYs.
> Please note that if you want to test this, you still need to first apply
> the patch adding the LED private triggers support from Pavel's tree.
> What I still don't like about this is that the LEDs created by the code
> don't properly support device names. LEDs should have name in format
> "device:color:function", for example "eth0:green:activity".
> The code currently looks for attached netdev for a given PHY, but
> at the time this happens there is no netdev attached, so the LEDs gets
> names without the device part (ie ":green:activity").
> This can be addressed in next version by renaming the LED when a netdev
> is attached to the PHY, but first a API for LED device renaming needs to
> be proposed. I am going to try to do that. This would also solve the
> same problem when userspace renames an interface.
> And no, I don't want phydev name there.

Ummm. Can we get little more explanation on that? I fear that LED
device renaming will be tricky and phydev would work around that

Best regards,
(cesky, pictures)

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)

Powered by blists - more mailing lists