Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
On Mon, Mar 19, 2018 at 01:19:24PM +, Stefan Chulski wrote: > > > > -Original Message- > > From: Andrew Lunn [mailto:and...@lunn.ch] > > Sent: Monday, March 19, 2018 3:08 PM > > To: Stefan Chulski <stef...@marvell.com> > > Cc: Antoine Tenart <antoine.ten...@bootlin.com>; Russell King - ARM Linux > > <li...@armlinux.org.uk>; da...@davemloft.net; kis...@ti.com; > > gregory.clem...@bootlin.com; ja...@lakedaemon.net; > > sebastian.hesselba...@gmail.com; net...@vger.kernel.org; linux- > > ker...@vger.kernel.org; thomas.petazz...@bootlin.com; > > maxime.chevall...@bootlin.com; miquel.ray...@bootlin.com; Nadav Haklai > > <nad...@marvell.com>; Yan Markman <ymark...@marvell.com>; > > m...@semihalf.com; linux-arm-ker...@lists.infradead.org > > Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > > interface to use in-band negotiation > > > > > > If they don't have PHYs, how are the connected to the outside world? > > > > > > > >Andrew > > > > > > By external SFP or direct attached cable. > > > > Maybe i'm missing something, but don't you just need to add an SFP device > > in the device tree. The SFP code and PHYLINK will work together, query what > > the SFP module is, use the GPIOs to determine link up/down and module > > present, and tell the MAC how to configure the MAC-SFP link? > > > > Andrew > > phylink pool SFP loss signal to determine link up/down? No. Phylink was merged along with SFP cage support, which includes a DT description for SFP cages, including the various signals for the cage. The SFP layer will take care of monitoring the cage and conveying state information to Phylink. Phylink's job is to work out how any SFP module, PHY and MAC should be configured and to determine the link state based on information supplied by or requested from each depending on the configured state. Please do not try and support SFP cages as fixed links. They aren't, and such an approach will always have sub-standard link state monitoring. In an optical setup, the SFP LOS signal just indicates whether there is sufficient optical power present at the receiver. It doesn't indicate whether there is a valid signal there, or whether the chip at the other end of the serdes link can decode the signal. That has to come from the upstream chip, whether it be a PHY or a MAC. SFP optical modules do not perform protocol validation - they merely convert the serdes electrical signal into a light signal and back again, with varying amounts of monitoring on board. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
On Mon, Mar 19, 2018 at 01:19:24PM +, Stefan Chulski wrote: > > > > -Original Message- > > From: Andrew Lunn [mailto:and...@lunn.ch] > > Sent: Monday, March 19, 2018 3:08 PM > > To: Stefan Chulski > > Cc: Antoine Tenart ; Russell King - ARM Linux > > ; da...@davemloft.net; kis...@ti.com; > > gregory.clem...@bootlin.com; ja...@lakedaemon.net; > > sebastian.hesselba...@gmail.com; net...@vger.kernel.org; linux- > > ker...@vger.kernel.org; thomas.petazz...@bootlin.com; > > maxime.chevall...@bootlin.com; miquel.ray...@bootlin.com; Nadav Haklai > > ; Yan Markman ; > > m...@semihalf.com; linux-arm-ker...@lists.infradead.org > > Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > > interface to use in-band negotiation > > > > > > If they don't have PHYs, how are the connected to the outside world? > > > > > > > >Andrew > > > > > > By external SFP or direct attached cable. > > > > Maybe i'm missing something, but don't you just need to add an SFP device > > in the device tree. The SFP code and PHYLINK will work together, query what > > the SFP module is, use the GPIOs to determine link up/down and module > > present, and tell the MAC how to configure the MAC-SFP link? > > > > Andrew > > phylink pool SFP loss signal to determine link up/down? No. Phylink was merged along with SFP cage support, which includes a DT description for SFP cages, including the various signals for the cage. The SFP layer will take care of monitoring the cage and conveying state information to Phylink. Phylink's job is to work out how any SFP module, PHY and MAC should be configured and to determine the link state based on information supplied by or requested from each depending on the configured state. Please do not try and support SFP cages as fixed links. They aren't, and such an approach will always have sub-standard link state monitoring. In an optical setup, the SFP LOS signal just indicates whether there is sufficient optical power present at the receiver. It doesn't indicate whether there is a valid signal there, or whether the chip at the other end of the serdes link can decode the signal. That has to come from the upstream chip, whether it be a PHY or a MAC. SFP optical modules do not perform protocol validation - they merely convert the serdes electrical signal into a light signal and back again, with varying amounts of monitoring on board. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> This would definitively work for SFP connectors with a PHY, but would > that work when using direct attached cable? Then you need to know what is on the other end of the cable? A switch? A PHY? and SFP module? Andrew
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> This would definitively work for SFP connectors with a PHY, but would > that work when using direct attached cable? Then you need to know what is on the other end of the cable? A switch? A PHY? and SFP module? Andrew
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> phylink pool SFP loss signal to determine link up/down? Yes, the SFP driver will act on a GPIO for link up/down, and a GPIO for module prescience. When it detects an SFP module hotplugged, it reads the EEPROM to find out what sort of module it is, and what mode should be used between the MAC and SFP module. It will also handle if the SFP module is copper, and has a PHY in it... Andrew
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> phylink pool SFP loss signal to determine link up/down? Yes, the SFP driver will act on a GPIO for link up/down, and a GPIO for module prescience. When it detects an SFP module hotplugged, it reads the EEPROM to find out what sort of module it is, and what mode should be used between the MAC and SFP module. It will also handle if the SFP module is copper, and has a PHY in it... Andrew
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, March 19, 2018 3:08 PM > To: Stefan Chulski <stef...@marvell.com> > Cc: Antoine Tenart <antoine.ten...@bootlin.com>; Russell King - ARM Linux > <li...@armlinux.org.uk>; da...@davemloft.net; kis...@ti.com; > gregory.clem...@bootlin.com; ja...@lakedaemon.net; > sebastian.hesselba...@gmail.com; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; thomas.petazz...@bootlin.com; > maxime.chevall...@bootlin.com; miquel.ray...@bootlin.com; Nadav Haklai > <nad...@marvell.com>; Yan Markman <ymark...@marvell.com>; > m...@semihalf.com; linux-arm-ker...@lists.infradead.org > Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > interface to use in-band negotiation > > > > If they don't have PHYs, how are the connected to the outside world? > > > > > >Andrew > > > > By external SFP or direct attached cable. > > Maybe i'm missing something, but don't you just need to add an SFP device > in the device tree. The SFP code and PHYLINK will work together, query what > the SFP module is, use the GPIOs to determine link up/down and module > present, and tell the MAC how to configure the MAC-SFP link? > > Andrew phylink pool SFP loss signal to determine link up/down? Stefan, Best Regards.
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, March 19, 2018 3:08 PM > To: Stefan Chulski > Cc: Antoine Tenart ; Russell King - ARM Linux > ; da...@davemloft.net; kis...@ti.com; > gregory.clem...@bootlin.com; ja...@lakedaemon.net; > sebastian.hesselba...@gmail.com; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; thomas.petazz...@bootlin.com; > maxime.chevall...@bootlin.com; miquel.ray...@bootlin.com; Nadav Haklai > ; Yan Markman ; > m...@semihalf.com; linux-arm-ker...@lists.infradead.org > Subject: Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > interface to use in-band negotiation > > > > If they don't have PHYs, how are the connected to the outside world? > > > > > >Andrew > > > > By external SFP or direct attached cable. > > Maybe i'm missing something, but don't you just need to add an SFP device > in the device tree. The SFP code and PHYLINK will work together, query what > the SFP module is, use the GPIOs to determine link up/down and module > present, and tell the MAC how to configure the MAC-SFP link? > > Andrew phylink pool SFP loss signal to determine link up/down? Stefan, Best Regards.
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
On Mon, Mar 19, 2018 at 02:08:23PM +0100, Andrew Lunn wrote: > > > If they don't have PHYs, how are the connected to the outside world? > > > > By external SFP or direct attached cable. > > Maybe i'm missing something, but don't you just need to add an SFP > device in the device tree. The SFP code and PHYLINK will work > together, query what the SFP module is, use the GPIOs to determine > link up/down and module present, and tell the MAC how to configure the > MAC-SFP link? This would definitively work for SFP connectors with a PHY, but would that work when using direct attached cable? As in the second case phylink wouldn't be able to ask the SFP PHY for the link state. Antoine -- Antoine Ténart, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
On Mon, Mar 19, 2018 at 02:08:23PM +0100, Andrew Lunn wrote: > > > If they don't have PHYs, how are the connected to the outside world? > > > > By external SFP or direct attached cable. > > Maybe i'm missing something, but don't you just need to add an SFP > device in the device tree. The SFP code and PHYLINK will work > together, query what the SFP module is, use the GPIOs to determine > link up/down and module present, and tell the MAC how to configure the > MAC-SFP link? This would definitively work for SFP connectors with a PHY, but would that work when using direct attached cable? As in the second case phylink wouldn't be able to ask the SFP PHY for the link state. Antoine -- Antoine Ténart, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> > If they don't have PHYs, how are the connected to the outside world? > > > >Andrew > > By external SFP or direct attached cable. Maybe i'm missing something, but don't you just need to add an SFP device in the device tree. The SFP code and PHYLINK will work together, query what the SFP module is, use the GPIOs to determine link up/down and module present, and tell the MAC how to configure the MAC-SFP link? Andrew
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> > If they don't have PHYs, how are the connected to the outside world? > > > >Andrew > > By external SFP or direct attached cable. Maybe i'm missing something, but don't you just need to add an SFP device in the device tree. The SFP code and PHYLINK will work together, query what the SFP module is, use the GPIOs to determine link up/down and module present, and tell the MAC how to configure the MAC-SFP link? Andrew
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
On Mon, Mar 19, 2018 at 01:01:07PM +, Yan Markman wrote: > The DTS-patch for this board (in "old" format) is attached > > > Yan Markman > Tel. 05-44732819 > > > -Original Message- > From: Stefan Chulski > Sent: Monday, March 19, 2018 2:58 PM > To: Russell King - ARM Linux <li...@armlinux.org.uk>; Antoine Tenart > <antoine.ten...@bootlin.com> > Cc: da...@davemloft.net; kis...@ti.com; gregory.clem...@bootlin.com; > and...@lunn.ch; ja...@lakedaemon.net; sebastian.hesselba...@gmail.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; > thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com; > miquel.ray...@bootlin.com; Nadav Haklai <nad...@marvell.com>; Yan Markman > <ymark...@marvell.com>; m...@semihalf.com; > linux-arm-ker...@lists.infradead.org > Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > interface to use in-band negotiation > > > > > There is no inband negotiation like there is with 802.3z or SGMII, > > > > so this makes no sense. > > > > > > Oh, that's what I feared. I read some docs but probably will need > > > more > > > :) > > > > > > Anyway, the reason to use in-band negotiation was also to avoid > > > using fixed-link. It would work but always report the link is up, > > > which for the user isn't a great experience as we have a way to detect > > > this. > > > > > > What would you suggest to achieve this in a reasonable way? > > > > The intention of this test in phylink_of_phy_connect() is to avoid > > failing when there is no requirement for a PHY to be present (such as > > a fixed link, or an 802.3z link.) However, with 10G PHYs such as the > > 3310, we need the PHY so we can read the speed from it, and so know > > whether to downgrade the MAC to SGMII mode, or having downgraded the > > MAC, upgrade it back to 10G mode when the PHY switches to 10G. > > > > I'm guessing that you're wanting this for the DB boards, but I don't see > > why. > > Do they not have PHYs? > > New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, > like DB boards. > https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/ Correct, but this DTS is wrong. It connects to a SFP cage, and as SFP cages are supported in mainline now, there's no need to mess around with fixed links or similar. I haven't tested phylink in that configuration yet as SolidRun haven't sent me a SingleShot board yet - and I need any board I do get to have the pull-up resistors on the I2C lines of the correct value, because I'm not risking corruption of the EEPROMs in my SFP* modules. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
On Mon, Mar 19, 2018 at 01:01:07PM +, Yan Markman wrote: > The DTS-patch for this board (in "old" format) is attached > > > Yan Markman > Tel. 05-44732819 > > > -Original Message- > From: Stefan Chulski > Sent: Monday, March 19, 2018 2:58 PM > To: Russell King - ARM Linux ; Antoine Tenart > > Cc: da...@davemloft.net; kis...@ti.com; gregory.clem...@bootlin.com; > and...@lunn.ch; ja...@lakedaemon.net; sebastian.hesselba...@gmail.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; > thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com; > miquel.ray...@bootlin.com; Nadav Haklai ; Yan Markman > ; m...@semihalf.com; > linux-arm-ker...@lists.infradead.org > Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > interface to use in-band negotiation > > > > > There is no inband negotiation like there is with 802.3z or SGMII, > > > > so this makes no sense. > > > > > > Oh, that's what I feared. I read some docs but probably will need > > > more > > > :) > > > > > > Anyway, the reason to use in-band negotiation was also to avoid > > > using fixed-link. It would work but always report the link is up, > > > which for the user isn't a great experience as we have a way to detect > > > this. > > > > > > What would you suggest to achieve this in a reasonable way? > > > > The intention of this test in phylink_of_phy_connect() is to avoid > > failing when there is no requirement for a PHY to be present (such as > > a fixed link, or an 802.3z link.) However, with 10G PHYs such as the > > 3310, we need the PHY so we can read the speed from it, and so know > > whether to downgrade the MAC to SGMII mode, or having downgraded the > > MAC, upgrade it back to 10G mode when the PHY switches to 10G. > > > > I'm guessing that you're wanting this for the DB boards, but I don't see > > why. > > Do they not have PHYs? > > New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, > like DB boards. > https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/ Correct, but this DTS is wrong. It connects to a SFP cage, and as SFP cages are supported in mainline now, there's no need to mess around with fixed links or similar. I haven't tested phylink in that configuration yet as SolidRun haven't sent me a SingleShot board yet - and I need any board I do get to have the pull-up resistors on the I2C lines of the correct value, because I'm not risking corruption of the EEPROMs in my SFP* modules. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, March 19, 2018 3:00 PM > To: Antoine Tenart <antoine.ten...@bootlin.com> > Cc: Russell King - ARM Linux <li...@armlinux.org.uk>; > da...@davemloft.net; kis...@ti.com; gregory.clem...@bootlin.com; > ja...@lakedaemon.net; sebastian.hesselba...@gmail.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; > thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com; > miquel.ray...@bootlin.com; Nadav Haklai <nad...@marvell.com>; Stefan > Chulski <stef...@marvell.com>; Yan Markman <ymark...@marvell.com>; > m...@semihalf.com; linux-arm-ker...@lists.infradead.org > Subject: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > interface to use in-band negotiation > > External Email > > -- > Hi Antoine > > > You guessed right, that's exactly my use case. The DB boards (7k and > > 8k) have 10G interfaces without PHYs. > > If they don't have PHYs, how are the connected to the outside world? > >Andrew By external SFP or direct attached cable. Stefan.
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, March 19, 2018 3:00 PM > To: Antoine Tenart > Cc: Russell King - ARM Linux ; > da...@davemloft.net; kis...@ti.com; gregory.clem...@bootlin.com; > ja...@lakedaemon.net; sebastian.hesselba...@gmail.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; > thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com; > miquel.ray...@bootlin.com; Nadav Haklai ; Stefan > Chulski ; Yan Markman ; > m...@semihalf.com; linux-arm-ker...@lists.infradead.org > Subject: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR > interface to use in-band negotiation > > External Email > > -- > Hi Antoine > > > You guessed right, that's exactly my use case. The DB boards (7k and > > 8k) have 10G interfaces without PHYs. > > If they don't have PHYs, how are the connected to the outside world? > >Andrew By external SFP or direct attached cable. Stefan.
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
The DTS-patch for this board (in "old" format) is attached Yan Markman Tel. 05-44732819 -Original Message- From: Stefan Chulski Sent: Monday, March 19, 2018 2:58 PM To: Russell King - ARM Linux <li...@armlinux.org.uk>; Antoine Tenart <antoine.ten...@bootlin.com> Cc: da...@davemloft.net; kis...@ti.com; gregory.clem...@bootlin.com; and...@lunn.ch; ja...@lakedaemon.net; sebastian.hesselba...@gmail.com; net...@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com; miquel.ray...@bootlin.com; Nadav Haklai <nad...@marvell.com>; Yan Markman <ymark...@marvell.com>; m...@semihalf.com; linux-arm-ker...@lists.infradead.org Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation > > > There is no inband negotiation like there is with 802.3z or SGMII, > > > so this makes no sense. > > > > Oh, that's what I feared. I read some docs but probably will need > > more > > :) > > > > Anyway, the reason to use in-band negotiation was also to avoid > > using fixed-link. It would work but always report the link is up, > > which for the user isn't a great experience as we have a way to detect this. > > > > What would you suggest to achieve this in a reasonable way? > > The intention of this test in phylink_of_phy_connect() is to avoid > failing when there is no requirement for a PHY to be present (such as > a fixed link, or an 802.3z link.) However, with 10G PHYs such as the > 3310, we need the PHY so we can read the speed from it, and so know > whether to downgrade the MAC to SGMII mode, or having downgraded the > MAC, upgrade it back to 10G mode when the PHY switches to 10G. > > I'm guessing that you're wanting this for the DB boards, but I don't see why. > Do they not have PHYs? New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, like DB boards. https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/ Stefan, Best Regards. 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch Description: 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
The DTS-patch for this board (in "old" format) is attached Yan Markman Tel. 05-44732819 -Original Message- From: Stefan Chulski Sent: Monday, March 19, 2018 2:58 PM To: Russell King - ARM Linux ; Antoine Tenart Cc: da...@davemloft.net; kis...@ti.com; gregory.clem...@bootlin.com; and...@lunn.ch; ja...@lakedaemon.net; sebastian.hesselba...@gmail.com; net...@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com; miquel.ray...@bootlin.com; Nadav Haklai ; Yan Markman ; m...@semihalf.com; linux-arm-ker...@lists.infradead.org Subject: RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation > > > There is no inband negotiation like there is with 802.3z or SGMII, > > > so this makes no sense. > > > > Oh, that's what I feared. I read some docs but probably will need > > more > > :) > > > > Anyway, the reason to use in-band negotiation was also to avoid > > using fixed-link. It would work but always report the link is up, > > which for the user isn't a great experience as we have a way to detect this. > > > > What would you suggest to achieve this in a reasonable way? > > The intention of this test in phylink_of_phy_connect() is to avoid > failing when there is no requirement for a PHY to be present (such as > a fixed link, or an 802.3z link.) However, with 10G PHYs such as the > 3310, we need the PHY so we can read the speed from it, and so know > whether to downgrade the MAC to SGMII mode, or having downgraded the > MAC, upgrade it back to 10G mode when the PHY switches to 10G. > > I'm guessing that you're wanting this for the DB boards, but I don't see why. > Do they not have PHYs? New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, like DB boards. https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/ Stefan, Best Regards. 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch Description: 0001-arm64-dts-marvell-add-new-mcbin-single-shot-board.patch
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> > > There is no inband negotiation like there is with 802.3z or SGMII, > > > so this makes no sense. > > > > Oh, that's what I feared. I read some docs but probably will need more > > :) > > > > Anyway, the reason to use in-band negotiation was also to avoid using > > fixed-link. It would work but always report the link is up, which for > > the user isn't a great experience as we have a way to detect this. > > > > What would you suggest to achieve this in a reasonable way? > > The intention of this test in phylink_of_phy_connect() is to avoid failing > when there is no requirement for a PHY to be present (such as a fixed link, or > an 802.3z link.) However, with 10G PHYs such as the 3310, we need the PHY > so we can read the speed from it, and so know whether to downgrade the > MAC to SGMII mode, or having downgraded the MAC, upgrade it back to 10G > mode when the PHY switches to 10G. > > I'm guessing that you're wanting this for the DB boards, but I don't see why. > Do they not have PHYs? New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, like DB boards. https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/ Stefan, Best Regards.
RE: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation
> > > There is no inband negotiation like there is with 802.3z or SGMII, > > > so this makes no sense. > > > > Oh, that's what I feared. I read some docs but probably will need more > > :) > > > > Anyway, the reason to use in-band negotiation was also to avoid using > > fixed-link. It would work but always report the link is up, which for > > the user isn't a great experience as we have a way to detect this. > > > > What would you suggest to achieve this in a reasonable way? > > The intention of this test in phylink_of_phy_connect() is to avoid failing > when there is no requirement for a PHY to be present (such as a fixed link, or > an 802.3z link.) However, with 10G PHYs such as the 3310, we need the PHY > so we can read the speed from it, and so know whether to downgrade the > MAC to SGMII mode, or having downgraded the MAC, upgrade it back to 10G > mode when the PHY switches to 10G. > > I'm guessing that you're wanting this for the DB boards, but I don't see why. > Do they not have PHYs? New Solid Run board MACCHIATObin Single Shot doesn't has 3310 PHY either, like DB boards. https://www.cnx-software.com/2017/12/20/solidrun-macchiatobin-single-shot-networking-board-launched-for-269-and-up/ Stefan, Best Regards.
