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:   Thu, 21 Apr 2022 13:51:53 +0200
From:   Andrew Lunn <>
To:     Kai-Heng Feng <>
Subject: Re: [PATCH 4/5] net: phy: marvell: Add LED accessors for Marvell

> This is not feasible.
> If BIOS can define a method and restore the LED by itself, it can put
> the method inside its S3 method and I don't have to work on this at
> the first place.

So maybe just declare the BIOS as FUBAR and move on to the next issue
assigned to you.

Do we really want the maintenance burden of this code for one machines
BIOS? Maybe the better solution is to push back on the vendor and its
BIOS, tell them how they should of done this, if the BIOS wants to be
in control of the LEDs it needs to offer the methods to control the
LEDs. And then hopefully the next machine the vendor produces will
have working BIOS.

Your other option is to take part in the effort to add control of the
LEDs via the standard Linux LED subsystem. The Marvel PHY driver is
likely to be one of the first to gain support this for. So you can
then totally take control of the LED from the BIOS and put it in the
users hands. And such a solution will be applicable to many machines,
not just one.


Powered by blists - more mailing lists