Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 30 May 2023 16:07:43 +0200
From:   Lukasz Majewski <lukma@denx.de>
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC] net: dsa: slave: Advertise correct EEE capabilities at
 slave PHY setup
Message-ID: <20230530160743.2c93a388@wsk>
In-Reply-To: <ZHXzTBOtlPKqNfLw@shell.armlinux.org.uk>
References: <20230530122621.2142192-1-lukma@denx.de>
        <ZHXzTBOtlPKqNfLw@shell.armlinux.org.uk>
Organization: denx.de
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/gukjY9rUgd.rLL7bPFTqt74";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Precedence: bulk

--Sig_/gukjY9rUgd.rLL7bPFTqt74
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Russell,

> On Tue, May 30, 2023 at 02:26:21PM +0200, Lukasz Majewski wrote:
> > One can disable in device tree advertising of EEE capabilities of
> > PHY when 'eee-broken-100tx' property is present in DTS.
> >=20
> > With DSA switch it also may happen that one would need to disable
> > EEE due to some network issues.
> >=20
> > Corresponding switch DTS description:
> >=20
> >  switch@0 {
> > 	 ports {
> > 		port@0 {
> > 		reg =3D <0>;
> > 		label =3D "lan1";
> > 		phy-handle =3D <&switchphy0>;
> > 		};
> > 	}
> > 	mdio {
> > 		switchphy0: switchphy@0 {
> > 		reg =3D <0>;
> > 		eee-broken-100tx;
> > 	};
> > 	};
> >=20
> > 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. =20
>=20
> This should be handled by phylib today in recent kernels without the
> need for any patch (as I describe below, because the config_aneg PHY
> method should be programming it.) Are you seeing a problem with it
> in 6.4-rc?

Unfortunately, for this project I use LTS 5.15.z kernel.

My impression is that the mv88e6xxx driver is not handling EEE setup
during initialization (even with v6.4-rc).

I've tried to replace genphy_config_eee_advert() with phy_init_eee, but
it lacks the part to program PCS advertise registers.

>=20
> > As a result the 'ethtool --show-eee lan1' shows that EEE is not
> > supported from the outset.
> >=20
> > Questions:
> >=20
> > - 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).
> >=20
> > - 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
> >=20
> >   It is cleared by PHY itself to 0x0 (from 0x2) and turning it on
> > again is not working.
> >=20
> >   Is this expected? Or am I missing something? =20
>=20
> No - this register is supposed to report the capabilities of the PHY,
> and bits 1..15 should be read-only, and as they report the
> capabilities they should be fixed. Writing to bit 1 of this register
> will therefore be ignored. It sounds like your PHY has some odd
> behaviour - maybe someone misinterpreted 802.3 45.2.3.9?
>=20

It is a good question. Or maybe after EEE disabling I read some wrong
data (however, up till this moment bit offsets and values seems
reasonable).

> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > ---
> >  net/dsa/slave.c | 1 +
> >  1 file changed, 1 insertion(+)
> >=20
> > 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);
> >  	}
> > =20
> > +	genphy_config_eee_advert(slave_dev->phydev); =20
>=20
> No network driver (which includes DSA) should be calling any function
> starting genphy_*. These functions are purely for phylib or phy
> drivers to use, and no one else.

As stated before, it looks like some PHY "update" in respect of EEE is
not done when DSA framework creates phydevs for slave ports.

>=20
> genphy_config_eee_advert() is a deprecated function (see commit
> 5827b168125d ("net: phy: c45: migrate to genphy_c45_write_eee_adv()")
> and thus should not be used.

Ok.

>=20
> genphy_c45_write_eee_adv() is called by
> genphy_c45_an_config_eee_aneg() which will in turn be called by
> genphy_config_aneg() for a clause 22 PHY, or by
> genphy_c45_an_config_aneg() for a clause 45 PHY. These will write the
> EEE advertisement mask to the PHY's AN MMD.
>=20

Ok.

> So, EEE should be handled by phylib according to the firmware
> settings.=20

I also would expect, that phy core code parses DTS properties and then
phydev->eee_broken_mode is used to mask EEE advertisement during PHY
initialization and startup.

> The only thing that network drivers that use phylib have to
> deal with is setting their hardware for the LPI timeout and
> enabling/disabling the timeout as necessary.
>=20

Yes. I do agree.


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

--Sig_/gukjY9rUgd.rLL7bPFTqt74
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAmR2Ay8ACgkQAR8vZIA0
zr0yNgf+MSmXQfSuHrYUlnCE2+UdHZnZS1IgUyT0DBnm7WkVggfh5/jWjgtlmkx7
glfhaJYQRXUR9OKDnagJdpPzw4yrkX1S3N+5bAkqnFWHEO7idNnY9pgd7OJXg84r
0p96obyfkIxpSjQXd1oBWFlrJ2rJjvMEougmQ9ANaZJajVmV80K1u3qgIiSDc0Va
0dB/oAmGSi6JRgcrs3EARuCPL3Gt0KRo2Z4OllbhcqDZ6+bTShYffqfnNuyhG83E
LRtpbgoLWqJsLTID4m1rfuo0hsrc06ewOuCeXdEDVO5P5Hm+f6VxrgxBpH6ymBm2
h/JuCiarOt2WxEO2UZnDawsCG20L5g==
=+NgL
-----END PGP SIGNATURE-----

--Sig_/gukjY9rUgd.rLL7bPFTqt74--