| Message ID | E1j6tqv-0003G6-BO@rmk-PC.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | rework phylink interface for split MAC/PCS support | expand |
Hi Russell, On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote: > > Propagate the resolved link parameters via the mac_link_up() call for > MACs that do not automatically track their PCS state. We propagate the > link parameters via function arguments so that inappropriate members > of struct phylink_link_state can't be accessed, and creating a new > structure just for this adds needless complexity to the API. > > Tested-by: Andre Przywara <andre.przywara@arm.com> > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > --- > Documentation/networking/sfp-phylink.rst | 17 +++++- > drivers/net/ethernet/cadence/macb_main.c | 7 ++- > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++- > drivers/net/ethernet/marvell/mvneta.c | 8 ++- > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++-- > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++- > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +- > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++- > drivers/net/phy/phylink.c | 9 ++- > include/linux/phylink.h | 57 ++++++++++++++----- > net/dsa/port.c | 4 +- > 11 files changed, 105 insertions(+), 41 deletions(-) > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst > index d753a309f9d1..8d7af28cd835 100644 > --- a/Documentation/networking/sfp-phylink.rst > +++ b/Documentation/networking/sfp-phylink.rst > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve > this documentation. > > 1. Optionally split the network driver's phylib update function into > - three parts dealing with link-down, link-up and reconfiguring the > - MAC settings. This can be done as a separate preparation commit. > + two parts dealing with link-down and link-up. This can be done as > + a separate preparation commit. > > - An example of this preparation can be found in git commit fc548b991fb0. > + An older example of this preparation can be found in git commit > + fc548b991fb0, although this was splitting into three parts; the > + link-up part now includes configuring the MAC for the link settings. > + Please see :c:func:`mac_link_up` for more information on this. > > 2. Replace:: > > @@ -207,6 +210,14 @@ this documentation. > using. This is particularly important for in-band negotiation > methods such as 1000base-X and SGMII. > > + The :c:func:`mac_link_up` method is used to inform the MAC that the > + link has come up. The call includes the negotiation mode and interface > + for reference only. The finalised link parameters are also supplied > + (speed, duplex and flow control/pause enablement settings) which > + should be used to configure the MAC when the MAC and PCS are not > + tightly integrated, or when the settings are not coming from in-band > + negotiation. > + > The :c:func:`mac_config` method is used to update the MAC with the > requested state, and must avoid unnecessarily taking the link down > when making changes to the MAC configuration. This means the Just to make sure I understand the changes: - A MAC with no PCS can be configured in either .mac_config or .mac_link_up - A MAC that needs to be manually reconfigured to the link mode negotiated by its PCS needs to have the PCS configured in .mac_config and the MAC in .mac_link_up - A MAC with PCS where the MAC follows the PCS negotiation automatically in hardware is basically equivalent with a MAC with no PCS, and therefore can be configured in either .mac_config or .mac_link_up Is this correct? Regards, -Vladimir
On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote: > Hi Russell, > > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote: > > > > Propagate the resolved link parameters via the mac_link_up() call for > > MACs that do not automatically track their PCS state. We propagate the > > link parameters via function arguments so that inappropriate members > > of struct phylink_link_state can't be accessed, and creating a new > > structure just for this adds needless complexity to the API. > > > > Tested-by: Andre Przywara <andre.przywara@arm.com> > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > --- > > Documentation/networking/sfp-phylink.rst | 17 +++++- > > drivers/net/ethernet/cadence/macb_main.c | 7 ++- > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++- > > drivers/net/ethernet/marvell/mvneta.c | 8 ++- > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++-- > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++- > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +- > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++- > > drivers/net/phy/phylink.c | 9 ++- > > include/linux/phylink.h | 57 ++++++++++++++----- > > net/dsa/port.c | 4 +- > > 11 files changed, 105 insertions(+), 41 deletions(-) > > > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst > > index d753a309f9d1..8d7af28cd835 100644 > > --- a/Documentation/networking/sfp-phylink.rst > > +++ b/Documentation/networking/sfp-phylink.rst > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve > > this documentation. > > > > 1. Optionally split the network driver's phylib update function into > > - three parts dealing with link-down, link-up and reconfiguring the > > - MAC settings. This can be done as a separate preparation commit. > > + two parts dealing with link-down and link-up. This can be done as > > + a separate preparation commit. > > > > - An example of this preparation can be found in git commit fc548b991fb0. > > + An older example of this preparation can be found in git commit > > + fc548b991fb0, although this was splitting into three parts; the > > + link-up part now includes configuring the MAC for the link settings. > > + Please see :c:func:`mac_link_up` for more information on this. > > > > 2. Replace:: > > > > @@ -207,6 +210,14 @@ this documentation. > > using. This is particularly important for in-band negotiation > > methods such as 1000base-X and SGMII. > > > > + The :c:func:`mac_link_up` method is used to inform the MAC that the > > + link has come up. The call includes the negotiation mode and interface > > + for reference only. The finalised link parameters are also supplied > > + (speed, duplex and flow control/pause enablement settings) which > > + should be used to configure the MAC when the MAC and PCS are not > > + tightly integrated, or when the settings are not coming from in-band > > + negotiation. > > + > > The :c:func:`mac_config` method is used to update the MAC with the > > requested state, and must avoid unnecessarily taking the link down > > when making changes to the MAC configuration. This means the > > Just to make sure I understand the changes: > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up I would much prefer mac_link_up to be used for setting the speed, duplex and pause modes for future-proofing in all cases except for the case where these parameters are automatically updated in the MAC from its associated PCS. mac_link_up must not be used to configure the AN mode or interface mode; these must be configured in mac_config(). > - A MAC that needs to be manually reconfigured to the link mode > negotiated by its PCS needs to have the PCS configured in .mac_config > and the MAC in .mac_link_up I do have further changes that split the PCS ops from the MAC ops, so what is in this series is not the full story yet - some of the further patches can be found in my "phy" branch and "cex7" branches where I add support to dpaa2 for automatically switching between SGMII and 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the extra complication that there's a firmware layer between the PCS and MAC. However, this series is the first stand-alone step along the road to supporting split PCS/MAC setups in a sane manner. I discussed with Andrew Lunn how much to send, and the conclusion was to make the changes in a number of small patch series, as large patch series tend not to get reviewed. My experience with _this_ series is that even this is very difficult to get feedback for, so adding any additional patches will just make that worse. > - A MAC with PCS where the MAC follows the PCS negotiation > automatically in hardware is basically equivalent with a MAC with no > PCS, and therefore can be configured in either .mac_config or > .mac_link_up In this case, mac_link_up doesn't do anything with the speed/duplex/ pause stuff when those are automatically passed from the PCS. I'm afraid that sentence contains a subtlety that's going to get people: it is not clear cut because of the different natures of the various links. In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the duplex and pause with the remote end. For mvneta (an example of a combined PCS/MAC implementation) operating in-band: - In mac_config(): - configures for 1000BASE-X interface type with in-band AN. - configures fixed 1G. - As mvneta only supports full duplex, we disable duplex negotiation and force full duplex. - Only symmetric pause is supported, and we set the symmetric pause advertisement appropriately, with pause negotiation enabled. - In mac_link_up(): - merely allow the device to transmit and receive. The MAC will be forced to 1G, full duplex, and will automatically be configured by the PCS for pause support depending on the hardware based pause resolution. The situation is different for SGMII operating in-band: - In mac_config(): - configures for SGMII interface type with in-band AN. - configures speed and duplex negotiation. - disables pause negotiation; SGMII has no support for this. - In mac_link_up(): - enables or disables pause frames depending on the tx_pause/ rx_pause flags, since this is not available from the MAC. - allow the device to transmit and receive. If we aren't operating in in-band mode, then: - In mac_config(): - configures for the interface type without in-band AN. - disables speed, duplex and pause negotiation. - In mac_link_up(): - sets the speed, duplex and pause frames depending on the passed parameters. - allow the device to transmit and receive. Please see patch 7 of this series which implements this for mvneta. So, there is a split between what mac_config() should be doing and what mac_link_up() should be doing; this is why I've said in the documentation that the "mode" and "interface" are for reference only in mac_link_up() - mac_link_up() can use these to decide _how_ to program the resolved parameters, but should _not_ use them to determine the link configuration (such as changing the interface between SGMII and 1000BASE-X - that is the responsibility of mac_config().) I hope that helps clarify the situation.
On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote: > > Hi Russell, > > > > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote: > > > > > > Propagate the resolved link parameters via the mac_link_up() call for > > > MACs that do not automatically track their PCS state. We propagate the > > > link parameters via function arguments so that inappropriate members > > > of struct phylink_link_state can't be accessed, and creating a new > > > structure just for this adds needless complexity to the API. > > > > > > Tested-by: Andre Przywara <andre.przywara@arm.com> > > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > --- > > > Documentation/networking/sfp-phylink.rst | 17 +++++- > > > drivers/net/ethernet/cadence/macb_main.c | 7 ++- > > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++- > > > drivers/net/ethernet/marvell/mvneta.c | 8 ++- > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++-- > > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++- > > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +- > > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++- > > > drivers/net/phy/phylink.c | 9 ++- > > > include/linux/phylink.h | 57 ++++++++++++++----- > > > net/dsa/port.c | 4 +- > > > 11 files changed, 105 insertions(+), 41 deletions(-) > > > > > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst > > > index d753a309f9d1..8d7af28cd835 100644 > > > --- a/Documentation/networking/sfp-phylink.rst > > > +++ b/Documentation/networking/sfp-phylink.rst > > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve > > > this documentation. > > > > > > 1. Optionally split the network driver's phylib update function into > > > - three parts dealing with link-down, link-up and reconfiguring the > > > - MAC settings. This can be done as a separate preparation commit. > > > + two parts dealing with link-down and link-up. This can be done as > > > + a separate preparation commit. > > > > > > - An example of this preparation can be found in git commit fc548b991fb0. > > > + An older example of this preparation can be found in git commit > > > + fc548b991fb0, although this was splitting into three parts; the > > > + link-up part now includes configuring the MAC for the link settings. > > > + Please see :c:func:`mac_link_up` for more information on this. > > > > > > 2. Replace:: > > > > > > @@ -207,6 +210,14 @@ this documentation. > > > using. This is particularly important for in-band negotiation > > > methods such as 1000base-X and SGMII. > > > > > > + The :c:func:`mac_link_up` method is used to inform the MAC that the > > > + link has come up. The call includes the negotiation mode and interface > > > + for reference only. The finalised link parameters are also supplied > > > + (speed, duplex and flow control/pause enablement settings) which > > > + should be used to configure the MAC when the MAC and PCS are not > > > + tightly integrated, or when the settings are not coming from in-band > > > + negotiation. > > > + > > > The :c:func:`mac_config` method is used to update the MAC with the > > > requested state, and must avoid unnecessarily taking the link down > > > when making changes to the MAC configuration. This means the > > > > Just to make sure I understand the changes: > > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up > > I would much prefer mac_link_up to be used for setting the speed, > duplex and pause modes for future-proofing in all cases except for > the case where these parameters are automatically updated in the > MAC from its associated PCS. > > mac_link_up must not be used to configure the AN mode or interface > mode; these must be configured in mac_config(). > > > - A MAC that needs to be manually reconfigured to the link mode > > negotiated by its PCS needs to have the PCS configured in .mac_config > > and the MAC in .mac_link_up > > I do have further changes that split the PCS ops from the MAC ops, so > what is in this series is not the full story yet - some of the further > patches can be found in my "phy" branch and "cex7" branches where I add > support to dpaa2 for automatically switching between SGMII and > 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the > extra complication that there's a firmware layer between the PCS and > MAC. > > However, this series is the first stand-alone step along the road to > supporting split PCS/MAC setups in a sane manner. > > I discussed with Andrew Lunn how much to send, and the conclusion was > to make the changes in a number of small patch series, as large patch > series tend not to get reviewed. My experience with _this_ series is > that even this is very difficult to get feedback for, so adding any > additional patches will just make that worse. > > > - A MAC with PCS where the MAC follows the PCS negotiation > > automatically in hardware is basically equivalent with a MAC with no > > PCS, and therefore can be configured in either .mac_config or > > .mac_link_up > > In this case, mac_link_up doesn't do anything with the speed/duplex/ > pause stuff when those are automatically passed from the PCS. > > I'm afraid that sentence contains a subtlety that's going to get > people: it is not clear cut because of the different natures of the > various links. > > In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the > duplex and pause with the remote end. For mvneta (an example of a > combined PCS/MAC implementation) operating in-band: > - In mac_config(): > - configures for 1000BASE-X interface type with in-band AN. > - configures fixed 1G. > - As mvneta only supports full duplex, we disable duplex negotiation > and force full duplex. > - Only symmetric pause is supported, and we set the symmetric pause > advertisement appropriately, with pause negotiation enabled. > - In mac_link_up(): > - merely allow the device to transmit and receive. > > The MAC will be forced to 1G, full duplex, and will automatically be > configured by the PCS for pause support depending on the hardware > based pause resolution. > > The situation is different for SGMII operating in-band: > - In mac_config(): > - configures for SGMII interface type with in-band AN. > - configures speed and duplex negotiation. > - disables pause negotiation; SGMII has no support for this. > - In mac_link_up(): > - enables or disables pause frames depending on the tx_pause/ > rx_pause flags, since this is not available from the MAC. > - allow the device to transmit and receive. > > If we aren't operating in in-band mode, then: > - In mac_config(): > - configures for the interface type without in-band AN. > - disables speed, duplex and pause negotiation. > - In mac_link_up(): > - sets the speed, duplex and pause frames depending on the passed > parameters. But there shouldn't be any requirement for this to be configured at this step and not earlier? > - allow the device to transmit and receive. > > Please see patch 7 of this series which implements this for mvneta. > > So, there is a split between what mac_config() should be doing and what > mac_link_up() should be doing; this is why I've said in the > documentation that the "mode" and "interface" are for reference only in > mac_link_up() - mac_link_up() can use these to decide _how_ to program > the resolved parameters, but should _not_ use them to determine the > link configuration (such as changing the interface between SGMII and > 1000BASE-X - that is the responsibility of mac_config().) Does any driver currently make any use of the phy_interface_t argument provided as reference in .mac_link_up? > > I hope that helps clarify the situation. > > -- > RMK's Patch system: https://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 Ok, so basically what is known early, as well as whatever is needed for the in-band AN preparation, is configured in .mac_config and what is known late is configured in .mac_link_up. Except that you would like to slowly move everything MAC-related to .mac_link_up, and everything PCS-related to .mac_config, presumably in an effort to convert .mac_config to .pcs_config and .mac_link_up to .mac_config. I don't actually know what other patches you have in the cex7 branch you mentioned. Please consider that people don't necessarily bookmark your git trees. I've spent some good 10 minutes searching for the "cex7" and "phy" keywords in emails received from you, and haven't found the git links. Regards, -Vladimir
On Wed, Feb 26, 2020 at 03:00:30PM +0200, Vladimir Oltean wrote: > On Wed, 26 Feb 2020 at 13:56, Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: > > > > On Wed, Feb 26, 2020 at 01:06:06PM +0200, Vladimir Oltean wrote: > > > Hi Russell, > > > > > > On Wed, 26 Feb 2020 at 12:23, Russell King <rmk+kernel@armlinux.org.uk> wrote: > > > > > > > > Propagate the resolved link parameters via the mac_link_up() call for > > > > MACs that do not automatically track their PCS state. We propagate the > > > > link parameters via function arguments so that inappropriate members > > > > of struct phylink_link_state can't be accessed, and creating a new > > > > structure just for this adds needless complexity to the API. > > > > > > > > Tested-by: Andre Przywara <andre.przywara@arm.com> > > > > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > > > > Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > > --- > > > > Documentation/networking/sfp-phylink.rst | 17 +++++- > > > > drivers/net/ethernet/cadence/macb_main.c | 7 ++- > > > > .../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 7 ++- > > > > drivers/net/ethernet/marvell/mvneta.c | 8 ++- > > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +++++-- > > > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++- > > > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +- > > > > .../net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++- > > > > drivers/net/phy/phylink.c | 9 ++- > > > > include/linux/phylink.h | 57 ++++++++++++++----- > > > > net/dsa/port.c | 4 +- > > > > 11 files changed, 105 insertions(+), 41 deletions(-) > > > > > > > > diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst > > > > index d753a309f9d1..8d7af28cd835 100644 > > > > --- a/Documentation/networking/sfp-phylink.rst > > > > +++ b/Documentation/networking/sfp-phylink.rst > > > > @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve > > > > this documentation. > > > > > > > > 1. Optionally split the network driver's phylib update function into > > > > - three parts dealing with link-down, link-up and reconfiguring the > > > > - MAC settings. This can be done as a separate preparation commit. > > > > + two parts dealing with link-down and link-up. This can be done as > > > > + a separate preparation commit. > > > > > > > > - An example of this preparation can be found in git commit fc548b991fb0. > > > > + An older example of this preparation can be found in git commit > > > > + fc548b991fb0, although this was splitting into three parts; the > > > > + link-up part now includes configuring the MAC for the link settings. > > > > + Please see :c:func:`mac_link_up` for more information on this. > > > > > > > > 2. Replace:: > > > > > > > > @@ -207,6 +210,14 @@ this documentation. > > > > using. This is particularly important for in-band negotiation > > > > methods such as 1000base-X and SGMII. > > > > > > > > + The :c:func:`mac_link_up` method is used to inform the MAC that the > > > > + link has come up. The call includes the negotiation mode and interface > > > > + for reference only. The finalised link parameters are also supplied > > > > + (speed, duplex and flow control/pause enablement settings) which > > > > + should be used to configure the MAC when the MAC and PCS are not > > > > + tightly integrated, or when the settings are not coming from in-band > > > > + negotiation. > > > > + > > > > The :c:func:`mac_config` method is used to update the MAC with the > > > > requested state, and must avoid unnecessarily taking the link down > > > > when making changes to the MAC configuration. This means the > > > > > > Just to make sure I understand the changes: > > > - A MAC with no PCS can be configured in either .mac_config or .mac_link_up > > > > I would much prefer mac_link_up to be used for setting the speed, > > duplex and pause modes for future-proofing in all cases except for > > the case where these parameters are automatically updated in the > > MAC from its associated PCS. > > > > mac_link_up must not be used to configure the AN mode or interface > > mode; these must be configured in mac_config(). > > > > > - A MAC that needs to be manually reconfigured to the link mode > > > negotiated by its PCS needs to have the PCS configured in .mac_config > > > and the MAC in .mac_link_up > > > > I do have further changes that split the PCS ops from the MAC ops, so > > what is in this series is not the full story yet - some of the further > > patches can be found in my "phy" branch and "cex7" branches where I add > > support to dpaa2 for automatically switching between SGMII and > > 1000BASE-X. dpaa2 is one of these split PCS/MAC setups, but with the > > extra complication that there's a firmware layer between the PCS and > > MAC. > > > > However, this series is the first stand-alone step along the road to > > supporting split PCS/MAC setups in a sane manner. > > > > I discussed with Andrew Lunn how much to send, and the conclusion was > > to make the changes in a number of small patch series, as large patch > > series tend not to get reviewed. My experience with _this_ series is > > that even this is very difficult to get feedback for, so adding any > > additional patches will just make that worse. > > > > > - A MAC with PCS where the MAC follows the PCS negotiation > > > automatically in hardware is basically equivalent with a MAC with no > > > PCS, and therefore can be configured in either .mac_config or > > > .mac_link_up > > > > In this case, mac_link_up doesn't do anything with the speed/duplex/ > > pause stuff when those are automatically passed from the PCS. > > > > I'm afraid that sentence contains a subtlety that's going to get > > people: it is not clear cut because of the different natures of the > > various links. > > > > In 1000BASE-X, speed is fixed at 1G, and the PCS autonegotiates the > > duplex and pause with the remote end. For mvneta (an example of a > > combined PCS/MAC implementation) operating in-band: > > - In mac_config(): > > - configures for 1000BASE-X interface type with in-band AN. > > - configures fixed 1G. > > - As mvneta only supports full duplex, we disable duplex negotiation > > and force full duplex. > > - Only symmetric pause is supported, and we set the symmetric pause > > advertisement appropriately, with pause negotiation enabled. > > - In mac_link_up(): > > - merely allow the device to transmit and receive. > > > > The MAC will be forced to 1G, full duplex, and will automatically be > > configured by the PCS for pause support depending on the hardware > > based pause resolution. > > > > The situation is different for SGMII operating in-band: > > - In mac_config(): > > - configures for SGMII interface type with in-band AN. > > - configures speed and duplex negotiation. > > - disables pause negotiation; SGMII has no support for this. > > - In mac_link_up(): > > - enables or disables pause frames depending on the tx_pause/ > > rx_pause flags, since this is not available from the MAC. > > - allow the device to transmit and receive. > > > > If we aren't operating in in-band mode, then: > > - In mac_config(): > > - configures for the interface type without in-band AN. > > - disables speed, duplex and pause negotiation. > > - In mac_link_up(): > > - sets the speed, duplex and pause frames depending on the passed > > parameters. > > But there shouldn't be any requirement for this to be configured at > this step and not earlier? > > > - allow the device to transmit and receive. > > > > Please see patch 7 of this series which implements this for mvneta. > > > > So, there is a split between what mac_config() should be doing and what > > mac_link_up() should be doing; this is why I've said in the > > documentation that the "mode" and "interface" are for reference only in > > mac_link_up() - mac_link_up() can use these to decide _how_ to program > > the resolved parameters, but should _not_ use them to determine the > > link configuration (such as changing the interface between SGMII and > > 1000BASE-X - that is the responsibility of mac_config().) > > Does any driver currently make any use of the phy_interface_t argument > provided as reference in .mac_link_up? Yes. mvpp2 uses it to decide whether to configure the 10/100/1G MAC or the 10G XLG MAC, for example - there are drivers that need to configure different blocks for the link-up event depending on the interface mode. Rather than having drivers store the interface mode internally, copying what phylink is doing, we provide that to the network driver so it can make its own decisions without that additional complexity. > > I hope that helps clarify the situation. > > > > -- > > RMK's Patch system: https://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 > > Ok, so basically what is known early, as well as whatever is needed > for the in-band AN preparation, is configured in .mac_config and what > is known late is configured in .mac_link_up. I envision a time when the speed/duplex/pause settings will not be passed to mac_config. > Except that you would like to slowly move everything MAC-related to > .mac_link_up, and everything PCS-related to .mac_config, presumably in > an effort to convert .mac_config to .pcs_config and .mac_link_up to > .mac_config. I don't actually know what other patches you have in the > cex7 branch you mentioned. Please consider that people don't > necessarily bookmark your git trees. I've spent some good 10 minutes > searching for the "cex7" and "phy" keywords in emails received from > you, and haven't found the git links. http://git.armlinux.org.uk/cgit/linux-arm.git/ I'm afraid that it's rather scattered amongst quite a few branches at the moment, because of their dependencies on other stuff in my tree. For dpaa2, see: http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=cex7 specifically: "dpaa2-mac: add PCS support" "net: phylink: add c45 pcs helpers" "net: phylink: helpers for 802.3 clause 37/SGMII register sets" "net: phylink: add pcs operations" "net: phylink: rename 'ops' to 'mac_ops'" "net: mii: add linkmode_adv_to_mii_adv_x()" "net: mii: convert mii_lpa_to_ethtool_lpa_x() to linkmode variant" dpaa2 is complicated by the firmware, and that we can't switch the interface mode between (SGMII,1000base-X) and 10G. If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told the current link parameters via the dpmac_set_link_state() call - it isn't clear whether that needs to be called for other modes with the up/down state (firmware API documentation is poor.)
On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > dpaa2 is complicated by the firmware, and that we can't switch the > interface mode between (SGMII,1000base-X) and 10G. > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told > the current link parameters via the dpmac_set_link_state() call - it > isn't clear whether that needs to be called for other modes with the > up/down state (firmware API documentation is poor.) > With PCS control in Linux, I am pretty sure that you don't want anything other than DPMAC_LINK_TYPE_PHY anyway. Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of the PCS and polls its link state to emit link notifications to objects connected to the DPMAC. So Linux control of PCS would class with firmware control of the PCS, leading to undesirable side-effects to say the least. > -- > RMK's Patch system: https://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 Regards, -Vladimir
On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote: > > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: > > > > > > dpaa2 is complicated by the firmware, and that we can't switch the > > interface mode between (SGMII,1000base-X) and 10G. > > > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told > > the current link parameters via the dpmac_set_link_state() call - it > > isn't clear whether that needs to be called for other modes with the > > up/down state (firmware API documentation is poor.) > > > > With PCS control in Linux, I am pretty sure that you don't want > anything other than DPMAC_LINK_TYPE_PHY anyway. > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of > the PCS and polls its link state to emit link notifications to objects > connected to the DPMAC. So Linux control of PCS would class with s/class/clash/ > firmware control of the PCS, leading to undesirable side-effects to > say the least. > > > -- > > RMK's Patch system: https://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 > > Regards, > -Vladimir
On Wed, Feb 26, 2020 at 08:22:39PM +0200, Vladimir Oltean wrote: > On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote: > > > > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin > > <linux@armlinux.org.uk> wrote: > > > > > > > > > dpaa2 is complicated by the firmware, and that we can't switch the > > > interface mode between (SGMII,1000base-X) and 10G. > > > > > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be told > > > the current link parameters via the dpmac_set_link_state() call - it > > > isn't clear whether that needs to be called for other modes with the > > > up/down state (firmware API documentation is poor.) > > > > > > > With PCS control in Linux, I am pretty sure that you don't want > > anything other than DPMAC_LINK_TYPE_PHY anyway. > > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of > > the PCS and polls its link state to emit link notifications to objects > > connected to the DPMAC. So Linux control of PCS would class with > > s/class/clash/ > > > firmware control of the PCS, leading to undesirable side-effects to > > say the least. Yes, which is why we only register the PCS with phylink if we're in DPMAC_LINK_TYPE_PHY mode.
> Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config > via mac_link_up() > > On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote: > > > > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin > > <linux@armlinux.org.uk> wrote: > > > > > > > > > dpaa2 is complicated by the firmware, and that we can't switch the > > > interface mode between (SGMII,1000base-X) and 10G. > > > > > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be > > > told the current link parameters via the dpmac_set_link_state() call > > > - it isn't clear whether that needs to be called for other modes > > > with the up/down state (firmware API documentation is poor.) > > > > > > > With PCS control in Linux, I am pretty sure that you don't want > > anything other than DPMAC_LINK_TYPE_PHY anyway. > > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of > > the PCS and polls its link state to emit link notifications to objects > > connected to the DPMAC. So Linux control of PCS would class with > > s/class/clash/ > > > firmware control of the PCS, leading to undesirable side-effects to > > say the least. If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact does not even connect to a phy so all the phylink interaction is not happening. As Vladimir said, in this case it's the MC firmware's job to poll the PCS and notify any connected objects of a link change. > > > > Regards, > > -Vladimir
On Wed, Feb 26, 2020 at 06:32:55PM +0000, Ioana Ciornei wrote: > > Subject: Re: [PATCH net-next v2 1/8] net: phylink: propagate resolved link config > > via mac_link_up() > > > > On Wed, 26 Feb 2020 at 20:21, Vladimir Oltean <olteanv@gmail.com> wrote: > > > > > > On Wed, 26 Feb 2020 at 15:36, Russell King - ARM Linux admin > > > <linux@armlinux.org.uk> wrote: > > > > > > > > > > > > dpaa2 is complicated by the firmware, and that we can't switch the > > > > interface mode between (SGMII,1000base-X) and 10G. > > > > > > > > If the firmware is in "DPMAC_LINK_TYPE_PHY" mode, it expects to be > > > > told the current link parameters via the dpmac_set_link_state() call > > > > - it isn't clear whether that needs to be called for other modes > > > > with the up/down state (firmware API documentation is poor.) > > > > > > > > > > With PCS control in Linux, I am pretty sure that you don't want > > > anything other than DPMAC_LINK_TYPE_PHY anyway. > > > Basically in DPMAC_LINK_TYPE_FIXED, the MC firmware is in control of > > > the PCS and polls its link state to emit link notifications to objects > > > connected to the DPMAC. So Linux control of PCS would class with > > > > s/class/clash/ > > > > > firmware control of the PCS, leading to undesirable side-effects to > > > say the least. > > > If the DPMAC object is in DPMAC_LINK_TYPE_FIXED, the dpaa2-eth in fact > does not even connect to a phy so all the phylink interaction is not happening. > As Vladimir said, in this case it's the MC firmware's job to poll the PCS and > notify any connected objects of a link change. Please see the patches I've referred Vladimir to, specifically this: if (attr.link_type == DPMAC_LINK_TYPE_PHY) { /* FIXME: how do we know whether this DPMAC has a PCS? */ err = dpaa2_pcs_create(mac, attr.id); if (err) goto err_phylink_destroy; phylink_add_pcs(mac->phylink, &dpaa2_pcs_phylink_ops); } Hence, if we are not in DPMAC_LINK_TYPE_PHY, then we never talk to the PCS, thereby satisfying the requirements of the firmware not to touch the PCS if it's in FIXED mode. It seems this is becoming a storm in a tea cup. Please stop.
diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst index d753a309f9d1..8d7af28cd835 100644 --- a/Documentation/networking/sfp-phylink.rst +++ b/Documentation/networking/sfp-phylink.rst @@ -74,10 +74,13 @@ phylib to the sfp/phylink support. Please send patches to improve this documentation. 1. Optionally split the network driver's phylib update function into - three parts dealing with link-down, link-up and reconfiguring the - MAC settings. This can be done as a separate preparation commit. + two parts dealing with link-down and link-up. This can be done as + a separate preparation commit. - An example of this preparation can be found in git commit fc548b991fb0. + An older example of this preparation can be found in git commit + fc548b991fb0, although this was splitting into three parts; the + link-up part now includes configuring the MAC for the link settings. + Please see :c:func:`mac_link_up` for more information on this. 2. Replace:: @@ -207,6 +210,14 @@ this documentation. using. This is particularly important for in-band negotiation methods such as 1000base-X and SGMII. + The :c:func:`mac_link_up` method is used to inform the MAC that the + link has come up. The call includes the negotiation mode and interface + for reference only. The finalised link parameters are also supplied + (speed, duplex and flow control/pause enablement settings) which + should be used to configure the MAC when the MAC and PCS are not + tightly integrated, or when the settings are not coming from in-band + negotiation. + The :c:func:`mac_config` method is used to update the MAC with the requested state, and must avoid unnecessarily taking the link down when making changes to the MAC configuration. This means the diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 2c28da1737fe..7ab0bef5e1bd 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -626,8 +626,11 @@ static void macb_mac_link_down(struct phylink_config *config, unsigned int mode, netif_tx_stop_all_queues(ndev); } -static void macb_mac_link_up(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, struct phy_device *phy) +static void macb_mac_link_up(struct phylink_config *config, + struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, + bool tx_pause, bool rx_pause) { struct net_device *ndev = to_net_dev(config->dev); struct macb *bp = netdev_priv(ndev); diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c index 84233e467ed1..3a75c5b58f95 100644 --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c @@ -154,8 +154,11 @@ static void dpaa2_mac_config(struct phylink_config *config, unsigned int mode, netdev_err(mac->net_dev, "dpmac_set_link_state() = %d\n", err); } -static void dpaa2_mac_link_up(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, struct phy_device *phy) +static void dpaa2_mac_link_up(struct phylink_config *config, + struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, + bool tx_pause, bool rx_pause) { struct dpaa2_mac *mac = phylink_to_dpaa2_mac(config); struct dpmac_link_state *dpmac_state = &mac->state; diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c index 1c391f63a26f..9af3f8d5b289 100644 --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -3965,9 +3965,11 @@ static void mvneta_mac_link_down(struct phylink_config *config, mvneta_set_eee(pp, false); } -static void mvneta_mac_link_up(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, - struct phy_device *phy) +static void mvneta_mac_link_up(struct phylink_config *config, + struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, + bool tx_pause, bool rx_pause) { struct net_device *ndev = to_net_dev(config->dev); struct mvneta_port *pp = netdev_priv(ndev); diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index 72133cbe55d4..ed8042d97e29 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -58,8 +58,11 @@ static struct { */ static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode, const struct phylink_link_state *state); -static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, struct phy_device *phy); +static void mvpp2_mac_link_up(struct phylink_config *config, + struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, + bool tx_pause, bool rx_pause); /* Queue modes */ #define MVPP2_QDIST_SINGLE_MODE 0 @@ -3473,8 +3476,9 @@ static void mvpp2_start_dev(struct mvpp2_port *port) .interface = port->phy_interface, }; mvpp2_mac_config(&port->phylink_config, MLO_AN_INBAND, &state); - mvpp2_mac_link_up(&port->phylink_config, MLO_AN_INBAND, - port->phy_interface, NULL); + mvpp2_mac_link_up(&port->phylink_config, NULL, + MLO_AN_INBAND, port->phy_interface, + SPEED_UNKNOWN, DUPLEX_UNKNOWN, false, false); } netif_tx_start_all_queues(port->dev); @@ -5141,8 +5145,11 @@ static void mvpp2_mac_config(struct phylink_config *config, unsigned int mode, mvpp2_port_enable(port); } -static void mvpp2_mac_link_up(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, struct phy_device *phy) +static void mvpp2_mac_link_up(struct phylink_config *config, + struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, + bool tx_pause, bool rx_pause) { struct net_device *dev = to_net_dev(config->dev); struct mvpp2_port *port = netdev_priv(dev); diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c index 8c6cfd15481c..8d28f90acfe7 100644 --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c @@ -412,9 +412,10 @@ static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode, mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id)); } -static void mtk_mac_link_up(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, - struct phy_device *phy) +static void mtk_mac_link_up(struct phylink_config *config, + struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, bool tx_pause, bool rx_pause) { struct mtk_mac *mac = container_of(config, struct mtk_mac, phylink_config); diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 37920b4da091..e039e715dcee 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -950,8 +950,10 @@ static void stmmac_mac_link_down(struct phylink_config *config, } static void stmmac_mac_link_up(struct phylink_config *config, + struct phy_device *phy, unsigned int mode, phy_interface_t interface, - struct phy_device *phy) + int speed, int duplex, + bool tx_pause, bool rx_pause) { struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev)); diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c index 20746b801959..197740781157 100644 --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c @@ -1486,9 +1486,10 @@ static void axienet_mac_link_down(struct phylink_config *config, } static void axienet_mac_link_up(struct phylink_config *config, - unsigned int mode, - phy_interface_t interface, - struct phy_device *phy) + struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, + bool tx_pause, bool rx_pause) { /* nothing meaningful to do */ } diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 2899fbe699ab..b4367fab7899 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -480,8 +480,11 @@ static void phylink_mac_link_up(struct phylink *pl, struct net_device *ndev = pl->netdev; pl->cur_interface = link_state.interface; - pl->ops->mac_link_up(pl->config, pl->cur_link_an_mode, - pl->cur_interface, pl->phydev); + pl->ops->mac_link_up(pl->config, pl->phydev, + pl->cur_link_an_mode, pl->cur_interface, + link_state.speed, link_state.duplex, + !!(link_state.pause & MLO_PAUSE_TX), + !!(link_state.pause & MLO_PAUSE_RX)); if (ndev) netif_carrier_on(ndev); @@ -547,6 +550,8 @@ static void phylink_resolve(struct work_struct *w) link_state.pause = pl->phy_state.pause; phylink_apply_manual_flow(pl, &link_state); phylink_mac_config(pl, &link_state); + } else { + phylink_apply_manual_flow(pl, &link_state); } break; } diff --git a/include/linux/phylink.h b/include/linux/phylink.h index 812357c03df4..2180eb1aa254 100644 --- a/include/linux/phylink.h +++ b/include/linux/phylink.h @@ -91,9 +91,10 @@ struct phylink_mac_ops { void (*mac_an_restart)(struct phylink_config *config); void (*mac_link_down)(struct phylink_config *config, unsigned int mode, phy_interface_t interface); - void (*mac_link_up)(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, - struct phy_device *phy); + void (*mac_link_up)(struct phylink_config *config, + struct phy_device *phy, unsigned int mode, + phy_interface_t interface, int speed, int duplex, + bool tx_pause, bool rx_pause); }; #if 0 /* For kernel-doc purposes only. */ @@ -152,6 +153,9 @@ void mac_pcs_get_state(struct phylink_config *config, * guaranteed to be correct, and so any mac_config() implementation must * never reference these fields. * + * (this requires a rewrite - please refer to mac_link_up() for situations + * where the PCS and MAC are not tightly integrated.) + * * In all negotiation modes, as defined by @mode, @state->pause indicates the * pause settings which should be applied as follows. If %MLO_PAUSE_AN is not * set, %MLO_PAUSE_TX and %MLO_PAUSE_RX indicate whether the MAC should send @@ -162,12 +166,20 @@ void mac_pcs_get_state(struct phylink_config *config, * The action performed depends on the currently selected mode: * * %MLO_AN_FIXED, %MLO_AN_PHY: - * Configure the specified @state->speed and @state->duplex over a link - * specified by @state->interface. @state->advertising may be used, but - * is not required. Pause modes as above. Other members of @state must - * be ignored. + * Configure for non-inband negotiation mode, where the link settings + * are completely communicated via mac_link_up(). The physical link + * protocol from the MAC is specified by @state->interface. + * + * @state->advertising may be used, but is not required. + * + * Older drivers (prior to the mac_link_up() change) may use @state->speed, + * @state->duplex and @state->pause to configure the MAC, but this is + * deprecated; such drivers should be converted to use mac_link_up(). * - * Valid state members: interface, speed, duplex, pause, advertising. + * Other members of @state must be ignored. + * + * Valid state members: interface, advertising. + * Deprecated state members: speed, duplex, pause. * * %MLO_AN_INBAND: * place the link in an inband negotiation mode (such as 802.3z @@ -228,19 +240,34 @@ void mac_link_down(struct phylink_config *config, unsigned int mode, /** * mac_link_up() - allow the link to come up * @config: a pointer to a &struct phylink_config. + * @phy: any attached phy * @mode: link autonegotiation mode * @interface: link &typedef phy_interface_t mode - * @phy: any attached phy + * @speed: link speed + * @duplex: link duplex + * @tx_pause: link transmit pause enablement status + * @rx_pause: link receive pause enablement status * - * If @mode is not an in-band negotiation mode (as defined by - * phylink_autoneg_inband()), allow the link to come up. If @phy - * is non-%NULL, configure Energy Efficient Ethernet by calling + * Configure the MAC for an established link. + * + * @speed, @duplex, @tx_pause and @rx_pause indicate the finalised link + * settings, and should be used to configure the MAC block appropriately + * where these settings are not automatically conveyed from the PCS block, + * or if in-band negotiation (as defined by phylink_autoneg_inband(@mode)) + * is disabled. + * + * Note that when 802.3z in-band negotiation is in use, it is possible + * that the user wishes to override the pause settings, and this should + * be allowed when considering the implementation of this method. + * + * If in-band negotiation mode is disabled, allow the link to come up. If + * @phy is non-%NULL, configure Energy Efficient Ethernet by calling * phy_init_eee() and perform appropriate MAC configuration for EEE. * Interface type selection must be done in mac_config(). */ -void mac_link_up(struct phylink_config *config, unsigned int mode, - phy_interface_t interface, - struct phy_device *phy); +void mac_link_up(struct phylink_config *config, struct phy_device *phy, + unsigned int mode, phy_interface_t interface, + int speed, int duplex, bool tx_pause, bool rx_pause); #endif struct phylink *phylink_create(struct phylink_config *, struct fwnode_handle *, diff --git a/net/dsa/port.c b/net/dsa/port.c index 774facb8d547..b2f5262b35cf 100644 --- a/net/dsa/port.c +++ b/net/dsa/port.c @@ -489,9 +489,11 @@ static void dsa_port_phylink_mac_link_down(struct phylink_config *config, } static void dsa_port_phylink_mac_link_up(struct phylink_config *config, + struct phy_device *phydev, unsigned int mode, phy_interface_t interface, - struct phy_device *phydev) + int speed, int duplex, + bool tx_pause, bool rx_pause) { struct dsa_port *dp = container_of(config, struct dsa_port, pl_config); struct dsa_switch *ds = dp->ds;