| Message ID | 20230527172024.9154-1-michal.smulski@ooma.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next,v2] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x | expand |
You need also to implement serdes_pcs_get_state for USXGMII. Preferably by adding USXGMII relevant register constants into include/uapi/linux/mii.h, and using them to parse state register. Marek On Sat, May 27, 2023 at 10:20:24AM -0700, Michal Smulski wrote: > Enable USXGMII mode for mv88e6393x chips. Tested on Marvell 88E6191X. > > Signed-off-by: Michal Smulski <michal.smulski@ooma.com> > --- > drivers/net/dsa/mv88e6xxx/chip.c | 3 +-- > drivers/net/dsa/mv88e6xxx/port.c | 3 +++ > drivers/net/dsa/mv88e6xxx/serdes.c | 10 ++++++++-- > 3 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c > index 5bbe95fa951c..71cee154622f 100644 > --- a/drivers/net/dsa/mv88e6xxx/chip.c > +++ b/drivers/net/dsa/mv88e6xxx/chip.c > @@ -806,8 +806,7 @@ static void mv88e6393x_phylink_get_caps(struct mv88e6xxx_chip *chip, int port, > __set_bit(PHY_INTERFACE_MODE_2500BASEX, supported); > __set_bit(PHY_INTERFACE_MODE_5GBASER, supported); > __set_bit(PHY_INTERFACE_MODE_10GBASER, supported); > - /* FIXME: USXGMII is not supported yet */ > - /* __set_bit(PHY_INTERFACE_MODE_USXGMII, supported); */ > + __set_bit(PHY_INTERFACE_MODE_USXGMII, supported); > > config->mac_capabilities |= MAC_2500FD | MAC_5000FD | > MAC_10000FD; > diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c > index f79cf716c541..8daeeeb66880 100644 > --- a/drivers/net/dsa/mv88e6xxx/port.c > +++ b/drivers/net/dsa/mv88e6xxx/port.c > @@ -554,6 +554,9 @@ static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port, > case PHY_INTERFACE_MODE_10GBASER: > cmode = MV88E6393X_PORT_STS_CMODE_10GBASER; > break; > + case PHY_INTERFACE_MODE_USXGMII: > + cmode = MV88E6393X_PORT_STS_CMODE_USXGMII; > + break; > default: > cmode = 0; > } > diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c > index 72faec8f44dc..ae051d383c7e 100644 > --- a/drivers/net/dsa/mv88e6xxx/serdes.c > +++ b/drivers/net/dsa/mv88e6xxx/serdes.c > @@ -683,7 +683,8 @@ int mv88e6393x_serdes_get_lane(struct mv88e6xxx_chip *chip, int port) > cmode == MV88E6XXX_PORT_STS_CMODE_SGMII || > cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX || > cmode == MV88E6393X_PORT_STS_CMODE_5GBASER || > - cmode == MV88E6393X_PORT_STS_CMODE_10GBASER) > + cmode == MV88E6393X_PORT_STS_CMODE_10GBASER || > + cmode == MV88E6393X_PORT_STS_CMODE_USXGMII) > lane = port; > > return lane; > @@ -1018,6 +1019,7 @@ int mv88e6393x_serdes_pcs_get_state(struct mv88e6xxx_chip *chip, int port, > state); > case PHY_INTERFACE_MODE_5GBASER: > case PHY_INTERFACE_MODE_10GBASER: > + case PHY_INTERFACE_MODE_USXGMII: > return mv88e6393x_serdes_pcs_get_state_10g(chip, port, lane, > state); > > @@ -1173,6 +1175,7 @@ int mv88e6393x_serdes_irq_enable(struct mv88e6xxx_chip *chip, int port, > return mv88e6390_serdes_irq_enable_sgmii(chip, lane, enable); > case MV88E6393X_PORT_STS_CMODE_5GBASER: > case MV88E6393X_PORT_STS_CMODE_10GBASER: > + case MV88E6393X_PORT_STS_CMODE_USXGMII: > return mv88e6393x_serdes_irq_enable_10g(chip, lane, enable); > } > > @@ -1213,6 +1216,7 @@ irqreturn_t mv88e6393x_serdes_irq_status(struct mv88e6xxx_chip *chip, int port, > break; > case MV88E6393X_PORT_STS_CMODE_5GBASER: > case MV88E6393X_PORT_STS_CMODE_10GBASER: > + case MV88E6393X_PORT_STS_CMODE_USXGMII: > err = mv88e6393x_serdes_irq_status_10g(chip, lane, &status); > if (err) > return err; > @@ -1477,7 +1481,8 @@ static int mv88e6393x_serdes_erratum_5_2(struct mv88e6xxx_chip *chip, int lane, > * to SERDES operating in 10G mode. These registers only apply to 10G > * operation and have no effect on other speeds. > */ > - if (cmode != MV88E6393X_PORT_STS_CMODE_10GBASER) > + if (cmode != MV88E6393X_PORT_STS_CMODE_10GBASER && > + cmode != MV88E6393X_PORT_STS_CMODE_USXGMII) > return 0; > > for (i = 0; i < ARRAY_SIZE(fixes); ++i) { > @@ -1582,6 +1587,7 @@ int mv88e6393x_serdes_power(struct mv88e6xxx_chip *chip, int port, int lane, > break; > case MV88E6393X_PORT_STS_CMODE_5GBASER: > case MV88E6393X_PORT_STS_CMODE_10GBASER: > + case MV88E6393X_PORT_STS_CMODE_USXGMII: > err = mv88e6390_serdes_power_10g(chip, lane, on); > break; > default: > -- > 2.34.1 > >
On Sun, May 28, 2023 at 11:25:22AM +0200, Marek Behún wrote: > You need also to implement serdes_pcs_get_state for USXGMII. > > Preferably by adding USXGMII relevant register constants into > include/uapi/linux/mii.h, and using them to parse state register. And if a standard is being followed here, please try to make the code as helpers, so other USXGMII implementations can use them. Thanks Andrew
If I understand this correctly, you are asking to create a function for USXGMII similar to: static int mv88e6390_serdes_pcs_get_state_sgmii(struct mv88e6xxx_chip *chip, int port, int lane, struct phylink_link_state *state) However, the datasheet for 88e6393x chips does not document any registers for USXGMII interface (as it does for SGMII). You can only see that 10G link is valid by looking at MV88E6390_10G_STAT1 & MDIO_STAT1_LSTATUS which has already been implemented in: static int mv88e6390_serdes_pcs_get_state_10g(struct mv88e6xxx_chip *chip, int port, int lane, struct phylink_link_state *state) The datasheet states that in USXGMII mode the link is always set to 10GBASE-R coding for all data rates. From the logs, I see that that the link is configured using in-band information. However, there is no register access in MV88E6393x that would allow to either control or get status information (speed, duplex, flow control, auto-negotiation, etc). Most of "useful" registers are already defined in mv88e6xxx/serdes.h file. [ 50.624175] mv88e6085 0x0000000008b96000:02: configuring for inband/usxgmii link mode ... [ 387.116463] fsl_dpaa2_eth dpni.3 eth1: configuring for inband/usxgmii link mode [ 387.132554] fsl_dpaa2_eth dpni.3 eth1: Link is Up - 10Gbps/Full - flow control off If I misunderstood what is requested, please give me a bit more information what I should be adding for this patch to be accepted. Regards, Michal -----Original Message----- From: Andrew Lunn <andrew@lunn.ch> Sent: Monday, May 29, 2023 8:11 AM To: Marek Behún <marek.behun@nic.cz> Cc: Michal Smulski <msmulski2@gmail.com>; f.fainelli@gmail.com; olteanv@gmail.com; netdev@vger.kernel.org; Michal Smulski <michal.smulski@ooma.com> Subject: Re: [PATCH net-next v2] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x CAUTION: This email is originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Sun, May 28, 2023 at 11:25:22AM +0200, Marek Behún wrote: > You need also to implement serdes_pcs_get_state for USXGMII. > > Preferably by adding USXGMII relevant register constants into > include/uapi/linux/mii.h, and using them to parse state register. And if a standard is being followed here, please try to make the code as helpers, so other USXGMII implementations can use them. Thanks Andrew
On Mon, 29 May 2023 17:23:12 +0000 Michal Smulski <michal.smulski@ooma.com> wrote: > If I understand this correctly, you are asking to create a function for USXGMII similar to: > > static int mv88e6390_serdes_pcs_get_state_sgmii(struct mv88e6xxx_chip *chip, > int port, int lane, struct phylink_link_state *state) > > However, the datasheet for 88e6393x chips does not document any registers for USXGMII interface (as it does for SGMII). You can only see that 10G link is valid by looking at MV88E6390_10G_STAT1 & MDIO_STAT1_LSTATUS which has already been implemented in: > static int mv88e6390_serdes_pcs_get_state_10g(struct mv88e6xxx_chip *chip, > int port, int lane, struct phylink_link_state *state) > The datasheet states that in USXGMII mode the link is always set to 10GBASE-R coding for all data rates. > > From the logs, I see that that the link is configured using in-band information. However, there is no register access in MV88E6393x that would allow to either control or get status information (speed, duplex, flow control, auto-negotiation, etc). Most of "useful" registers are already defined in mv88e6xxx/serdes.h file. > > [ 50.624175] mv88e6085 0x0000000008b96000:02: configuring for inband/usxgmii link mode > ... > [ 387.116463] fsl_dpaa2_eth dpni.3 eth1: configuring for inband/usxgmii link mode > [ 387.132554] fsl_dpaa2_eth dpni.3 eth1: Link is Up - 10Gbps/Full - flow control off > > If I misunderstood what is requested, please give me a bit more information what I should be adding for this patch to be accepted. I know that 6393x does not document the USXGMII registers, but I bet there are there. Similar to how 88X3540 supports USXGMII but the registers are not documented. Do you have func spec for 88X3310 / 88X3340 ? Those two document some USXGMII registers, and the bits are the same as in this microsemi document https://www.microsemi.com/document-portal/doc_view/1245324-coreusxgmii-hb I don't acutally have access to Cisco's USXGMII specification, but I bet these register bits are same between vendors. Could you at least try to investigate this? Marek
I followed your suggestions and came up with version v3 as in my previous email. With that patch, I get a notice of link up in logs. [ 51.658898] mv88e6085 0x0000000008b96000:02: switch 0x1920 detected: Marvell 88E6191X, revision 0 [ 52.325920] mv88e6085 0x0000000008b96000:02: configuring for inband/usxgmii link mode [ 52.521309] mv88e6085 0x0000000008b96000:02: Link is Up - 10Gbps/Full - flow control off Michal -----Original Message----- From: Marek Behún <kabel@kernel.org> Sent: Tuesday, May 30, 2023 6:54 AM To: Michal Smulski <michal.smulski@ooma.com> Cc: Andrew Lunn <andrew@lunn.ch>; f.fainelli@gmail.com; olteanv@gmail.com; netdev@vger.kernel.org Subject: Re: [PATCH net-next v2] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x CAUTION: This email is originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, 29 May 2023 17:23:12 +0000 Michal Smulski <michal.smulski@ooma.com> wrote: > If I understand this correctly, you are asking to create a function for USXGMII similar to: > > static int mv88e6390_serdes_pcs_get_state_sgmii(struct mv88e6xxx_chip *chip, > int port, int lane, struct phylink_link_state *state) > > However, the datasheet for 88e6393x chips does not document any registers for USXGMII interface (as it does for SGMII). You can only see that 10G link is valid by looking at MV88E6390_10G_STAT1 & MDIO_STAT1_LSTATUS which has already been implemented in: > static int mv88e6390_serdes_pcs_get_state_10g(struct mv88e6xxx_chip *chip, > int port, int lane, struct phylink_link_state *state) The > datasheet states that in USXGMII mode the link is always set to 10GBASE-R coding for all data rates. > > From the logs, I see that that the link is configured using in-band information. However, there is no register access in MV88E6393x that would allow to either control or get status information (speed, duplex, flow control, auto-negotiation, etc). Most of "useful" registers are already defined in mv88e6xxx/serdes.h file. > > [ 50.624175] mv88e6085 0x0000000008b96000:02: configuring for inband/usxgmii link mode > ... > [ 387.116463] fsl_dpaa2_eth dpni.3 eth1: configuring for > inband/usxgmii link mode [ 387.132554] fsl_dpaa2_eth dpni.3 eth1: > Link is Up - 10Gbps/Full - flow control off > > If I misunderstood what is requested, please give me a bit more information what I should be adding for this patch to be accepted. I know that 6393x does not document the USXGMII registers, but I bet there are there. Similar to how 88X3540 supports USXGMII but the registers are not documented. Do you have func spec for 88X3310 / 88X3340 ? Those two document some USXGMII registers, and the bits are the same as in this microsemi document https://www.microsemi.com/document-portal/doc_view/1245324-coreusxgmii-hb I don't acutally have access to Cisco's USXGMII specification, but I bet these register bits are same between vendors. Could you at least try to investigate this? Marek
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 5bbe95fa951c..71cee154622f 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -806,8 +806,7 @@ static void mv88e6393x_phylink_get_caps(struct mv88e6xxx_chip *chip, int port, __set_bit(PHY_INTERFACE_MODE_2500BASEX, supported); __set_bit(PHY_INTERFACE_MODE_5GBASER, supported); __set_bit(PHY_INTERFACE_MODE_10GBASER, supported); - /* FIXME: USXGMII is not supported yet */ - /* __set_bit(PHY_INTERFACE_MODE_USXGMII, supported); */ + __set_bit(PHY_INTERFACE_MODE_USXGMII, supported); config->mac_capabilities |= MAC_2500FD | MAC_5000FD | MAC_10000FD; diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c index f79cf716c541..8daeeeb66880 100644 --- a/drivers/net/dsa/mv88e6xxx/port.c +++ b/drivers/net/dsa/mv88e6xxx/port.c @@ -554,6 +554,9 @@ static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port, case PHY_INTERFACE_MODE_10GBASER: cmode = MV88E6393X_PORT_STS_CMODE_10GBASER; break; + case PHY_INTERFACE_MODE_USXGMII: + cmode = MV88E6393X_PORT_STS_CMODE_USXGMII; + break; default: cmode = 0; } diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c index 72faec8f44dc..ae051d383c7e 100644 --- a/drivers/net/dsa/mv88e6xxx/serdes.c +++ b/drivers/net/dsa/mv88e6xxx/serdes.c @@ -683,7 +683,8 @@ int mv88e6393x_serdes_get_lane(struct mv88e6xxx_chip *chip, int port) cmode == MV88E6XXX_PORT_STS_CMODE_SGMII || cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX || cmode == MV88E6393X_PORT_STS_CMODE_5GBASER || - cmode == MV88E6393X_PORT_STS_CMODE_10GBASER) + cmode == MV88E6393X_PORT_STS_CMODE_10GBASER || + cmode == MV88E6393X_PORT_STS_CMODE_USXGMII) lane = port; return lane; @@ -1018,6 +1019,7 @@ int mv88e6393x_serdes_pcs_get_state(struct mv88e6xxx_chip *chip, int port, state); case PHY_INTERFACE_MODE_5GBASER: case PHY_INTERFACE_MODE_10GBASER: + case PHY_INTERFACE_MODE_USXGMII: return mv88e6393x_serdes_pcs_get_state_10g(chip, port, lane, state); @@ -1173,6 +1175,7 @@ int mv88e6393x_serdes_irq_enable(struct mv88e6xxx_chip *chip, int port, return mv88e6390_serdes_irq_enable_sgmii(chip, lane, enable); case MV88E6393X_PORT_STS_CMODE_5GBASER: case MV88E6393X_PORT_STS_CMODE_10GBASER: + case MV88E6393X_PORT_STS_CMODE_USXGMII: return mv88e6393x_serdes_irq_enable_10g(chip, lane, enable); } @@ -1213,6 +1216,7 @@ irqreturn_t mv88e6393x_serdes_irq_status(struct mv88e6xxx_chip *chip, int port, break; case MV88E6393X_PORT_STS_CMODE_5GBASER: case MV88E6393X_PORT_STS_CMODE_10GBASER: + case MV88E6393X_PORT_STS_CMODE_USXGMII: err = mv88e6393x_serdes_irq_status_10g(chip, lane, &status); if (err) return err; @@ -1477,7 +1481,8 @@ static int mv88e6393x_serdes_erratum_5_2(struct mv88e6xxx_chip *chip, int lane, * to SERDES operating in 10G mode. These registers only apply to 10G * operation and have no effect on other speeds. */ - if (cmode != MV88E6393X_PORT_STS_CMODE_10GBASER) + if (cmode != MV88E6393X_PORT_STS_CMODE_10GBASER && + cmode != MV88E6393X_PORT_STS_CMODE_USXGMII) return 0; for (i = 0; i < ARRAY_SIZE(fixes); ++i) { @@ -1582,6 +1587,7 @@ int mv88e6393x_serdes_power(struct mv88e6xxx_chip *chip, int port, int lane, break; case MV88E6393X_PORT_STS_CMODE_5GBASER: case MV88E6393X_PORT_STS_CMODE_10GBASER: + case MV88E6393X_PORT_STS_CMODE_USXGMII: err = mv88e6390_serdes_power_10g(chip, lane, on); break; default:
Enable USXGMII mode for mv88e6393x chips. Tested on Marvell 88E6191X. Signed-off-by: Michal Smulski <michal.smulski@ooma.com> --- drivers/net/dsa/mv88e6xxx/chip.c | 3 +-- drivers/net/dsa/mv88e6xxx/port.c | 3 +++ drivers/net/dsa/mv88e6xxx/serdes.c | 10 ++++++++-- 3 files changed, 12 insertions(+), 4 deletions(-)