linux-kernel - Re: [PATCH 2/2] net: dsa: qca8k: Improve SGMII interface handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Jun 2020 18:47:12 +0100
From:   Jonathan McDowell <noodles@...th.li>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] net: dsa: qca8k: Improve SGMII interface handling

On Wed, Jun 10, 2020 at 08:31:11PM -0700, Florian Fainelli wrote:
> On 6/10/2020 12:15 PM, Jonathan McDowell wrote:
> > This patch improves the handling of the SGMII interface on the QCA8K
> > devices. Previously the driver did no configuration of the port, even if
> > it was selected. We now configure it up in the appropriate
> > PHY/MAC/Base-X mode depending on what phylink tells us we are connected
> > to and ensure it is enabled.
> > 
> > Tested with a device where the CPU connection is RGMII (i.e. the common
> > current use case) + one where the CPU connection is SGMII. I don't have
> > any devices where the SGMII interface is brought out to something other
> > than the CPU.
> > 
> > Signed-off-by: Jonathan McDowell <noodles@...th.li>
> > ---
> >  drivers/net/dsa/qca8k.c | 28 +++++++++++++++++++++++++++-
> >  drivers/net/dsa/qca8k.h | 13 +++++++++++++
> >  2 files changed, 40 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
> > index dcd9e8fa99b6..33e62598289e 100644
> > --- a/drivers/net/dsa/qca8k.c
> > +++ b/drivers/net/dsa/qca8k.c
> > @@ -681,7 +681,7 @@ qca8k_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode,
> >  			 const struct phylink_link_state *state)
> >  {
> >  	struct qca8k_priv *priv = ds->priv;
> > -	u32 reg;
> > +	u32 reg, val;
> >  
> >  	switch (port) {
> >  	case 0: /* 1st CPU port */
> > @@ -740,6 +740,32 @@ qca8k_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode,
> >  	case PHY_INTERFACE_MODE_1000BASEX:
> >  		/* Enable SGMII on the port */
> >  		qca8k_write(priv, reg, QCA8K_PORT_PAD_SGMII_EN);
> > +
> > +		/* Enable/disable SerDes auto-negotiation as necessary */
> > +		val = qca8k_read(priv, QCA8K_REG_PWS);
> > +		if (phylink_autoneg_inband(mode))
> > +			val &= ~QCA8K_PWS_SERDES_AEN_DIS;
> > +		else
> > +			val |= QCA8K_PWS_SERDES_AEN_DIS;
> > +		qca8k_write(priv, QCA8K_REG_PWS, val);
> > +
> > +		/* Configure the SGMII parameters */
> > +		val = qca8k_read(priv, QCA8K_REG_SGMII_CTRL);
> > +
> > +		val |= QCA8K_SGMII_EN_PLL | QCA8K_SGMII_EN_RX |
> > +			QCA8K_SGMII_EN_TX | QCA8K_SGMII_EN_SD;
> > +
> > +		val &= ~QCA8K_SGMII_MODE_CTRL_MASK;
> > +		if (dsa_is_cpu_port(ds, port)) {
> > +			/* CPU port, we're talking to the CPU MAC, be a PHY */
> > +			val |= QCA8K_SGMII_MODE_CTRL_PHY;
> 
> Since port 6 can be interfaced to an external PHY, do not you have to
> differentiate here whether this port is connected to an actual PHY,
> versus connected to a MAC? You should be able to use mode == MLO_AN_PHY
> to differentiate that case from the others.

I don't think MLO_AN_PHY is sufficient? If it's a fixed link we'll have
MLO_AN_FIXED and that could be talking to a PHY?

The logic I've gone for is assuming that a port hooked up to the CPU
should look like a PHY, and otherwise we're hooked up to a PHY so we're
acting as a MAC. That means we don't cope with the situation that we're
hooked up to something that isn't the CPU but wants us to look like a
PHY, but I don't think we have any current way to describe that.

> > +		} else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
> > +			val |= QCA8K_SGMII_MODE_CTRL_MAC;
> > +		} else {
> > +			val |= QCA8K_SGMII_MODE_CTRL_BASEX;
> 
> Better make this explicit and check for PHY_INTERFACE_MODE_1000BASEX,
> even if those are the only two possible values covered by this part of
> the case statement.

Sure. I'll move the mask inside the if block too in that case, so we
don't change the setting if we get fed something invalid.

J.

-- 
Beware of programmers carrying screwdrivers.