netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: "Marek Behún" <kabel@kernel.org>
Cc: netdev@vger.kernel.org, pavana.sharma@digi.com,
	vivien.didelot@gmail.com, f.fainelli@gmail.com, kuba@kernel.org,
	lkp@intel.com, davem@davemloft.net, ashkan.boldaji@digi.com,
	andrew@lunn.ch, Chris Packham <chris.packham@alliedtelesis.co.nz>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>
Subject: Re: [PATCH net-next v14 5/6] net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell
Date: Tue, 12 Jan 2021 13:11:39 +0200	[thread overview]
Message-ID: <20210112111139.hp56x5nzgadqlthw@skbuf> (raw)
In-Reply-To: <20210111012156.27799-6-kabel@kernel.org>

On Mon, Jan 11, 2021 at 02:21:55AM +0100, Marek Behún wrote:
> From: Pavana Sharma <pavana.sharma@digi.com>
> 
> The Marvell 88E6393X device is a single-chip integration of a 11-port
> Ethernet switch with eight integrated Gigabit Ethernet (GbE)
> transceivers and three 10-Gigabit interfaces.
> 
> This patch adds functionalities specific to mv88e6393x family (88E6393X,
> 88E6193X and 88E6191X).
> 
> The main differences between previous devices and this one are:
> - port 0 can be a SERDES port
> - all SERDESes are one-lane, eg. no XAUI nor RXAUI
> - on the other hand the SERDESes can do USXGMII, 10GBASER and 5GBASER
>   (on 6191X only one SERDES is capable of more than 1g; USXGMII is not
>   yet supported with this change)
> - Port Policy CTL register is changed to Port Policy MGMT CTL register,
>   via which serveral more registers can be accessed indirectly
              ~~~~~~~~
              several
> - egress monitor port is configured differently
> - ingress monitor/CPU/mirror ports are configured differently and can be
>   configured per port (ie. each port can have different ingress monitor
>   port, for example)
> - port speed AltBit works differently than previously
> - PHY registers can be also accessed via MDIO address 0x18 and 0x19
>   (on previous devices they could be accessed only via Global 2 offsets
>    0x18 and 0x19, which means two indirections; this feature is not yet
>    leveraged with this patch)
> 
> Co-developed-by: Ashkan Boldaji <ashkan.boldaji@digi.com>
> Signed-off-by: Ashkan Boldaji <ashkan.boldaji@digi.com>
> Signed-off-by: Pavana Sharma <pavana.sharma@digi.com>
> Co-developed-by: Marek Behún <kabel@kernel.org>
> Signed-off-by: Marek Behún <kabel@kernel.org>
> ---
> +static void mv88e6393x_phylink_validate(struct mv88e6xxx_chip *chip, int port,
> +					unsigned long *mask,
> +					struct phylink_link_state *state)
> +{
> +	if (port == 0 || port == 9 || port == 10) {
> +		phylink_set(mask, 10000baseT_Full);
> +		phylink_set(mask, 10000baseKR_Full);

I think I understand the reason for declaring 10GBase-KR support in
phylink_validate, in case the PHY supports that link mode on the media
side, but...

> +		phylink_set(mask, 10000baseCR_Full);
> +		phylink_set(mask, 10000baseSR_Full);
> +		phylink_set(mask, 10000baseLR_Full);
> +		phylink_set(mask, 10000baseLRM_Full);
> +		phylink_set(mask, 10000baseER_Full);
> +		phylink_set(mask, 5000baseT_Full);
> +		phylink_set(mask, 2500baseX_Full);
> +		phylink_set(mask, 2500baseT_Full);
> +	}
> +
> +	phylink_set(mask, 1000baseT_Full);
> +	phylink_set(mask, 1000baseX_Full);
> +
> +	mv88e6065_phylink_validate(chip, port, mask, state);
> +}
> +
> @@ -450,6 +559,9 @@ static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
>  	case PHY_INTERFACE_MODE_2500BASEX:
>  		cmode = MV88E6XXX_PORT_STS_CMODE_2500BASEX;
>  		break;
> +	case PHY_INTERFACE_MODE_5GBASER:
> +		cmode = MV88E6393X_PORT_STS_CMODE_5GBASER;
> +		break;
>  	case PHY_INTERFACE_MODE_XGMII:
>  	case PHY_INTERFACE_MODE_XAUI:
>  		cmode = MV88E6XXX_PORT_STS_CMODE_XAUI;
> @@ -457,6 +569,10 @@ static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
>  	case PHY_INTERFACE_MODE_RXAUI:
>  		cmode = MV88E6XXX_PORT_STS_CMODE_RXAUI;
>  		break;
> +	case PHY_INTERFACE_MODE_10GBASER:
> +	case PHY_INTERFACE_MODE_10GKR:

Does the SERDES actually support 10GBase-KR (aka 10GBase-R for copper
backplanes)? It is different than plain 10GBase-R (abusingly called XFI)
by the need of a link training procedure to negotiate SERDES eye
parameters. There have been discussion in the past where it turned out
that drivers which didn't really support 10GBase-KR incorrectly reported
that they did.

> +		cmode = MV88E6393X_PORT_STS_CMODE_10GBASER;
> +		break;
>  	default:
>  		cmode = 0;
>  	}
> @@ -541,6 +657,29 @@ int mv88e6390_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
>  	return mv88e6xxx_port_set_cmode(chip, port, mode, false);
>  }
>  
> +int mv88e6393x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
> +			      phy_interface_t mode)
> +{
> +	int err;
> +	u16 reg;
> +
> +	if (port != 0 && port != 9 && port != 10)
> +		return -EOPNOTSUPP;
> +
> +	/* mv88e6393x errata 4.5: EEE should be disabled on SERDES ports */
> +	err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_MAC_CTL, &reg);
> +	if (err)
> +		return err;
> +
> +	reg &= ~MV88E6XXX_PORT_MAC_CTL_EEE;
> +	reg |= MV88E6XXX_PORT_MAC_CTL_FORCE_EEE;
> +	err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_MAC_CTL, reg);
> +	if (err)
> +		return err;
> +
> +	return mv88e6xxx_port_set_cmode(chip, port, mode, false);
> +}
> +
>  static int mv88e6341_port_set_cmode_writable(struct mv88e6xxx_chip *chip,
>  					     int port)
>  {
> @@ -1164,6 +1303,135 @@ int mv88e6xxx_port_disable_pri_override(struct mv88e6xxx_chip *chip, int port)
>  	return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_PRI_OVERRIDE, 0);
>  }
>  
> +/* Offset 0x0E: Policy & MGMT Control Register for FAMILY 6191X 6193X 6393X */
> +
> +static int mv88e6393x_port_policy_write(struct mv88e6xxx_chip *chip, int port,
> +					u16 pointer, u8 data)
> +{
> +	u16 reg;
> +
> +	reg = MV88E6393X_PORT_POLICY_MGMT_CTL_UPDATE | pointer | data;

I think the assignment fits on the same line as the declaration?

> +
> +	return mv88e6xxx_port_write(chip, port, MV88E6393X_PORT_POLICY_MGMT_CTL,
> +				    reg);
> +}
> +
> +int mv88e6393x_serdes_setup_errata(struct mv88e6xxx_chip *chip)
> +{
> +	int err;
> +
> +	err = mv88e6393x_serdes_port_errata(chip, MV88E6393X_PORT0_LANE);
> +	if (err)
> +		return err;
> +
> +	err = mv88e6393x_serdes_port_errata(chip, MV88E6393X_PORT9_LANE);
> +	if (err)
> +		return err;
> +
> +	return mv88e6393x_serdes_port_errata(chip, MV88E6393X_PORT10_LANE);
> +}
> +
> +static int mv88e6393x_serdes_port_config(struct mv88e6xxx_chip *chip, int lane,
> +					 bool on)
> +{
> +	u8 cmode = chip->ports[lane].cmode;
> +	u16 reg, pcs;
> +	int err;
> +
> +	if (on) {

And if "on" is false? Nothing? Why even pass it as an argument then? Why
even call mv88e6393x_serdes_port_config?

> +		switch (cmode) {
> +		case MV88E6XXX_PORT_STS_CMODE_SGMII:
> +			pcs = MV88E6393X_PCS_SELECT_SGMII_MAC;
> +			break;
> +		case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
> +			pcs = MV88E6393X_PCS_SELECT_1000BASEX;
> +			break;
> +		case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
> +			pcs = MV88E6393X_PCS_SELECT_2500BASEX;
> +			break;
> +		case MV88E6393X_PORT_STS_CMODE_5GBASER:
> +			pcs = MV88E6393X_PCS_SELECT_5GBASER;
> +			break;
> +		case MV88E6393X_PORT_STS_CMODE_10GBASER:
> +			pcs = MV88E6393X_PCS_SELECT_10GBASER;
> +			break;
> +		default:
> +			pcs = MV88E6393X_PCS_SELECT_1000BASEX;
> +			break;
> +		}
> +
> +		/* mv88e6393x family errata 3.6 :
> +		 * When changing c_mode on Port 0 from [x]MII mode to any
> +		 * SERDES mode SERDES will not be operational.
> +		 * Workaround: Set Port0 SERDES register 4.F002.5=0
> +		 */
> +		err = mv88e6390_serdes_read(chip, lane, MDIO_MMD_PHYXS,
> +					    MV88E6393X_SERDES_POC, &reg);
> +		if (err)
> +			return err;
> +
> +		reg &= ~(MV88E6393X_SERDES_POC_PCS_MODE_MASK |
> +			 MV88E6393X_SERDES_POC_PDOWN);
> +		reg |= pcs;
> +
> +		err = mv88e6390_serdes_write(chip, lane, MDIO_MMD_PHYXS,
> +					     MV88E6393X_SERDES_POC, reg);
> +		if (err)
> +			return err;
> +
> +		reg |= MV88E6393X_SERDES_POC_RESET;
> +		err = mv88e6390_serdes_write(chip, lane, MDIO_MMD_PHYXS,
> +					     MV88E6393X_SERDES_POC, reg);
> +		if (err)
> +			return err;
> +
> +		/* mv88e6393x family errata 3.7 :
> +		 * When changing cmode on SERDES port from any other mode to
> +		 * 1000BASE-X mode the link may not come up due to invalid
> +		 * 1000BASE-X advertisement.
> +		 * Workaround: Correct advertisement and reset PHY core.
> +		 */
> +		if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASEX) {
> +			reg = MV88E6390_SGMII_ANAR_1000BASEX_FD;
> +			err = mv88e6390_serdes_write(chip, lane, MDIO_MMD_PHYXS,
> +						     MV88E6390_SGMII_ANAR, reg);
> +			if (err)
> +				return err;
> +
> +			/* soft reset the PCS/PMA */
> +			err = mv88e6390_serdes_read(chip, lane, MDIO_MMD_PHYXS,
> +						    MV88E6390_SGMII_CONTROL,
> +						    &reg);
> +			if (err)
> +				return err;
> +
> +			reg |= MV88E6390_SGMII_CONTROL_RESET;
> +			err = mv88e6390_serdes_write(chip, lane, MDIO_MMD_PHYXS,
> +						     MV88E6390_SGMII_CONTROL,
> +						     reg);
> +			if (err)
> +				return err;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +int mv88e6393x_serdes_power(struct mv88e6xxx_chip *chip, int port, int lane,
> +			    bool on)
> +{
> +	u8 cmode = chip->ports[port].cmode;
> +
> +	if (port != 0 && port != 9 && port != 10)
> +		return -EOPNOTSUPP;
> +
> +	mv88e6393x_serdes_port_config(chip, lane, on);
> +
> +	switch (cmode) {
> +	case MV88E6XXX_PORT_STS_CMODE_SGMII:
> +	case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
> +	case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
> +		return mv88e6390_serdes_power_sgmii(chip, lane, on);
> +	case MV88E6393X_PORT_STS_CMODE_5GBASER:
> +	case MV88E6393X_PORT_STS_CMODE_10GBASER:
> +		return mv88e6390_serdes_power_10g(chip, lane, on);
> +	}
> +
> +	return 0;
> +}

  reply	other threads:[~2021-01-12 11:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11  1:21 [PATCH net-next v14 0/6] Add support for mv88e6393x family of Marvell Marek Behún
2021-01-11  1:21 ` [PATCH net-next v14 1/6] dt-bindings: net: Add 5GBASER phy interface Marek Behún
2021-01-11 16:41   ` Andrew Lunn
2021-01-11  1:21 ` [PATCH net-next v14 2/6] net: phy: Add 5GBASER interface mode Marek Behún
2021-01-11 16:48   ` Russell King - ARM Linux admin
2021-01-11 17:49     ` Marek Behún
2021-01-11  1:21 ` [PATCH net-next v14 3/6] net: dsa: mv88e6xxx: Change serdes lane parameter type from u8 type to int Marek Behún
2021-01-12 10:53   ` Vladimir Oltean
2021-01-11  1:21 ` [PATCH net-next v14 4/6] net: dsa: mv88e6xxx: wrap .set_egress_port method Marek Behún
2021-01-11  5:57   ` Pavana Sharma
2021-01-12 10:53   ` Vladimir Oltean
2021-01-11  1:21 ` [PATCH net-next v14 5/6] net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell Marek Behún
2021-01-12 11:11   ` Vladimir Oltean [this message]
2021-01-12 16:02     ` Marek Behún
2021-01-12 16:29       ` Russell King - ARM Linux admin
2021-01-12 16:37         ` Marek Behún
2021-01-12 18:06         ` Marek Behún
2021-01-12 21:58           ` Vladimir Oltean
2021-01-13  3:56             ` Marek Behún
2021-01-11  1:21 ` [PATCH net-next v14 6/6] net: dsa: mv88e6xxx: implement .port_set_policy for Amethyst Marek Behún
2021-01-11  6:00   ` Pavana Sharma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210112111139.hp56x5nzgadqlthw@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=ashkan.boldaji@digi.com \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kabel@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lkp@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pavana.sharma@digi.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).