| Message ID | 20210325131250.15901-1-kabel@kernel.org |
|---|---|
| Headers | show |
| Series | net: phy: marvell10g updates | expand |
On Thu, 25 Mar 2021 14:12:49 +0100
Marek Behún <kabel@kernel.org> wrote:
> Print exact mode, one of
typo: model
On Thu, Mar 25, 2021 at 02:12:49PM +0100, Marek Behún wrote: > @@ -443,12 +446,24 @@ static int mv3310_probe(struct phy_device *phydev) > > switch (phydev->drv->phy_id) { > case MARVELL_PHY_ID_88X3310: > + ret = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MV_PMA_XGSTAT); > + if (ret < 0) > + return ret; > + > + has_macsec = !(ret & MV_PMA_XGSTAT_NO_MACSEC); > + > if (nports == 4) > priv->model = MV_MODEL_88X3340; > else if (nports == 1) > priv->model = MV_MODEL_88X3310; > break; The 88X3310 and 88X3340 can be differentiated by bit 3 in the revision. In other words, 88X3310 is 0x09a0..0x09a7, and 88X3340 is 0x09a8..0x09af. We could add a separate driver structure, which would then allow the kernel to print a more specific string via standard methods, like we do for other PHYs. Not sure whether that would work for the 88X21x0 family though.
On 25.03.2021 21:29, Marek Behún wrote: > On Thu, 25 Mar 2021 15:54:52 +0000 > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > >> The 88X3310 and 88X3340 can be differentiated by bit 3 in the revision. >> In other words, 88X3310 is 0x09a0..0x09a7, and 88X3340 is >> 0x09a8..0x09af. We could add a separate driver structure, which would >> then allow the kernel to print a more specific string via standard >> methods, like we do for other PHYs. Not sure whether that would work >> for the 88X21x0 family though. > > According to release notes it seems that we can also differentiate > 88E211X from 88E218X (via bit 3 in register 1.3): > 88E211X has 0x09B9 > 88E218X has 0x09B1 > > but not 88E2110 from 88E2111 > nor 88E2180 from 88E2181. > > These can be differentiated via register > 3.0004.7 > (bit 7 of MDIO_MMD_PCS.MDIO_SPEED., which says whether device is capable > of 5g speed) > If the PHY ID's are the same but you can use this register to differentiate the two versions, then you could implement the match_phy_device callback. This would allow you to have separate PHY drivers. This is just meant to say you have this option, I don't know the context good enough to state whether it's the better one. > I propose creating separate structures for mv88x3340 and mv88e218x. > We can then print the remaining info as > "(not) macsec/ptp capable" > or > "(not) 5g capable" > > What do you think? > > Marek >
On Thu, Mar 25, 2021 at 09:54:14PM +0100, Marek Behún wrote: > On Thu, 25 Mar 2021 21:44:21 +0100 > Heiner Kallweit <hkallweit1@gmail.com> wrote: > > > On 25.03.2021 21:29, Marek Behún wrote: > > > On Thu, 25 Mar 2021 15:54:52 +0000 > > > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > > > >> The 88X3310 and 88X3340 can be differentiated by bit 3 in the revision. > > >> In other words, 88X3310 is 0x09a0..0x09a7, and 88X3340 is > > >> 0x09a8..0x09af. We could add a separate driver structure, which would > > >> then allow the kernel to print a more specific string via standard > > >> methods, like we do for other PHYs. Not sure whether that would work > > >> for the 88X21x0 family though. > > > > > > According to release notes it seems that we can also differentiate > > > 88E211X from 88E218X (via bit 3 in register 1.3): > > > 88E211X has 0x09B9 > > > 88E218X has 0x09B1 > > > > > > but not 88E2110 from 88E2111 > > > nor 88E2180 from 88E2181. > > > > > > These can be differentiated via register > > > 3.0004.7 > > > (bit 7 of MDIO_MMD_PCS.MDIO_SPEED., which says whether device is capable > > > of 5g speed) > > > > > > > If the PHY ID's are the same but you can use this register to > > differentiate the two versions, then you could implement the > > match_phy_device callback. This would allow you to have separate > > PHY drivers. This is just meant to say you have this option, I don't > > know the context good enough to state whether it's the better one. > > Nice, didn't know about that. But I fear whether this would always work > for the 88X3310 vs 88X3310P, it is possible that this feature is only > recognizable if the firmware in the PHY is already running. The ID registers aren't programmable and contain the proper IDs even if there isn't firmware loaded (I've had such a PHY here.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, 26 Mar 2021 09:07:34 +0000 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > Nice, didn't know about that. But I fear whether this would always work > > for the 88X3310 vs 88X3310P, it is possible that this feature is only > > recognizable if the firmware in the PHY is already running. > > The ID registers aren't programmable and contain the proper IDs even if > there isn't firmware loaded (I've had such a PHY here.) > Yes, but the macsec feature bit is in register MDIO_MMD_PMAPMD.MV_PMA_XGSTAT.12 (1.c001.12) But it says "This bit is valid upon completion of reset (1.0.15 = 0)", so it seems we can use this. :) Marek