netdev - Re: [PATCH v2] net: phy: marvell: Honor phy LED set by system firmware on a Dell hardware

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YerOIXi7afbH/3QJ@lunn.ch>
Date:   Fri, 21 Jan 2022 16:15:45 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     hkallweit1@...il.com, linux@...linux.org.uk,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net: phy: marvell: Honor phy LED set by system
 firmware on a Dell hardware

> > They are similar to what DT has, but expressed in an ACPI way. DT has
> > been used with PHY drivers for a long time, but ACPI is new. The ACPI
> > standard also says nothing about PHYs. So Linux has defined its own
> > properties, which we expect all ACPI machine to use. According to the
> > ACPI maintainers, this is within the ACPI standard. Maybe at some
> > point somebody will submit the current definitions to the standards
> > body for approval, or maybe the standard will do something completely
> > different, but for the moment, this is what we have, and what you
> > should use.
> 
> Right, so we can add a new property, document it, and just use it?

Yes. So long as you follow the scheme documented there, cleanly
integrate it into the code as needed, you can add a new property.

> Maybe others will use the new property once we set the precedence?

Yes, which is why i keep saying you need to think of the general case,
not your specific machine.

> How about what Heiner proposed? Maybe we should leave the LED as is,
> and restore it on system resume?

I don't think we can change the current code because it will cause
regressions. The LEDs probably work on some boards because of the
current code.

At some point in the future, we hope to be able to control the PHY
LEDs via /sys/class/LEDs. But until then, telling the PHY driver to
not touch the LED configuration seems a reasonable request.

    Andrew