netdev - [RFC] net: dsa: slave: Advertise correct EEE capabilities at slave PHY setup

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

Date: Tue, 30 May 2023 14:26:21 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Andrew Lunn <andrew@...n.ch>,
	Russell King <linux@...linux.org.uk>
Cc: Vivien Didelot <vivien.didelot@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Lukasz Majewski <lukma@...x.de>
Subject: [RFC] net: dsa: slave: Advertise correct EEE capabilities at slave PHY setup

One can disable in device tree advertising of EEE capabilities of PHY
when 'eee-broken-100tx' property is present in DTS.

With DSA switch it also may happen that one would need to disable EEE due
to some network issues.

Corresponding switch DTS description:

 switch@0 {
	 ports {
		port@0 {
		reg = <0>;
		label = "lan1";
		phy-handle = <&switchphy0>;
		};
	}
	mdio {
		switchphy0: switchphy@0 {
		reg = <0>;
		eee-broken-100tx;
	};
	};

This patch adjusts the content of MDIO_AN_EEE_ADV in MDIO_MMD_AN "device"
so the phydev->eee_broken_modes are taken into account from the start of
the slave PHYs.

As a result the 'ethtool --show-eee lan1' shows that EEE is not supported
from the outset.

Questions:

- Is the genphy_config_eee_advert() appropriate to be used here?
  As I found this issue on 5.15 kernel, it looks like mainline now uses
  PHY features for handle EEE (but the aforementioned function is still
  present in newest mainline - v6.4-rc1).

- I've also observed strange behaviour for EEE capability register:
  Why the value in MDIO_MMD_PCS device; reg MDIO_PCS_EEE_ABLE is somewhat
  "volatile" - in a sense that when I use:
  ethtool --set-eee lan2 eee off

  It is cleared by PHY itself to 0x0 (from 0x2) and turning it on again is
  not working.

  Is this expected? Or am I missing something?



Signed-off-by: Lukasz Majewski <lukma@...x.de>
---
 net/dsa/slave.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 353d8fff3166..712923c7d4e2 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -2247,6 +2247,7 @@ static int dsa_slave_phy_setup(struct net_device *slave_dev)
 		phylink_destroy(dp->pl);
 	}
 
+	genphy_config_eee_advert(slave_dev->phydev);
 	return ret;
 }
 
-- 
2.37.3