From: Vladimir Oltean <olteanv@gmail.com>
To: Mattias Forsblad <mattias.forsblad@gmail.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH net-next v2 2/3] dsa: mv88e6xxx: Add support for RMU in select switches
Date: Tue, 30 Aug 2022 19:42:26 +0300 [thread overview]
Message-ID: <20220830164226.ohmn6bkwagz6n3pg@skbuf> (raw)
In-Reply-To: <20220830163515.3d2lzzc55vmko325@skbuf>
On Tue, Aug 30, 2022 at 07:35:15PM +0300, Vladimir Oltean wrote:
> > +void mv88e6xxx_rmu_master_change(struct dsa_switch *ds, const struct net_device *master,
> > + bool operational)
> > +{
> > + struct mv88e6xxx_chip *chip = ds->priv;
> > +
> > + if (operational)
> > + chip->rmu.ops = &mv88e6xxx_bus_ops;
> > + else
> > + chip->rmu.ops = NULL;
> > +}
>
> There is a subtle but very important point to be careful about here,
> which is compatibility with multiple CPU ports. If there is a second DSA
> master whose state flaps from up to down, this should not affect the
> fact that you can still use RMU over the first DSA master. But in your
> case it does, so this is a case of how not to write code that accounts
> for that.
>
> In fact, given this fact, I think your function prototypes for
> chip->info->ops->rmu_enable() are all wrong / not sufficiently
> reflective of what the hardware can do. If the hardware has a bit mask
> of ports on which RMU operations are possible, why hardcode using
> dsa_switch_upstream_port() and not look at which DSA masters/CPU ports
> are actually up? At least for the top-most switch. For downstream
> switches we can use dsa_switch_upstream_port(), I guess (even that can
> be refined, but I'm not aware of setups using multiple DSA links, where
> each DSA link ultimately goes to a different upstream switch).
Hit "send" too soon. Wanted to give the extra hint that the "master"
pointer is given to you here for a reason. You can look at struct
dsa_port *cpu_dp = master->dsa_ptr, and figure out the index of the CPU
port which can be used for RMU operations. I see that the macros are
constructed in a very strange way:
#define MV88E6352_G1_CTL2_RMU_MODE_DISABLED 0x0000
#define MV88E6352_G1_CTL2_RMU_MODE_PORT_4 0x1000
#define MV88E6352_G1_CTL2_RMU_MODE_PORT_5 0x2000
#define MV88E6352_G1_CTL2_RMU_MODE_PORT_6 0x3000
it's as if this is actually a bit mask of ports, and they all can be
combined together. The bit in G1_CTL2 whose state we can flip can be
made to depend on the number of the CPU port attached to the DSA master
which changed state.
next prev parent reply other threads:[~2022-08-30 16:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-26 6:38 [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: Add RMU support Mattias Forsblad
2022-08-26 6:38 ` [PATCH net-next v2 1/3] dsa: Implement RMU layer in DSA Mattias Forsblad
2022-08-26 19:27 ` Andrew Lunn
2022-08-29 6:10 ` Mattias Forsblad
2022-08-29 12:42 ` Andrew Lunn
2022-08-30 15:47 ` Vladimir Oltean
2022-08-31 5:55 ` Mattias Forsblad
2022-08-26 6:38 ` [PATCH net-next v2 2/3] dsa: mv88e6xxx: Add support for RMU in select switches Mattias Forsblad
2022-08-30 16:35 ` Vladimir Oltean
2022-08-30 16:42 ` Vladimir Oltean [this message]
2022-08-31 6:15 ` Mattias Forsblad
2022-09-01 9:05 ` Mattias Forsblad
2022-09-01 13:14 ` Vladimir Oltean
2022-08-31 6:12 ` Mattias Forsblad
2022-08-31 15:24 ` Vladimir Oltean
2022-08-26 6:38 ` [PATCH net-next v2 3/3] rmon: Use RMU if available Mattias Forsblad
2022-08-30 14:20 ` Vladimir Oltean
2022-08-31 5:51 ` Mattias Forsblad
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=20220830164226.ohmn6bkwagz6n3pg@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=mattias.forsblad@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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