All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff
@ 2020-07-12 16:48 Vladimir Oltean
  2020-07-16 19:01 ` Jakub Kicinski
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Vladimir Oltean @ 2020-07-12 16:48 UTC (permalink / raw)
  To: davem, netdev
  Cc: linux, f.fainelli, andrew, hkallweit1, claudiu.manoil,
	alexandru.marginean, ioana.ciornei, michael

From: Vladimir Oltean <vladimir.oltean@nxp.com>

At the time of introduction, in commit bdeced75b13f ("net: dsa: felix:
Add PCS operations for PHYLINK"), support for the Lynx PCS inside Felix
was relying, for USXGMII support, on the fact that get_phy_device() is
able to parse the Lynx PCS "device-in-package" registers for this C45
MDIO device and identify it correctly.

However, this was actually working somewhat by mistake (in the sense
that, even though it was detected, it was detected for the wrong
reasons).

The get_phy_c45_ids() function works by iterating through all MMDs
starting from 1 (MDIO_MMD_PMAPMD) and stops at the first one which
returns a non-zero value in the "device-in-package" register pair,
proceeding to see what that non-zero value is.

For the Felix PCS, the first MMD (1, for the PMA/PMD) returns a non-zero
value of 0xffffffff in the "device-in-package" registers. There is a
code branch which is supposed to treat this case and flag it as wrong,
and normally, this would have caught my attention when adding initial
support for this PCS:

	if ((devs_in_pkg & 0x1fffffff) == 0x1fffffff) {
		/* If mostly Fs, there is no device there, then let's probe
		 * MMD 0, as some 10G PHYs have zero Devices In package,
		 * e.g. Cortina CS4315/CS4340 PHY.
		 */

However, this code never actually kicked in, it seems, because this
snippet from get_phy_c45_devs_in_pkg() was basically sabotaging itself,
by returning 0xfffffffe instead of 0xffffffff:

	/* Bit 0 doesn't represent a device, it indicates c22 regs presence */
	*devices_in_package &= ~BIT(0);

Then the rest of the code just carried on thinking "ok, MMD 1 (PMA/PMD)
says that there are 31 devices in that package, each having a device id
of ffff:ffff, that's perfectly fine, let's go ahead and probe this PHY
device".

But after cleanup commit 320ed3bf9000 ("net: phy: split
devices_in_package"), this got "fixed", and now devs_in_pkg is no longer
0xfffffffe, but 0xffffffff. So now, get_phy_device is returning -ENODEV
for the Lynx PCS, because the semantics have remained mostly unchanged:
the loop stops at the first MMD that returns a non-zero value, and that
is MMD 1.

But the Lynx PCS is simply a clause 37 PCS which implements the required
MAC-side functionality for USXGMII (when operated in C45 mode, which is
where C45 devices-in-package detection is relevant to). Of course it
will fail the PMD/PMA test (MMD 1), since it is not a PHY. But it does
implement detection for MDIO_MMD_PCS (3):

- MDIO_DEVS1=0x008a, MDIO_DEVS2=0x0000,
- MDIO_DEVID1=0x0083, MDIO_DEVID2=0xe400

Let get_phy_c45_ids() continue searching for valid MMDs, and don't
assume that every phy_device has a PMA/PMD MMD implemented.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/phy/phy_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index cf3505e2f587..15e5bb25103f 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -734,7 +734,8 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr,
 	/* Find first non-zero Devices In package. Device zero is reserved
 	 * for 802.3 c45 complied PHYs, so don't probe it at first.
 	 */
-	for (i = 1; i < MDIO_MMD_NUM && devs_in_pkg == 0; i++) {
+	for (i = 1; i < MDIO_MMD_NUM && devs_in_pkg == 0 &&
+	     (devs_in_pkg & 0x1fffffff) == 0x1fffffff; i++) {
 		if (i == MDIO_MMD_VEND1 || i == MDIO_MMD_VEND2) {
 			/* Check that there is a device present at this
 			 * address before reading the devices-in-package
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff
  2020-07-12 16:48 [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff Vladimir Oltean
@ 2020-07-16 19:01 ` Jakub Kicinski
  2020-07-16 20:09   ` Andrew Lunn
  2020-07-16 20:12 ` Andrew Lunn
  2020-07-17 17:23 ` David Miller
  2 siblings, 1 reply; 7+ messages in thread
From: Jakub Kicinski @ 2020-07-16 19:01 UTC (permalink / raw)
  To: linux, f.fainelli, andrew, hkallweit1
  Cc: Vladimir Oltean, davem, netdev, claudiu.manoil,
	alexandru.marginean, ioana.ciornei, michael

On Sun, 12 Jul 2020 19:48:15 +0300 Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> 
> At the time of introduction, in commit bdeced75b13f ("net: dsa: felix:
> Add PCS operations for PHYLINK"), support for the Lynx PCS inside Felix
> was relying, for USXGMII support, on the fact that get_phy_device() is
> able to parse the Lynx PCS "device-in-package" registers for this C45
> MDIO device and identify it correctly.
> [...]

PHY folks, is this part of the larger PCS discussion or something
you're happy to have applied in the current form?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff
  2020-07-16 19:01 ` Jakub Kicinski
@ 2020-07-16 20:09   ` Andrew Lunn
  0 siblings, 0 replies; 7+ messages in thread
From: Andrew Lunn @ 2020-07-16 20:09 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: linux, f.fainelli, hkallweit1, Vladimir Oltean, davem, netdev,
	claudiu.manoil, alexandru.marginean, ioana.ciornei, michael

On Thu, Jul 16, 2020 at 12:01:39PM -0700, Jakub Kicinski wrote:
> On Sun, 12 Jul 2020 19:48:15 +0300 Vladimir Oltean wrote:
> > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> > 
> > At the time of introduction, in commit bdeced75b13f ("net: dsa: felix:
> > Add PCS operations for PHYLINK"), support for the Lynx PCS inside Felix
> > was relying, for USXGMII support, on the fact that get_phy_device() is
> > able to parse the Lynx PCS "device-in-package" registers for this C45
> > MDIO device and identify it correctly.
> > [...]
> 
> PHY folks, is this part of the larger PCS discussion or something
> you're happy to have applied in the current form?

Hi Jakub

This seems fine, independent of the PCS discussions.

     Andrew

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff
  2020-07-12 16:48 [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff Vladimir Oltean
  2020-07-16 19:01 ` Jakub Kicinski
@ 2020-07-16 20:12 ` Andrew Lunn
  2020-07-16 20:51   ` Vladimir Oltean
  2020-07-17 17:23 ` David Miller
  2 siblings, 1 reply; 7+ messages in thread
From: Andrew Lunn @ 2020-07-16 20:12 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: davem, netdev, linux, f.fainelli, hkallweit1, claudiu.manoil,
	alexandru.marginean, ioana.ciornei, michael

> Then the rest of the code just carried on thinking "ok, MMD 1 (PMA/PMD)
> says that there are 31 devices in that package, each having a device id
> of ffff:ffff, that's perfectly fine, let's go ahead and probe this PHY
> device".

With a device ID of ffff:ffff, what PHY driver was getting loaded?

> - MDIO_DEVS1=0x008a, MDIO_DEVS2=0x0000,
> - MDIO_DEVID1=0x0083, MDIO_DEVID2=0xe400

Now that we have valid IDs, is the same driver getting loaded? Do this
ID adding somewhere?

> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff
  2020-07-16 20:12 ` Andrew Lunn
@ 2020-07-16 20:51   ` Vladimir Oltean
  2020-07-16 20:58     ` Vladimir Oltean
  0 siblings, 1 reply; 7+ messages in thread
From: Vladimir Oltean @ 2020-07-16 20:51 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: davem, netdev, linux, f.fainelli, hkallweit1, claudiu.manoil,
	alexandru.marginean, ioana.ciornei, michael

On Thu, Jul 16, 2020 at 10:12:10PM +0200, Andrew Lunn wrote:
> > Then the rest of the code just carried on thinking "ok, MMD 1 (PMA/PMD)
> > says that there are 31 devices in that package, each having a device id
> > of ffff:ffff, that's perfectly fine, let's go ahead and probe this PHY
> > device".
> 
> With a device ID of ffff:ffff, what PHY driver was getting loaded?
> 

You mean ffff:fffe.
No PHY driver. I am driving this PCS locally from within
drivers/net/dsa/ocelot/felix_vsc9959.c. I call get_phy_device at the
address where I know a PCS is present, for the simple reason that I like
an extra validation that my internal MDIO reads/writes are going
somewhere. I've had situations in the past where the PCS was working
because the bootloader had initialized it, however the internal MDIO
reads/writes from Linux were broken. So, the fact that get_phy_device
can read the PHY ID correctly is giving me some assurance.

> > - MDIO_DEVS1=0x008a, MDIO_DEVS2=0x0000,
> > - MDIO_DEVID1=0x0083, MDIO_DEVID2=0xe400
> 
> Now that we have valid IDs, is the same driver getting loaded? Do this
> ID adding somewhere?
> 

Not applicable, see above.

> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> 
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> 
>     Andrew

Thanks,
-Vladimir

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff
  2020-07-16 20:51   ` Vladimir Oltean
@ 2020-07-16 20:58     ` Vladimir Oltean
  0 siblings, 0 replies; 7+ messages in thread
From: Vladimir Oltean @ 2020-07-16 20:58 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: davem, netdev, linux, f.fainelli, hkallweit1, claudiu.manoil,
	alexandru.marginean, ioana.ciornei, michael

On Thu, Jul 16, 2020 at 11:51:37PM +0300, Vladimir Oltean wrote:
> On Thu, Jul 16, 2020 at 10:12:10PM +0200, Andrew Lunn wrote:
> > > Then the rest of the code just carried on thinking "ok, MMD 1 (PMA/PMD)
> > > says that there are 31 devices in that package, each having a device id
> > > of ffff:ffff, that's perfectly fine, let's go ahead and probe this PHY
> > > device".
> > 
> > With a device ID of ffff:ffff, what PHY driver was getting loaded?
> > 
> 
> You mean ffff:fffe.

Sorry, I was wrong to correct you here. ffff:fffe was the
devices-in-package register, the phy id was ffff:ffff. Doesn't change
the rest of the answer though.

> No PHY driver. I am driving this PCS locally from within
> drivers/net/dsa/ocelot/felix_vsc9959.c. I call get_phy_device at the
> address where I know a PCS is present, for the simple reason that I like
> an extra validation that my internal MDIO reads/writes are going
> somewhere. I've had situations in the past where the PCS was working
> because the bootloader had initialized it, however the internal MDIO
> reads/writes from Linux were broken. So, the fact that get_phy_device
> can read the PHY ID correctly is giving me some assurance.
> 
> > > - MDIO_DEVS1=0x008a, MDIO_DEVS2=0x0000,
> > > - MDIO_DEVID1=0x0083, MDIO_DEVID2=0xe400
> > 
> > Now that we have valid IDs, is the same driver getting loaded? Do this
> > ID adding somewhere?
> > 
> 
> Not applicable, see above.
> 
> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > 
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > 
> >     Andrew
> 
> Thanks,
> -Vladimir

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff
  2020-07-12 16:48 [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff Vladimir Oltean
  2020-07-16 19:01 ` Jakub Kicinski
  2020-07-16 20:12 ` Andrew Lunn
@ 2020-07-17 17:23 ` David Miller
  2 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2020-07-17 17:23 UTC (permalink / raw)
  To: olteanv
  Cc: netdev, linux, f.fainelli, andrew, hkallweit1, claudiu.manoil,
	alexandru.marginean, ioana.ciornei, michael

From: Vladimir Oltean <olteanv@gmail.com>
Date: Sun, 12 Jul 2020 19:48:15 +0300

> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> 
> At the time of introduction, in commit bdeced75b13f ("net: dsa: felix:
> Add PCS operations for PHYLINK"), support for the Lynx PCS inside Felix
> was relying, for USXGMII support, on the fact that get_phy_device() is
> able to parse the Lynx PCS "device-in-package" registers for this C45
> MDIO device and identify it correctly.
 ...
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Applied to net-next, thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-07-17 17:23 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-12 16:48 [PATCH net-next] net: phy: continue searching for C45 MMDs even if first returned ffff:ffff Vladimir Oltean
2020-07-16 19:01 ` Jakub Kicinski
2020-07-16 20:09   ` Andrew Lunn
2020-07-16 20:12 ` Andrew Lunn
2020-07-16 20:51   ` Vladimir Oltean
2020-07-16 20:58     ` Vladimir Oltean
2020-07-17 17:23 ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.