From: Arınç ÜNAL <arinc.unal@arinc9.com>
The CPU_PORT bits represent the CPU port to trap frames to for the MT7530
switch. This switch traps frames received from a user port to the CPU port
set on the CPU_PORT bits, regardless of the affinity of the user port from
which the frames are received.
When multiple CPU ports are being used, the trapped frames won't be
received when the DSA conduit interface, which the frames are supposed to
be trapped to, is down because it's not affine to any user port. This
requires the DSA conduit interface to be manually set up for the trapped
frames to be received.
To fix this, implement ds->ops->master_state_change() on this subdriver and
set the CPU_PORT bits to the CPU port which the DSA conduit interface its
affine to is up. Introduce the active_cpu_ports field to store the
information of the active CPU ports. Correct the macros, CPU_PORT is bits 4
through 6 of the register.
Add a comment to explain frame trapping for this switch.
Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
Suggested-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
drivers/net/dsa/mt7530.c | 32 ++++++++++++++++++++++++++++----
drivers/net/dsa/mt7530.h | 6 ++++--
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index b1657679e69d..ef8879087932 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1006,10 +1006,6 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
mt7530_set(priv, MT7530_MFC, BC_FFP(BIT(port)) | UNM_FFP(BIT(port)) |
UNU_FFP(BIT(port)));
- /* Set CPU port number */
- if (priv->id == ID_MT7621)
- mt7530_rmw(priv, MT7530_MFC, CPU_MASK, CPU_EN | CPU_PORT(port));
-
/* Add the CPU port to the CPU port bitmap for MT7531 and the switch on
* the MT7988 SoC. Frames received from a user port which are set for
* trapping to CPU port will be trapped to the CPU port that is affine
@@ -3063,6 +3059,33 @@ static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
return 0;
}
+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;
+
+ /* Set the CPU port to trap frames to for MT7530. There can be only one
+ * CPU port due to CPU_PORT having only 3 bits. Frames received from a
+ * user port which are set for trapping to CPU port will be trapped to
+ * the numerically smallest CPU port which is affine to the DSA conduit
+ * interface that is up.
+ */
+ if (priv->id != ID_MT7621)
+ return;
+
+ 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, MT7530_MFC, CPU_EN | CPU_PORT_MASK, CPU_EN |
+ CPU_PORT(__ffs(priv->active_cpu_ports)));
+}
+
static int mt7988_pad_setup(struct dsa_switch *ds, phy_interface_t interface)
{
return 0;
@@ -3117,6 +3140,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 e590cf43f3ae..28dbd131a535 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -41,8 +41,8 @@ enum mt753x_id {
#define UNU_FFP(x) (((x) & 0xff) << 8)
#define UNU_FFP_MASK UNU_FFP(~0)
#define CPU_EN BIT(7)
-#define CPU_PORT(x) ((x) << 4)
-#define CPU_MASK (0xf << 4)
+#define CPU_PORT_MASK GENMASK(6, 4)
+#define CPU_PORT(x) FIELD_PREP(CPU_PORT_MASK, x)
#define MIRROR_EN BIT(3)
#define MIRROR_PORT(x) ((x) & 0x7)
#define MIRROR_MASK 0x7
@@ -753,6 +753,7 @@ struct mt753x_info {
* @irq_domain: IRQ domain of the switch irq_chip
* @irq_enable: IRQ enable bits, synced to SYS_INT_EN
* @create_sgmii: Pointer to function creating SGMII PCS instance(s)
+ * @active_cpu_ports: Holding the active CPU ports
*/
struct mt7530_priv {
struct device *dev;
@@ -779,6 +780,7 @@ struct mt7530_priv {
struct irq_domain *irq_domain;
u32 irq_enable;
int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii);
+ unsigned long active_cpu_ports;
};
struct mt7530_hw_vlan_entry {
--
2.39.2
On Mon, Jun 12, 2023 at 10:59:40AM +0300, arinc9.unal@gmail.com wrote: > From: Arınç ÜNAL <arinc.unal@arinc9.com> > > The CPU_PORT bits represent the CPU port to trap frames to for the MT7530 > switch. This switch traps frames received from a user port to the CPU port > set on the CPU_PORT bits, regardless of the affinity of the user port from > which the frames are received. I think: "On the MT7530, the CPU_PORT() field indicates which CPU port to trap frames to, regardless of the affinity of the inbound user port." covers everything necessary in the first paragraph? Sorry to be a pain about this, but commit logs should be understandable. > When multiple CPU ports are being used, the trapped frames won't be > received when the DSA conduit interface, which the frames are supposed to > be trapped to, is down because it's not affine to any user port. This > requires the DSA conduit interface to be manually set up for the trapped > frames to be received. "When multiple CPU ports are in use, if the DSA conduit interface is down, trapped frames won't be passed to the conduit interface." > To fix this, implement ds->ops->master_state_change() on this subdriver and > set the CPU_PORT bits to the CPU port which the DSA conduit interface its ... "to the first CPU port" - isn't that what the code is doing with __ffs(priv->active_cpu_ports)? You're giving priority to the lowest numbered port, and I think that should be stated in the commit message. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 13.06.2023 00:09, Russell King (Oracle) wrote: > On Mon, Jun 12, 2023 at 10:59:40AM +0300, arinc9.unal@gmail.com wrote: >> From: Arınç ÜNAL <arinc.unal@arinc9.com> >> >> The CPU_PORT bits represent the CPU port to trap frames to for the MT7530 >> switch. This switch traps frames received from a user port to the CPU port >> set on the CPU_PORT bits, regardless of the affinity of the user port from >> which the frames are received. > > I think: > > "On the MT7530, the CPU_PORT() field indicates which CPU port to trap > frames to, regardless of the affinity of the inbound user port." > > covers everything necessary in the first paragraph? Sorry to be a pain > about this, but commit logs should be understandable. Sounds good to me. > >> When multiple CPU ports are being used, the trapped frames won't be >> received when the DSA conduit interface, which the frames are supposed to >> be trapped to, is down because it's not affine to any user port. This >> requires the DSA conduit interface to be manually set up for the trapped >> frames to be received. > > "When multiple CPU ports are in use, if the DSA conduit interface is > down, trapped frames won't be passed to the conduit interface." Ok. > >> To fix this, implement ds->ops->master_state_change() on this subdriver and >> set the CPU_PORT bits to the CPU port which the DSA conduit interface its > > ... "to the first CPU port" - isn't that what the code is doing with > __ffs(priv->active_cpu_ports)? You're giving priority to the lowest > numbered port, and I think that should be stated in the commit message. Will do. Arınç
On Mon, Jun 12, 2023 at 10:09:45PM +0100, Russell King (Oracle) wrote: > On Mon, Jun 12, 2023 at 10:59:40AM +0300, arinc9.unal@gmail.com wrote: > > From: Arınç ÜNAL <arinc.unal@arinc9.com> > > > > The CPU_PORT bits represent the CPU port to trap frames to for the MT7530 > > switch. This switch traps frames received from a user port to the CPU port > > set on the CPU_PORT bits, regardless of the affinity of the user port from > > which the frames are received. > > I think: > > "On the MT7530, the CPU_PORT() field indicates which CPU port to trap > frames to, regardless of the affinity of the inbound user port." also, is it really the MT7530, or is it MT7621? The code only does something for the MT7621. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
© 2016 - 2024 Red Hat, Inc.