| Message ID | 20210216225454.2944373-3-robert.hancock@calian.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | b834489bceccc64641684eee5e93275cdf5f465b |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Broadcom PHY driver updates | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | success | CCed 6 of 6 maintainers |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 616 this patch: 616 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 37 lines checked |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 532 this patch: 532 |
| netdev/header_inline | success | Link |
| netdev/stable | success | Stable not CCed |
On Tue, Feb 16, 2021 at 04:54:53PM -0600, Robert Hancock wrote: > Add a flag and helper function to indicate that a PHY device is part of > an SFP module, which is set on attach. This can be used by PHY drivers > to handle SFP-specific quirks or behavior. > > Signed-off-by: Robert Hancock <robert.hancock@calian.com> > --- > drivers/net/phy/phy_device.c | 2 ++ > include/linux/phy.h | 11 +++++++++++ > 2 files changed, 13 insertions(+) > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c > index 05261698bf74..d6ac3ed38197 100644 > --- a/drivers/net/phy/phy_device.c > +++ b/drivers/net/phy/phy_device.c > @@ -1377,6 +1377,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev, > > if (phydev->sfp_bus_attached) > dev->sfp_bus = phydev->sfp_bus; > + else if (dev->sfp_bus) > + phydev->is_on_sfp_module = true; I get lost here. It this correct? We have setups with two PHY. The marvell10g PHY can play the role of media converter. It converts the signal from the MAC into signals which can be connected to an SFP cage. And then inside the cage, we can have a copper module with a second PHY. It is this second PHY which we need to indicate is_on_sfp_module true. We probably want to media convert PHYs LEDs to work, since those possible are connected to the front panel. So this needs to be specific to the SFP module PHY, and i'm not sure it is. Russell? Andrew
On Wed, Feb 17, 2021 at 04:58:26AM +0100, Andrew Lunn wrote: > On Tue, Feb 16, 2021 at 04:54:53PM -0600, Robert Hancock wrote: > > Add a flag and helper function to indicate that a PHY device is part of > > an SFP module, which is set on attach. This can be used by PHY drivers > > to handle SFP-specific quirks or behavior. > > > > Signed-off-by: Robert Hancock <robert.hancock@calian.com> > > --- > > drivers/net/phy/phy_device.c | 2 ++ > > include/linux/phy.h | 11 +++++++++++ > > 2 files changed, 13 insertions(+) > > > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c > > index 05261698bf74..d6ac3ed38197 100644 > > --- a/drivers/net/phy/phy_device.c > > +++ b/drivers/net/phy/phy_device.c > > @@ -1377,6 +1377,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev, > > > > if (phydev->sfp_bus_attached) > > dev->sfp_bus = phydev->sfp_bus; > > + else if (dev->sfp_bus) > > + phydev->is_on_sfp_module = true; > > I get lost here. It this correct? > > We have setups with two PHY. The marvell10g PHY can play the role of > media converter. It converts the signal from the MAC into signals > which can be connected to an SFP cage. > > And then inside the cage, we can have a copper module with a second > PHY. It is this second PHY which we need to indicate is_on_sfp_module > true. We don't support that setup, at least at the moment. There's no support for stacking PHYs precisely because we have the net_device structure containing a pointer to the PHY (which will be the first PHY in the chain.) That has the effect of making the second PHY inaccessible to the normal network APIs. > We probably want to media convert PHYs LEDs to work, since those > possible are connected to the front panel. So this needs to be > specific to the SFP module PHY, and i'm not sure it is. Russell? The main reason I'm hessitant with using the net_device structure to detect this is that we know that phylink has been converted to work without the net_device structure - it will be NULL. This includes attaching the "primary" PHY - phylib will be given a NULL net_device. The good news is that if a SFP cage is attempted to be attached in that situation, phylink will oops in phylink_sfp_attach(). So it isn't something that we support. However, the point is that we can end up in situations where phylib has a NULL net_device. Florian mentioned in response to one of my previous emails that he's working on sorting out the phylib dev_flags - I think we should wait for that to be resolved first, so we can allocate a dev_flag (or maybe we can do that already today?) that says "this PHY is part of a SFP module". That will give us a clearly defined positive condition that is more maintainable into the future. I'm just worrying that if we sort out phylink_sfp_*tach() (which could be trivial), if we introduce new dependencies into phylib on the network device, we're moving backwards.
On 2/17/2021 2:34 AM, Russell King - ARM Linux admin wrote: > On Wed, Feb 17, 2021 at 04:58:26AM +0100, Andrew Lunn wrote: >> On Tue, Feb 16, 2021 at 04:54:53PM -0600, Robert Hancock wrote: >>> Add a flag and helper function to indicate that a PHY device is part of >>> an SFP module, which is set on attach. This can be used by PHY drivers >>> to handle SFP-specific quirks or behavior. >>> >>> Signed-off-by: Robert Hancock <robert.hancock@calian.com> >>> --- >>> drivers/net/phy/phy_device.c | 2 ++ >>> include/linux/phy.h | 11 +++++++++++ >>> 2 files changed, 13 insertions(+) >>> >>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c >>> index 05261698bf74..d6ac3ed38197 100644 >>> --- a/drivers/net/phy/phy_device.c >>> +++ b/drivers/net/phy/phy_device.c >>> @@ -1377,6 +1377,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev, >>> >>> if (phydev->sfp_bus_attached) >>> dev->sfp_bus = phydev->sfp_bus; >>> + else if (dev->sfp_bus) >>> + phydev->is_on_sfp_module = true; >> >> I get lost here. It this correct? >> >> We have setups with two PHY. The marvell10g PHY can play the role of >> media converter. It converts the signal from the MAC into signals >> which can be connected to an SFP cage. >> >> And then inside the cage, we can have a copper module with a second >> PHY. It is this second PHY which we need to indicate is_on_sfp_module >> true. > > We don't support that setup, at least at the moment. There's no support > for stacking PHYs precisely because we have the net_device structure > containing a pointer to the PHY (which will be the first PHY in the > chain.) That has the effect of making the second PHY inaccessible to the > normal network APIs. > >> We probably want to media convert PHYs LEDs to work, since those >> possible are connected to the front panel. So this needs to be >> specific to the SFP module PHY, and i'm not sure it is. Russell? > > The main reason I'm hessitant with using the net_device structure > to detect this is that we know that phylink has been converted to > work without the net_device structure - it will be NULL. This includes > attaching the "primary" PHY - phylib will be given a NULL net_device. > > The good news is that if a SFP cage is attempted to be attached in > that situation, phylink will oops in phylink_sfp_attach(). So it > isn't something that we support. However, the point is that we can > end up in situations where phylib has a NULL net_device. > > Florian mentioned in response to one of my previous emails that he's > working on sorting out the phylib dev_flags - I think we should wait > for that to be resolved first, so we can allocate a dev_flag (or > maybe we can do that already today?) that says "this PHY is part of > a SFP module". That will give us a clearly defined positive condition > that is more maintainable into the future. We could be allocating a generic flag today starting from bit 31 and down and that would certainly be fine without necessarily making my rework any harder. The existing issues with phydev->dev_flags as I am sure you are all aware is that the flags are not name-spaced per driver yet all Ethernet MAC drivers make assumptions (tg3.c, bcmgenet.c, etc.) and it is not possible to pass arbitrary configuration settings down the PHY driver, etc. I would not hold my breath on this rework as I keep getting sucked into various issues at work. FWIW, this series appears to have already been applied.
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 05261698bf74..d6ac3ed38197 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -1377,6 +1377,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev, if (phydev->sfp_bus_attached) dev->sfp_bus = phydev->sfp_bus; + else if (dev->sfp_bus) + phydev->is_on_sfp_module = true; } /* Some Ethernet drivers try to connect to a PHY device before diff --git a/include/linux/phy.h b/include/linux/phy.h index 0d537f59b77f..1a12e4436b5b 100644 --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -492,6 +492,7 @@ struct macsec_ops; * @sysfs_links: Internal boolean tracking sysfs symbolic links setup/removal. * @loopback_enabled: Set true if this PHY has been loopbacked successfully. * @downshifted_rate: Set true if link speed has been downshifted. + * @is_on_sfp_module: Set true if PHY is located on an SFP module. * @state: State of the PHY for management purposes * @dev_flags: Device-specific flags used by the PHY driver. * @irq: IRQ number of the PHY's interrupt (-1 if none) @@ -565,6 +566,7 @@ struct phy_device { unsigned sysfs_links:1; unsigned loopback_enabled:1; unsigned downshifted_rate:1; + unsigned is_on_sfp_module:1; unsigned autoneg:1; /* The most recently read link state */ @@ -1296,6 +1298,15 @@ static inline bool phy_is_internal(struct phy_device *phydev) return phydev->is_internal; } +/** + * phy_on_sfp - Convenience function for testing if a PHY is on an SFP module + * @phydev: the phy_device struct + */ +static inline bool phy_on_sfp(struct phy_device *phydev) +{ + return phydev->is_on_sfp_module; +} + /** * phy_interface_mode_is_rgmii - Convenience function for testing if a * PHY interface mode is RGMII (all variants)
Add a flag and helper function to indicate that a PHY device is part of an SFP module, which is set on attach. This can be used by PHY drivers to handle SFP-specific quirks or behavior. Signed-off-by: Robert Hancock <robert.hancock@calian.com> --- drivers/net/phy/phy_device.c | 2 ++ include/linux/phy.h | 11 +++++++++++ 2 files changed, 13 insertions(+)