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.
next prev parent 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