[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250307132422.GH3666230@kernel.org>
Date: Fri, 7 Mar 2025 13:24:22 +0000
From: Simon Horman <horms@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Andrei Botila <andrei.botila@....nxp.com>,
Paolo Abeni <pabeni@...hat.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, s32@....com,
Christophe Lizzi <clizzi@...hat.com>,
Alberto Ruiz <aruizrui@...hat.com>,
Enric Balletbo <eballetb@...hat.com>, stable@...r.kernel.org
Subject: Re: [PATCH net v2 1/2] net: phy: nxp-c45-tja11xx: add TJA112X PHY
configuration errata
On Thu, Mar 06, 2025 at 04:35:12PM +0100, Andrew Lunn wrote:
> > >> +/* Errata: ES_TJA1120 and ES_TJA1121 Rev. 1.0 — 28 November 2024 Section 3.1 */
> > >> +static void nxp_c45_tja1120_errata(struct phy_device *phydev)
> > >> +{
> > >> + int silicon_version, sample_type;
> > >> + bool macsec_ability;
> > >> + int phy_abilities;
> > >> + int ret = 0;
> > >> +
> > >> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_DEVICE_ID3);
> > >> + if (ret < 0)
> > >> + return;
> > >> +
> > >> + sample_type = FIELD_GET(TJA1120_DEV_ID3_SAMPLE_TYPE, ret);
> > >> + if (sample_type != DEVICE_ID3_SAMPLE_TYPE_R)
> > >> + return;
> > >> +
> > >> + silicon_version = FIELD_GET(TJA1120_DEV_ID3_SILICON_VERSION, ret);
> > >> +
> > >> + phy_abilities = phy_read_mmd(phydev, MDIO_MMD_VEND1,
> > >> + VEND1_PORT_ABILITIES);
> > >> + macsec_ability = !!(phy_abilities & MACSEC_ABILITY);
> > >> + if ((!macsec_ability && silicon_version == 2) ||
> > >> + (macsec_ability && silicon_version == 1)) {
> > >> + /* TJA1120/TJA1121 PHY configuration errata workaround.
> > >> + * Apply PHY writes sequence before link up.
> > >> + */
> > >> + if (!macsec_ability) {
> > >> + phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x01F8, 0x4b95);
> > >> + phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x01F9, 0xf3cd);
> > >> + } else {
> > >> + phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x01F8, 0x89c7);
> > >> + phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x01F9, 0x0893);
> > >> + }
> > >> +
> > >> + phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x0476, 0x58a0);
> > >> +
> > >> + phy_write_mmd(phydev, MDIO_MMD_PMAPMD, 0x8921, 0xa3a);
> > >> + phy_write_mmd(phydev, MDIO_MMD_PMAPMD, 0x89F1, 0x16c1);
> > >> +
> > >> + phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x01F8, 0x0);
> > >> + phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x01F9, 0x0);
> > >
> > > Please add macro with meaningful names for all the magic numbers used
> > > above, thanks!
> > >
> > > Paolo
> > >
> >
> > Hello, these registers are not documented in the datasheet or errata sheet.
> > The access sequence comes 1-to-1 from the errata so I couldn't use macros.
>
> Yes, we sometimes just have to accept the drivers are doing magic we
> have no idea about because the vendor does not want to tell is. All
> the registers in MDIO_MMD_VEND1 are clearly vendor specific. The
> MDIO_MMD_PMAPMD registers are also in the range reserved for
> vendors. So i think we just have to accept it.
+1
It can happen that vendors regard such information as IP that they do
not wish to disclose. Not saying that is the case here. Just saying
it is one reason that we sometimes have to accept such things.
So I think what you say above is completely reasonable.
> Reviewed-by: Andrew Lunn <andrew@...n.ch>
>
> Andrew
>
Powered by blists - more mailing lists