Re: [PATCH] net: phy: honor eee_disabled_modes in phy_support_eee()

[Nicolai Buchwitz]

Hi Andrew

On May 16, 2026 4:40:25 PM GMT+02:00, Andrew Lunn <andrew@xxxxxxx> wrote:
>On Sat, May 16, 2026 at 06:51:02AM +0200, Nicolai Buchwitz wrote:
>> phy_support_eee() copies supported_eee into advertising_eee
>> unconditionally, overwriting any filtering applied during phy_probe()
>> based on DT eee-broken-* properties or driver-populated
>> eee_disabled_modes. MAC drivers that call phy_support_eee() after
>> probe (e.g. bcmgenet, fec, lan743x, lan78xx, r8169) then cause the PHY
>> to advertise EEE for modes the user marked as broken.
>> 
>> The symptom is that ethtool --show-eee on the local interface reports
>> "not supported" (supported & ~eee_disabled_modes is empty) while the
>> link partner sees EEE negotiated and active.
>> 
>> phy_probe() already filters advertising_eee via eee_disabled_modes
>> after calling of_set_phy_eee_broken(). Apply the same mask in
>> phy_support_eee() so the filtering survives the copy.
>
>I don't think this not the full fix.

You're right, this only fixes the initial behavior on boot.

>
>of_set_phy_eee_broken() sets phydev->eee_disabled_modes.
>
>genphy_c45_ethtool_get_eee() masks supported_eee with this when
>reporting to user space what is supported.
>
>genphy_c45_ethtool_set_eee() will also mask what user space passes in,
>if it is not empty. However, if nothing is passed in,
>phy_advertise_eee_all() is used, and that does not make use of
>phydev->eee_disabled_modes, which i think it should.

Agree, will fix this in v2.

>
>So while your fix seems correct, i don't think on its own, it is
>sufficient. Whenever phydev->supported_eee is used, we need to review
>the code and see if it should be masked by phydev->eee_disabled_modes.

I will have a look and try to catch all scenarios.

>
>    Andrew
>
>---
>pw-bot: cr

Thanks
Nicolai