Merge branch 'net-phy-honor-eee_disabled_modes-when-advertising-eee'

Nicolai Buchwitz says:

====================
net: phy: honor eee_disabled_modes when advertising EEE

While debugging why ethtool --show-eee reports "not supported" on a
Raspberry Pi CM4 with eee-broken-1000t / eee-broken-100tx set on the
PHY node, I noticed two phylib helpers copy phydev->supported_eee
into phydev->advertising_eee without applying
phydev->eee_disabled_modes: phy_support_eee() and
phy_advertise_eee_all(). That undoes the filtering phy_probe() set
up after of_set_phy_eee_broken(), so the PHY ends up advertising EEE
for modes that were marked broken in DT (or by the driver via
eee_disabled_modes).

The visible effect on MAC drivers that call phy_support_eee() after
probe (bcmgenet, fec, lan743x, lan78xx, r8169) is that ethtool on the
local interface reports "not supported" (because supported is masked
by eee_disabled_modes and ends up empty), while the link partner
happily sees EEE negotiated and active.

Patch 1 fixes phy_support_eee(). Patch 2 fixes phy_advertise_eee_all(),
which is also reached from genphy_c45_ethtool_set_eee() when user
space passes an empty advertisement.

I went through the other users of supported_eee as suggested by Andrew
and they look fine:

  - phy_probe() already masks via eee_disabled_modes after
    of_set_phy_eee_broken().
  - genphy_c45_ethtool_get_eee() masks supported_eee with
    eee_disabled_modes when reporting to user space.
  - genphy_c45_ethtool_set_eee() masks user-supplied adv against
    eee_disabled_modes, and the empty-adv path is now covered by
    patch 2.
  - genphy_c45_read_eee_abilities(), read_eee_cap1/cap2 populate
    supported_eee from PHY registers (source of truth).
  - genphy_c45_read_eee_adv(), read_eee_lpa() and write_eee_adv() use
    supported_eee only to gate which MMD registers to access, not to
    construct an advertisement.
====================

Link: https://patch.msgid.link/20260518-devel-phy-support-eee-fix-v2-0-05b52626fa68@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>