netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>
Cc: Frank Wunderlich <frank-w@public-files.de>,
	Felix Fietkau <nbd@nbd.name>, netdev <netdev@vger.kernel.org>,
	erkin.bozoglu@xeront.com, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	John Crispin <john@phrozen.org>,
	Mark Lee <Mark-MC.Lee@mediatek.com>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	Sean Wang <sean.wang@mediatek.com>,
	DENG Qingfang <dqfext@gmail.com>,
	mithat.guner@xeront.com
Subject: Re: Choose a default DSA CPU port
Date: Thu, 18 May 2023 17:24:22 +0300	[thread overview]
Message-ID: <20230518142422.62hm5d4orvy7nroz@skbuf> (raw)
In-Reply-To: <d2236430-0303-b74c-2b35-99bef4ac30a1@arinc9.com> <d2236430-0303-b74c-2b35-99bef4ac30a1@arinc9.com>

On Thu, May 18, 2023 at 01:36:42PM +0300, Arınç ÜNAL wrote:
> The frames won't necessarily be trapped to the CPU port the user port is
> connected to. This operation is only there to make sure the trapped frames
> always reach the CPU.

That's kind of understated and I don't regard that as that big of a deal.
Since control packets cannot be guaranteed to be processed by the
conduit interface affine to the user port, I would go one step further
and say: don't even attempt to keep an affinity, just use for that purpose
the numerically first conduit interface that is up.

> I don't (know how to) check for other conduits being up when changing the
> trap port. So if a conduit is set down which results in both conduits being
> down, the trap port will still be changed to the other port which is
> unnecessary but it doesn't break anything.
> 
> Looking forward to your comments.
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index b5c8fdd381e5..55c11633f96f 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -961,11 +961,6 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
>  	mt7530_set(priv, MT753X_MFC, MT753X_BC_FFP(BIT(port)) |
>  		   MT753X_UNM_FFP(BIT(port)) | MT753X_UNU_FFP(BIT(port)));
> -	/* Set CPU port number */
> -	if (priv->id == ID_MT7621)
> -		mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_MASK, MT7530_CPU_EN |
> -			   MT7530_CPU_PORT(port));
> -
>  	/* Add the CPU port to the CPU port bitmap for MT7531 and switch on
>  	 * MT7988 SoC. Any frames set for trapping to CPU port will be trapped
>  	 * to the CPU port the user port is connected to.
> @@ -2258,6 +2253,10 @@ mt7530_setup(struct dsa_switch *ds)
>  			   PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
>  	}
> +	/* Trap BPDUs to the CPU port */
> +	mt7530_rmw(priv, MT753X_BPC, MT753X_BPDU_PORT_FW_MASK,
> +		   MT753X_BPDU_CPU_ONLY);
> +

This part will need its own patch + explanation
.
>  	/* Setup VLAN ID 0 for VLAN-unaware bridges */
>  	ret = mt7530_setup_vlan0(priv);
>  	if (ret)
> @@ -2886,6 +2885,50 @@ static const struct phylink_pcs_ops mt7530_pcs_ops = {
>  	.pcs_an_restart = mt7530_pcs_an_restart,
>  };
> +static void
> +mt753x_master_state_change(struct dsa_switch *ds,
> +			   const struct net_device *master,
> +			   bool operational)
> +{
> +	struct mt7530_priv *priv = ds->priv;
> +	struct dsa_port *cpu_dp = master->dsa_ptr;
> +	unsigned int trap_port;
> +
> +	/* Set the CPU port to trap frames to for MT7530. There can be only one
> +	 * CPU port due to MT7530_CPU_PORT having only 3 bits. Any frames set
> +	 * for trapping to CPU port will be trapped to the CPU port connected to
> +	 * the most recently set up DSA conduit. If the most recently set up DSA
> +	 * conduit is set down, frames will be trapped to the CPU port connected
> +	 * to the other DSA conduit.
> +	 */
> +	if (priv->id == ID_MT7530 || priv->id == ID_MT7621) {

Just return early which saves one level of indentation.

	if (priv->id != ID_MT7530 && priv->id != ID_MT7621)
		return;

> +		trap_port = (mt7530_read(priv, MT753X_MFC) & MT7530_CPU_PORT_MASK) >> 4;
> +		dev_info(priv->dev, "trap_port is %d\n", trap_port);
> +		if (operational) {
> +			dev_info(priv->dev, "the conduit for cpu port %d is up\n", cpu_dp->index);
> +
> +			/* This check will be unnecessary if we find a way to
> +			 * not change the trap port to the other port when a
> +			 * conduit is set down which results in both conduits
> +			 * being down.
> +			 */
> +			if (!(cpu_dp->index == trap_port)) {
> +				dev_info(priv->dev, "trap to cpu port %d\n", cpu_dp->index);
> +				mt7530_set(priv, MT753X_MFC, MT7530_CPU_EN);
> +				mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_PORT_MASK, MT7530_CPU_PORT(cpu_dp->index));
> +			}
> +		} else {
> +			if (cpu_dp->index == 5 && trap_port == 5) {
> +				dev_info(priv->dev, "the conduit for cpu port 5 is down, trap frames to port 6\n");
> +				mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_PORT_MASK, MT7530_CPU_PORT(6));
> +			} else if (cpu_dp->index == 6 && trap_port == 6) {
> +				dev_info(priv->dev, "the conduit for cpu port 6 is down, trap frames to port 5\n");
> +				mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_PORT_MASK, MT7530_CPU_PORT(5));
> +			}
> +		}

I believe that the implementation where you cache the "operational"
value of previous calls will be cleaner. Something like this (written in
an email client, so take it with a grain of salt):

struct mt7530_priv {
	unsigned long active_cpu_ports;
	...
};

	if (operational)
		priv->active_cpu_ports |= BIT(cpu_dp->index);
	else
		priv->active_cpu_ports &= ~BIT(cpu_dp->index);

	if (priv->active_cpu_ports) {
		mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_EN | MT7530_CPU_PORT_MASK,
			   MT7530_CPU_EN |
			   MT7530_CPU_PORT(__ffs(priv->active_cpu_ports)));
	} else {
		mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_EN | MT7530_CPU_PORT_MASK,
			   MT7530_CPU_PORT(0));
	}

> +	}
> +}
> +
>  static int
>  mt753x_setup(struct dsa_switch *ds)
>  {
> @@ -2999,6 +3042,7 @@ const struct dsa_switch_ops mt7530_switch_ops = {
>  	.phylink_mac_link_up	= mt753x_phylink_mac_link_up,
>  	.get_mac_eee		= mt753x_get_mac_eee,
>  	.set_mac_eee		= mt753x_set_mac_eee,
> +	.master_state_change	= mt753x_master_state_change,
>  };
>  EXPORT_SYMBOL_GPL(mt7530_switch_ops);
> diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
> index fd2a2f726b8a..2abd3c5ce05a 100644
> --- a/drivers/net/dsa/mt7530.h
> +++ b/drivers/net/dsa/mt7530.h
> @@ -41,8 +41,8 @@ enum mt753x_id {
>  #define  MT753X_UNU_FFP(x)		(((x) & 0xff) << 8)
>  #define  MT753X_UNU_FFP_MASK		MT753X_UNU_FFP(~0)
>  #define  MT7530_CPU_EN			BIT(7)
> -#define  MT7530_CPU_PORT(x)		((x) << 4)
> -#define  MT7530_CPU_MASK		(0xf << 4)
> +#define  MT7530_CPU_PORT(x)		(((x) & 0x7) << 4)
> +#define  MT7530_CPU_PORT_MASK		MT7530_CPU_PORT(~0)
>  #define  MT7530_MIRROR_EN		BIT(3)
>  #define  MT7530_MIRROR_PORT(x)		((x) & 0x7)
>  #define  MT7530_MIRROR_MASK		0x7
> 
> Arınç


  reply	other threads:[~2023-05-18 14:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 20:44 Aw: Re: Choose a default DSA CPU port Frank Wunderlich
2023-02-24 21:08 ` Vladimir Oltean
2023-02-25 11:14   ` Aw: " Frank Wunderlich
2023-02-25 13:50   ` Frank Wunderlich
2023-02-25 16:11     ` Arınç ÜNAL
2023-02-25 19:56       ` Arınç ÜNAL
2023-02-26 12:12         ` Aw: " Frank Wunderlich
2023-02-28  9:54           ` Arınç ÜNAL
2023-02-28 11:58           ` Vladimir Oltean
2023-02-28 13:48             ` Frank Wunderlich
2023-02-28 22:56               ` Vladimir Oltean
2023-03-01  6:38                 ` Frank Wunderlich
2023-03-01 12:37                   ` Vladimir Oltean
2023-03-06 18:20                     ` Aw: " Frank Wunderlich
2023-03-07 17:43                       ` Vladimir Oltean
2023-04-13 18:09                         ` Aw: " Frank Wunderlich
2023-04-13 21:30                           ` Frank Wunderlich
2023-05-16 19:29             ` Arınç ÜNAL
2023-05-17 16:10               ` Vladimir Oltean
2023-05-17 16:14                 ` Arınç ÜNAL
2023-05-17 16:16                   ` Vladimir Oltean
2023-05-18 10:36                     ` Arınç ÜNAL
2023-05-18 14:24                       ` Vladimir Oltean [this message]
2023-05-19  9:00                         ` Arınç ÜNAL
2023-05-19 23:54                           ` Vladimir Oltean
  -- strict thread matches above, loose matches on Subject: below --
2023-02-18 17:07 Arınç ÜNAL
2023-02-18 20:17 ` Frank Wunderlich
2023-02-18 20:17 ` Florian Fainelli
2023-02-18 20:52 ` Vladimir Oltean
2023-02-19  7:35   ` Arınç ÜNAL
2023-02-19  9:49     ` Aw: " Frank Wunderlich
2023-02-21  0:27       ` Vladimir Oltean
2023-02-22 17:17         ` Aw: " Frank Wunderlich
2023-02-22 18:06           ` Vladimir Oltean
2023-02-22 18:08             ` Arınç ÜNAL
2023-02-22 19:34               ` Vladimir Oltean
2023-02-22 19:42                 ` Arınç ÜNAL
2023-02-24 18:07                   ` Aw: " Frank Wunderlich
2023-02-24 18:13                     ` Vladimir Oltean
2023-02-24 18:16                       ` Vladimir Oltean
2023-02-22 19:39           ` Vladimir Oltean

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=20230518142422.62hm5d4orvy7nroz@skbuf \
    --to=olteanv@gmail.com \
    --cc=Landen.Chao@mediatek.com \
    --cc=Mark-MC.Lee@mediatek.com \
    --cc=andrew@lunn.ch \
    --cc=arinc.unal@arinc9.com \
    --cc=dqfext@gmail.com \
    --cc=erkin.bozoglu@xeront.com \
    --cc=f.fainelli@gmail.com \
    --cc=frank-w@public-files.de \
    --cc=john@phrozen.org \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mithat.guner@xeront.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=sean.wang@mediatek.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).