Netdev List
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Frank Wunderlich <frank-w@public-files.de>
Cc: "Arınç ÜNAL" <arinc.unal@arinc9.com>,
	netdev <netdev@vger.kernel.org>,
	erkin.bozoglu@xeront.com, "Andrew Lunn" <andrew@lunn.ch>,
	"Florian Fainelli" <f.fainelli@gmail.com>
Subject: Re: Choose a default DSA CPU port
Date: Tue, 21 Feb 2023 02:27:13 +0200	[thread overview]
Message-ID: <20230221002713.qdsabxy7y74jpbm4@skbuf> (raw)
In-Reply-To: <trinity-4025f060-3bb8-4260-99b7-e25cbdcf9c27-1676800164589@3c-app-gmx-bs35>

On Sun, Feb 19, 2023 at 10:49:24AM +0100, Frank Wunderlich wrote:
> > I'm leaving this to Frank to explain.
> 
> yes only looking at phy speed may not be the right way, but one way...i would like the hw driver
> choose the right port which is used as default.
> 
> currently i try to figure out why dsa_tree_setup_cpu_ports does not use dsa_tree_find_first_cpu.
> the loops looks same, first returns the first one, second skips all further which should be same
> and at the end it calls dsa_tree_find_first_cpu for all ports not yet having a cpu-port assigned...

Because by the time dsa_tree_find_first_cpu() has been called, all user
and cascade ports got their dp->cpu_dp pointers resolved by the earlier
logic, which prefers a CPU port local to that switch before assigning
CPU ports which are potentially on remote switches.

> looks starnge to me, but maybe i oversee a detail.

Yeah, at least one.

> does not yet compile because i do not know how to get dsa_switch from dsa_switch_tree,
> but basicly shows how i would do it (select the right cpu at driver level without dts properties).

Basically what you want is something like this:

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 3a15015bc409..c4771a848319 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -393,6 +393,20 @@ mt7530_fdb_write(struct mt7530_priv *priv, u16 vid,
 		mt7530_write(priv, MT7530_ATA1 + (i * 4), reg[i]);
 }
 
+/* If port 6 is available as a CPU port, always prefer that as the default,
+ * otherwise don't care.
+ */
+static struct dsa_port *
+mt7530_preferred_default_local_cpu_port(struct dsa_switch *ds)
+{
+	struct dsa_port *cpu_dp = dsa_to_port(ds, 6);
+
+	if (dsa_port_is_cpu(cpu_dp))
+		return cpu_dp;
+
+	return NULL;
+}
+
 /* Setup TX circuit including relevant PAD and driving */
 static int
 mt7530_pad_clk_setup(struct dsa_switch *ds, phy_interface_t interface)
@@ -3152,6 +3166,7 @@ static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
 static const struct dsa_switch_ops mt7530_switch_ops = {
 	.get_tag_protocol	= mtk_get_tag_protocol,
 	.setup			= mt753x_setup,
+	.preferred_default_local_cpu_port = mt7530_preferred_default_local_cpu_port,
 	.get_strings		= mt7530_get_strings,
 	.get_ethtool_stats	= mt7530_get_ethtool_stats,
 	.get_sset_count		= mt7530_get_sset_count,
diff --git a/include/net/dsa.h b/include/net/dsa.h
index a15f17a38eca..5db43be2a464 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -973,6 +973,14 @@ struct dsa_switch_ops {
 			       struct phy_device *phy);
 	void	(*port_disable)(struct dsa_switch *ds, int port);
 
+	/*
+	 * Compatibility between device trees defining multiple CPU ports and
+	 * drivers which are not ok to use by default the numerically first CPU
+	 * port of a switch for its local ports. This can return NULL, meaning
+	 * "don't know/don't care".
+	 */
+	struct dsa_port *(*preferred_default_local_cpu_port)(struct dsa_switch *ds);
+
 	/*
 	 * Port's MAC EEE settings
 	 */
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index e5f156940c67..6cd8607a3928 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -402,6 +402,24 @@ static int dsa_tree_setup_default_cpu(struct dsa_switch_tree *dst)
 	return 0;
 }
 
+static struct dsa_port *
+dsa_switch_preferred_default_local_cpu_port(struct dsa_switch *ds)
+{
+	struct dsa_port *cpu_dp;
+
+	if (!ds->ops->preferred_default_local_cpu_port)
+		return NULL;
+
+	cpu_dp = ds->ops->preferred_default_local_cpu_port(ds);
+	if (!cpu_dp)
+		return NULL;
+
+	if (WARN_ON(!dsa_port_is_cpu(cpu_dp) || cpu_dp->ds != ds))
+		return NULL;
+
+	return cpu_dp;
+}
+
 /* Perform initial assignment of CPU ports to user ports and DSA links in the
  * fabric, giving preference to CPU ports local to each switch. Default to
  * using the first CPU port in the switch tree if the port does not have a CPU
@@ -409,12 +427,16 @@ static int dsa_tree_setup_default_cpu(struct dsa_switch_tree *dst)
  */
 static int dsa_tree_setup_cpu_ports(struct dsa_switch_tree *dst)
 {
-	struct dsa_port *cpu_dp, *dp;
+	struct dsa_port *preferred_cpu_dp, *cpu_dp, *dp;
 
 	list_for_each_entry(cpu_dp, &dst->ports, list) {
 		if (!dsa_port_is_cpu(cpu_dp))
 			continue;
 
+		preferred_cpu_dp = dsa_switch_preferred_default_local_cpu_port(cpu_dp->ds);
+		if (preferred_cpu_dp && preferred_cpu_dp != cpu_dp)
+			continue;
+
 		/* Prefer a local CPU port */
 		dsa_switch_for_each_port(dp, cpu_dp->ds) {
 			/* Prefer the first local CPU port found */

> imho there is no way to ensure both ways backwards compatible..

if you say so... can't argue with that

> in the moment you add port5 it will be the default cpu-port which is
> what we try to "fix" here. either driver should select the better one
> (drivercode not backported if no real fix) or it needs a setting in
> dts (which is not read in older driver/core).

If changes to driver code to resolve a device tree compatibility issue
are not treated as stable-worthy bug fixes, then the implication is that
the whole thing with device tree as stable ABI is just a moronic and
pointless effort.

Have you ever tried fixing some kind of issue similar to this and gotten
adverse feedback?

There are 2 ways of addressing the compatibility issue for stable
kernels. Either port 6 always gets preferred over port 5, or the patches
which make port 5 work as a CPU port are resubmitted as stable material.
I was hoping you'd be able to bring an argument why preferring port 6
would unconditionally be a better choice than working with the first
port that's given: $insert_reason_here.

  reply	other threads:[~2023-02-21  0:27 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18 17:07 Choose a default DSA CPU port 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 [this message]
2023-02-22 17:17         ` 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-24 18:31                       ` Aw: " Frank Wunderlich
2023-02-22 19:39           ` Vladimir Oltean
  -- strict thread matches above, loose matches on Subject: below --
2023-02-24 20:44 Aw: " Frank Wunderlich
2023-02-24 21:08 ` Vladimir Oltean
2023-02-25 13:50   ` Aw: " 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 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
2023-05-19  9:00                         ` Arınç ÜNAL
2023-05-19 23:54                           ` 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=20230221002713.qdsabxy7y74jpbm4@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=arinc.unal@arinc9.com \
    --cc=erkin.bozoglu@xeront.com \
    --cc=f.fainelli@gmail.com \
    --cc=frank-w@public-files.de \
    --cc=netdev@vger.kernel.org \
    /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