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

[Heiner Kallweit <hkallweit1@gmail.com>]

On 21.01.2022 16:15, Andrew Lunn wrote:
>>> 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.
> 
One more idea:
The hw reset default for register 16 is 0x101e. If the current value
is different when entering config_init then we could preserve it
because intentionally a specific value has been set.
Only if we find the hw reset default we'd set the values according
to 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
Heiner