* [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver @ 2018-11-06 23:29 Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 1/3] net: phy: Add helpers to determine if PHY driver is generic Florian Fainelli ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: Florian Fainelli @ 2018-11-06 23:29 UTC (permalink / raw) To: netdev; +Cc: andrew, rmk+kernel, davem, 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH RFC net-next 1/3] net: phy: Add helpers to determine if PHY driver is generic 2018-11-06 23:29 [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver Florian Fainelli @ 2018-11-06 23:29 ` Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 2/3] net: phy: sfp: Issue warning when using Generic PHY driver(s) Florian Fainelli ` (2 subsequent siblings) 3 siblings, 0 replies; 11+ messages in thread From: Florian Fainelli @ 2018-11-06 23:29 UTC (permalink / raw) To: netdev; +Cc: andrew, rmk+kernel, davem, 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH RFC net-next 2/3] net: phy: sfp: Issue warning when using Generic PHY driver(s) 2018-11-06 23:29 [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 1/3] net: phy: Add helpers to determine if PHY driver is generic Florian Fainelli @ 2018-11-06 23:29 ` Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 3/3] net: phy: Default MARVELL_PHY to the value of SFP Florian Fainelli 2018-11-06 23:38 ` [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver David Miller 3 siblings, 0 replies; 11+ messages in thread From: Florian Fainelli @ 2018-11-06 23:29 UTC (permalink / raw) To: netdev; +Cc: andrew, rmk+kernel, davem, 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH RFC net-next 3/3] net: phy: Default MARVELL_PHY to the value of SFP 2018-11-06 23:29 [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 1/3] net: phy: Add helpers to determine if PHY driver is generic Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 2/3] net: phy: sfp: Issue warning when using Generic PHY driver(s) Florian Fainelli @ 2018-11-06 23:29 ` Florian Fainelli 2018-11-06 23:38 ` [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver David Miller 3 siblings, 0 replies; 11+ messages in thread From: Florian Fainelli @ 2018-11-06 23:29 UTC (permalink / raw) To: netdev; +Cc: andrew, rmk+kernel, davem, 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver 2018-11-06 23:29 [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver Florian Fainelli ` (2 preceding siblings ...) 2018-11-06 23:29 ` [PATCH RFC net-next 3/3] net: phy: Default MARVELL_PHY to the value of SFP Florian Fainelli @ 2018-11-06 23:38 ` David Miller 2018-11-06 23:42 ` Florian Fainelli 2018-11-07 0:03 ` Russell King - ARM Linux 3 siblings, 2 replies; 11+ messages in thread From: David Miller @ 2018-11-06 23:38 UTC (permalink / raw) To: f.fainelli; +Cc: netdev, andrew, rmk+kernel 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver 2018-11-06 23:38 ` [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver David Miller @ 2018-11-06 23:42 ` Florian Fainelli 2018-11-07 0:03 ` Russell King - ARM Linux 1 sibling, 0 replies; 11+ messages in thread From: Florian Fainelli @ 2018-11-06 23:42 UTC (permalink / raw) To: David Miller; +Cc: netdev, andrew, rmk+kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver 2018-11-06 23:38 ` [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver David Miller 2018-11-06 23:42 ` Florian Fainelli @ 2018-11-07 0:03 ` Russell King - ARM Linux 2018-11-07 0:09 ` Florian Fainelli 1 sibling, 1 reply; 11+ messages in thread From: Russell King - ARM Linux @ 2018-11-07 0:03 UTC (permalink / raw) To: David Miller; +Cc: f.fainelli, netdev, andrew 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver 2018-11-07 0:03 ` Russell King - ARM Linux @ 2018-11-07 0:09 ` Florian Fainelli 2018-11-07 0:34 ` Russell King - ARM Linux 0 siblings, 1 reply; 11+ messages in thread From: Florian Fainelli @ 2018-11-07 0:09 UTC (permalink / raw) To: Russell King - ARM Linux, David Miller; +Cc: netdev, andrew 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver 2018-11-07 0:09 ` Florian Fainelli @ 2018-11-07 0:34 ` Russell King - ARM Linux 2018-11-07 0:51 ` Florian Fainelli 0 siblings, 1 reply; 11+ messages in thread From: Russell King - ARM Linux @ 2018-11-07 0:34 UTC (permalink / raw) To: Florian Fainelli; +Cc: David Miller, netdev, andrew 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver 2018-11-07 0:34 ` Russell King - ARM Linux @ 2018-11-07 0:51 ` Florian Fainelli 2018-11-07 0:59 ` Andrew Lunn 0 siblings, 1 reply; 11+ messages in thread From: Florian Fainelli @ 2018-11-07 0:51 UTC (permalink / raw) To: Russell King - ARM Linux; +Cc: David Miller, netdev, andrew 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver 2018-11-07 0:51 ` Florian Fainelli @ 2018-11-07 0:59 ` Andrew Lunn 0 siblings, 0 replies; 11+ messages in thread From: Andrew Lunn @ 2018-11-07 0:59 UTC (permalink / raw) To: Florian Fainelli; +Cc: Russell King - ARM Linux, David Miller, netdev > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-11-07 10:27 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-06 23:29 [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 1/3] net: phy: Add helpers to determine if PHY driver is generic Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 2/3] net: phy: sfp: Issue warning when using Generic PHY driver(s) Florian Fainelli 2018-11-06 23:29 ` [PATCH RFC net-next 3/3] net: phy: Default MARVELL_PHY to the value of SFP Florian Fainelli 2018-11-06 23:38 ` [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver David Miller 2018-11-06 23:42 ` Florian Fainelli 2018-11-07 0:03 ` Russell King - ARM Linux 2018-11-07 0:09 ` Florian Fainelli 2018-11-07 0:34 ` Russell King - ARM Linux 2018-11-07 0:51 ` Florian Fainelli 2018-11-07 0:59 ` Andrew Lunn
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.