[PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[Florian Fainelli]

Hi all,

This patch series allows warning an user that the generic PHY driver(s)
are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is
likely not going to work at all.

Let me know if you would want to do that differently.

Florian Fainelli (3):
  net: phy: Add helpers to determine if PHY driver is generic
  net: phy: sfp: Issue warning when using Generic PHY driver(s)
  net: phy: Default MARVELL_PHY to the value of SFP

 drivers/net/phy/Kconfig      |  1 +
 drivers/net/phy/phy_device.c | 34 ++++++++++++++++++++++++++++++++--
 drivers/net/phy/sfp.c        |  3 +++
 include/linux/phy.h          |  3 +++
 4 files changed, 39 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH RFC net-next 1/3] net: phy: Add helpers to determine if PHY driver is generic

[Florian Fainelli]

We are already checking in phy_detach() that the PHY driver is of
generic kind (1G or 10G) and we are going to make use of that in the SFP
layer as well for 1000BaseT SFP modules, so expose helper functions to
return that information.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/phy/phy_device.c | 34 ++++++++++++++++++++++++++++++++--
 include/linux/phy.h          |  3 +++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ab33d1777132..15de7a3263bf 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1262,6 +1262,36 @@ struct phy_device *phy_attach(struct net_device *dev, const char *bus_id,
 }
 EXPORT_SYMBOL(phy_attach);
 
+static bool phy_driver_is_genphy_kind(struct phy_device *phydev,
+				      struct device_driver *driver)
+{
+	struct device *d = &phydev->mdio.dev;
+	bool ret = false;
+
+	if (!phydev->drv)
+		return ret;
+
+	get_device(d);
+	ret = d->driver == driver;
+	put_device(d);
+
+	return ret;
+}
+
+bool phy_driver_is_genphy(struct phy_device *phydev)
+{
+	return phy_driver_is_genphy_kind(phydev,
+					 &genphy_driver.mdiodrv.driver);
+}
+EXPORT_SYMBOL_GPL(phy_driver_is_genphy);
+
+bool phy_driver_is_genphy_10g(struct phy_device *phydev)
+{
+	return phy_driver_is_genphy_kind(phydev,
+					 &genphy_10g_driver.mdiodrv.driver);
+}
+EXPORT_SYMBOL_GPL(phy_driver_is_genphy_10g);
+
 /**
  * phy_detach - detach a PHY device from its network device
  * @phydev: target phy_device struct
@@ -1293,8 +1323,8 @@ void phy_detach(struct phy_device *phydev)
 	 * from the generic driver so that there's a chance a
 	 * real driver could be loaded
 	 */
-	if (phydev->mdio.dev.driver == &genphy_10g_driver.mdiodrv.driver ||
-	    phydev->mdio.dev.driver == &genphy_driver.mdiodrv.driver)
+	if (phy_driver_is_genphy(phydev) ||
+	    phy_driver_is_genphy_10g(phydev))
 		device_release_driver(&phydev->mdio.dev);
 
 	/*
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3ea87f774a76..84a6c7efef60 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1192,4 +1192,7 @@ module_exit(phy_module_exit)
 #define module_phy_driver(__phy_drivers)				\
 	phy_module_driver(__phy_drivers, ARRAY_SIZE(__phy_drivers))
 
+bool phy_driver_is_genphy(struct phy_device *phydev);
+bool phy_driver_is_genphy_10g(struct phy_device *phydev);
+
 #endif /* __PHY_H */
-- 
2.17.1

[PATCH RFC net-next 2/3] net: phy: sfp: Issue warning when using Generic PHY driver(s)

[Florian Fainelli]

1000BaseT SFP modules typically include an Ethernet PHY device, and
while the Generic PHY driver will be able to bind to it, it usually will
not work at all without a specialized PHY driver. Issue a warning in
that case to help toubleshoot things.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/phy/sfp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index fd8bb998ae52..228205d8ce84 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1203,6 +1203,9 @@ static void sfp_sm_probe_phy(struct sfp *sfp)
 	}
 
 	sfp->mod_phy = phy;
+	if (phy_driver_is_genphy(phy) || phy_driver_is_genphy_10g(phy))
+		dev_warn(sfp->dev, "Using Generic PHY driver with a SFP!\n");
+
 	phy_start(phy);
 }
 
-- 
2.17.1

[PATCH RFC net-next 3/3] net: phy: Default MARVELL_PHY to the value of SFP

[Florian Fainelli]

Marvell PHYs are typically found in 1000BaseT SFP modules, so give a
chance for users to get the correct PHY driver when using SFP modules.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/phy/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 3d187cd50eb0..cf7d44ba20c5 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -350,6 +350,7 @@ config LXT_PHY
 
 config MARVELL_PHY
 	tristate "Marvell PHYs"
+	default SFP
 	---help---
 	  Currently has a driver for the 88E1011S
 
-- 
2.17.1

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[David Miller]

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue,  6 Nov 2018 15:29:10 -0800

> This patch series allows warning an user that the generic PHY driver(s)
> are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is
> likely not going to work at all.
> 
> Let me know if you would want to do that differently.

Is there ever a possibility that the generic PHY driver could work
in an SFP situation?

If not, yes emit the message but also fail the load and registry too
perhaps?

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[Florian Fainelli]

On 11/6/18 3:38 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue,  6 Nov 2018 15:29:10 -0800
> 
>> This patch series allows warning an user that the generic PHY driver(s)
>> are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is
>> likely not going to work at all.
>>
>> Let me know if you would want to do that differently.
> 
> Is there ever a possibility that the generic PHY driver could work
> in an SFP situation?

Given the PHY has to operate in SGMII mode, I doubt it could work
without a specialized driver, Andrew, Russell, would you concur?

> 
> If not, yes emit the message but also fail the load and registry too
> perhaps?
> 

I was not sure this would be acceptable, but it is definitively an easy
change.
-- 
Florian

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[Russell King - ARM Linux]

On Tue, Nov 06, 2018 at 03:38:44PM -0800, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue,  6 Nov 2018 15:29:10 -0800
> 
> > This patch series allows warning an user that the generic PHY driver(s)
> > are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is
> > likely not going to work at all.
> > 
> > Let me know if you would want to do that differently.
> 
> Is there ever a possibility that the generic PHY driver could work
> in an SFP situation?

I don't yet see the reason for Florian's patch series - all the Marvell
88e1111 based modules I have, or have come across in information from
manufacturers self-configure themselves and don't really need the
Marvell 1G PHY driver.

For example, the Source Photonics were offering a range of 1GbaseT
modules with the 88e1111 programmed in different modes, but published
instructions for the register accesses to configure them differently
(eg, SGMII vs 1000base-X interface facing the MAC).  Depending on
the module part number determines which mode the PHY has been
programmed to come up in.

So in theory, you don't need any PHY driver for these modules - but
it's useful to have a functional PHY driver to be able to read out
the negotiated flow control results.

I'd like more information from Florian about the reasoning behind
this patch series before it's merged.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[Florian Fainelli]

On 11/6/18 4:03 PM, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2018 at 03:38:44PM -0800, David Miller wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>> Date: Tue,  6 Nov 2018 15:29:10 -0800
>>
>>> This patch series allows warning an user that the generic PHY driver(s)
>>> are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is
>>> likely not going to work at all.
>>>
>>> Let me know if you would want to do that differently.
>>
>> Is there ever a possibility that the generic PHY driver could work
>> in an SFP situation?
> 
> I don't yet see the reason for Florian's patch series - all the Marvell
> 88e1111 based modules I have, or have come across in information from
> manufacturers self-configure themselves and don't really need the
> Marvell 1G PHY driver.
> 
> For example, the Source Photonics were offering a range of 1GbaseT
> modules with the 88e1111 programmed in different modes, but published
> instructions for the register accesses to configure them differently
> (eg, SGMII vs 1000base-X interface facing the MAC).  Depending on
> the module part number determines which mode the PHY has been
> programmed to come up in.
> 
> So in theory, you don't need any PHY driver for these modules - but
> it's useful to have a functional PHY driver to be able to read out
> the negotiated flow control results.
> 
> I'd like more information from Florian about the reasoning behind
> this patch series before it's merged.
> 

The module that I am using [1] would not work, as in , no link up being
reported without turning on the Marvell PHY driver:

https://www.amazon.com/dp/B01LW2P72V/ref=twister_B07F3WQJQX?_encoding=UTF8&psc=1

this module uses a 88E1111 PHY as well (OUI: 0x01410cc2).
-- 
Florian

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[Russell King - ARM Linux]

On Tue, Nov 06, 2018 at 04:09:35PM -0800, Florian Fainelli wrote:
> On 11/6/18 4:03 PM, Russell King - ARM Linux wrote:
> > On Tue, Nov 06, 2018 at 03:38:44PM -0800, David Miller wrote:
> >> From: Florian Fainelli <f.fainelli@gmail.com>
> >> Date: Tue,  6 Nov 2018 15:29:10 -0800
> >>
> >>> This patch series allows warning an user that the generic PHY driver(s)
> >>> are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is
> >>> likely not going to work at all.
> >>>
> >>> Let me know if you would want to do that differently.
> >>
> >> Is there ever a possibility that the generic PHY driver could work
> >> in an SFP situation?
> > 
> > I don't yet see the reason for Florian's patch series - all the Marvell
> > 88e1111 based modules I have, or have come across in information from
> > manufacturers self-configure themselves and don't really need the
> > Marvell 1G PHY driver.
> > 
> > For example, the Source Photonics were offering a range of 1GbaseT
> > modules with the 88e1111 programmed in different modes, but published
> > instructions for the register accesses to configure them differently
> > (eg, SGMII vs 1000base-X interface facing the MAC).  Depending on
> > the module part number determines which mode the PHY has been
> > programmed to come up in.
> > 
> > So in theory, you don't need any PHY driver for these modules - but
> > it's useful to have a functional PHY driver to be able to read out
> > the negotiated flow control results.
> > 
> > I'd like more information from Florian about the reasoning behind
> > this patch series before it's merged.
> > 
> 
> The module that I am using [1] would not work, as in , no link up being
> reported without turning on the Marvell PHY driver:
> 
> https://www.amazon.com/dp/B01LW2P72V/ref=twister_B07F3WQJQX?_encoding=UTF8&psc=1
> 
> this module uses a 88E1111 PHY as well (OUI: 0x01410cc2).

>From the above URL:

     * This is 1000M SFP-T Transceiver, not 10/100/1000M Multi-Rate SFP-T. If
       you want to buy 10/100/1000M Multi-Rate SFP-T, pls contact us.10Gtek
       offer more compatible options, if your brands not listed above, pls
       contact us.

I wonder if this is like the Source Photonics situation, where the
1000base-T only variant of their module uses 1000base-X on the MAC
side, whereas their 10/100/1000base-T variant uses SGMII.  The only
difference between these are the part numbers and the programming
of the 88E1111 to tell it which mode to default to for the host
side.  (There's no true way to know from the EEPROM whether a module
wants SGMII or 1000base-X.)

What I also gather is that this is a 10Gtek-manufactured version of
the Ubiquiti UF-RJ45-1G - the original Ubiquiti version supports
10/100/1G speeds which would require the 88e1111 to configure for
a SGMII host interface by default.

Now, the reason that modules with an 88E1111 configured to default to
1000base-X will work when the marvell PHY driver is present, but not
with the generic driver is that the marvell PHY driver will see that
SFP/phylink is wanting to use SGMII mode, and the Marvell PHY driver
reprograms the PHY to use SGMII.  This is only a problem for these
modules.

So, in so far as your patch 3 goes to give a hint that the Marvell
driver should be selected, that's correct.

However, where the 88e1111 is configured for SGMII by default, the
Marvell driver shouldn't be required, and I wonder whether we ought
to be issuing a warning in that case.  The problem, however, is there
is no way to know for certain.

We could have modules that do not use the Marvell PHY, and if we don't
have a PHY driver for their particular PHY, do we want a warning to be
issued?

The whole 1000base-X vs SGMII with SFP modules is all very icky. :(

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[Florian Fainelli]

On 11/6/18 4:34 PM, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2018 at 04:09:35PM -0800, Florian Fainelli wrote:
>> On 11/6/18 4:03 PM, Russell King - ARM Linux wrote:
>>> On Tue, Nov 06, 2018 at 03:38:44PM -0800, David Miller wrote:
>>>> From: Florian Fainelli <f.fainelli@gmail.com>
>>>> Date: Tue,  6 Nov 2018 15:29:10 -0800
>>>>
>>>>> This patch series allows warning an user that the generic PHY driver(s)
>>>>> are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is
>>>>> likely not going to work at all.
>>>>>
>>>>> Let me know if you would want to do that differently.
>>>>
>>>> Is there ever a possibility that the generic PHY driver could work
>>>> in an SFP situation?
>>>
>>> I don't yet see the reason for Florian's patch series - all the Marvell
>>> 88e1111 based modules I have, or have come across in information from
>>> manufacturers self-configure themselves and don't really need the
>>> Marvell 1G PHY driver.
>>>
>>> For example, the Source Photonics were offering a range of 1GbaseT
>>> modules with the 88e1111 programmed in different modes, but published
>>> instructions for the register accesses to configure them differently
>>> (eg, SGMII vs 1000base-X interface facing the MAC).  Depending on
>>> the module part number determines which mode the PHY has been
>>> programmed to come up in.
>>>
>>> So in theory, you don't need any PHY driver for these modules - but
>>> it's useful to have a functional PHY driver to be able to read out
>>> the negotiated flow control results.
>>>
>>> I'd like more information from Florian about the reasoning behind
>>> this patch series before it's merged.
>>>
>>
>> The module that I am using [1] would not work, as in , no link up being
>> reported without turning on the Marvell PHY driver:
>>
>> https://www.amazon.com/dp/B01LW2P72V/ref=twister_B07F3WQJQX?_encoding=UTF8&psc=1
>>
>> this module uses a 88E1111 PHY as well (OUI: 0x01410cc2).
> 
> From the above URL:
> 
>      * This is 1000M SFP-T Transceiver, not 10/100/1000M Multi-Rate SFP-T. If
>        you want to buy 10/100/1000M Multi-Rate SFP-T, pls contact us.10Gtek
>        offer more compatible options, if your brands not listed above, pls
>        contact us.
> 
> I wonder if this is like the Source Photonics situation, where the
> 1000base-T only variant of their module uses 1000base-X on the MAC
> side, whereas their 10/100/1000base-T variant uses SGMII.  The only
> difference between these are the part numbers and the programming
> of the 88E1111 to tell it which mode to default to for the host
> side.  (There's no true way to know from the EEPROM whether a module
> wants SGMII or 1000base-X.)
> 
> What I also gather is that this is a 10Gtek-manufactured version of
> the Ubiquiti UF-RJ45-1G - the original Ubiquiti version supports
> 10/100/1G speeds which would require the 88e1111 to configure for
> a SGMII host interface by default.
> 
> Now, the reason that modules with an 88E1111 configured to default to
> 1000base-X will work when the marvell PHY driver is present, but not
> with the generic driver is that the marvell PHY driver will see that
> SFP/phylink is wanting to use SGMII mode, and the Marvell PHY driver
> reprograms the PHY to use SGMII.  This is only a problem for these
> modules.
> 
> So, in so far as your patch 3 goes to give a hint that the Marvell
> driver should be selected, that's correct.
> 
> However, where the 88e1111 is configured for SGMII by default, the
> Marvell driver shouldn't be required, and I wonder whether we ought
> to be issuing a warning in that case.  The problem, however, is there
> is no way to know for certain.
> 
> We could have modules that do not use the Marvell PHY, and if we don't
> have a PHY driver for their particular PHY, do we want a warning to be
> issued?

Another approach could be to maintain a list of modules that do not work
with the generic PHY driver and therefore require a specialized driver,
in that case we could even go as far as not letting sfp_sm_probe_phy()
return success. Not sure how well things would scale, probably not too
bad given there are only a handful of users of the SFP framework thus far...

> 
> The whole 1000base-X vs SGMII with SFP modules is all very icky. :(
> 
-- 
Florian

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

[Andrew Lunn]

> Another approach could be to maintain a list of modules that do not work
> with the generic PHY driver and therefore require a specialized driver,
> in that case we could even go as far as not letting sfp_sm_probe_phy()
> return success. Not sure how well things would scale, probably not too
> bad given there are only a handful of users of the SFP framework thus far...

Hi Florian

Blacklisting modules with known issues with the generic driver does
not sound too bad. This is just a warning, a helpful hint, and it is
not going to work anyway. And i don't see scaling problems, Copper
SFPs seems quite odd to start with...

    Andrew