summaryrefslogtreecommitdiff
path: root/drivers/net/dsa/mt7530.h
AgeCommit message (Collapse)Author
2024-03-21net: dsa: mt7530: fix handling of all link-local framesArınç ÜNAL
Currently, the MT753X switches treat frames with :01-0D and :0F MAC DAs as regular multicast frames, therefore flooding them to user ports. On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE Std 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC DA must only be propagated to C-VLAN and MAC Bridge components. That means VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports, these frames are supposed to be processed by the CPU (software). So we make the switch only forward them to the CPU port. And if received from a CPU port, forward to a single port. The software is responsible of making the switch conform to the latter by setting a single port as destination port on the special tag. This switch intellectual property cannot conform to this part of the standard fully. Whilst the REV_UN frame tag covers the remaining :04-0D and :0F MAC DAs, it also includes :22-FF which the scope of propagation is not supposed to be restricted for these MAC DAs. Set frames with :01-03 MAC DAs to be trapped to the CPU port(s). Add a comment for the remaining MAC DAs. Note that the ingress port must have a PVID assigned to it for the switch to forward untagged frames. A PVID is set by default on VLAN-aware and VLAN-unaware ports. However, when the network interface that pertains to the ingress port is attached to a vlan_filtering enabled bridge, the user can remove the PVID assignment from it which would prevent the link-local frames from being trapped to the CPU port. I am yet to see a way to forward link-local frames while preventing other untagged frames from being forwarded too. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-21net: dsa: mt7530: fix link-local frames that ingress vlan filtering portsArınç ÜNAL
Whether VLAN-aware or not, on every VID VLAN table entry that has the CPU port as a member of it, frames are set to egress the CPU port with the VLAN tag stacked. This is so that VLAN tags can be appended after hardware special tag (called DSA tag in the context of Linux drivers). For user ports on a VLAN-unaware bridge, frame ingressing the user port egresses CPU port with only the special tag. For user ports on a VLAN-aware bridge, frame ingressing the user port egresses CPU port with the special tag and the VLAN tag. This causes issues with link-local frames, specifically BPDUs, because the software expects to receive them VLAN-untagged. There are two options to make link-local frames egress untagged. Setting CONSISTENT or UNTAGGED on the EG_TAG bits on the relevant register. CONSISTENT means frames egress exactly as they ingress. That means egressing with the VLAN tag they had at ingress or egressing untagged if they ingressed untagged. Although link-local frames are not supposed to be transmitted VLAN-tagged, if they are done so, when egressing through a CPU port, the special tag field will be broken. BPDU egresses CPU port with VLAN tag egressing stacked, received on software: 00:01:25.104821 AF Unknown (382365846), length 106: | STAG | | VLAN | 0x0000: 0000 6c27 614d 4143 0001 0000 8100 0001 ..l'aMAC........ 0x0010: 0026 4242 0300 0000 0000 0000 6c27 614d .&BB........l'aM 0x0020: 4143 0000 0000 0000 6c27 614d 4143 0000 AC......l'aMAC.. 0x0030: 0000 1400 0200 0f00 0000 0000 0000 0000 ................ BPDU egresses CPU port with VLAN tag egressing untagged, received on software: 00:23:56.628708 AF Unknown (25215488), length 64: | STAG | 0x0000: 0000 6c27 614d 4143 0001 0000 0026 4242 ..l'aMAC.....&BB 0x0010: 0300 0000 0000 0000 6c27 614d 4143 0000 ........l'aMAC.. 0x0020: 0000 0000 6c27 614d 4143 0000 0000 1400 ....l'aMAC...... 0x0030: 0200 0f00 0000 0000 0000 0000 ............ BPDU egresses CPU port with VLAN tag egressing tagged, received on software: 00:01:34.311963 AF Unknown (25215488), length 64: | Mess | 0x0000: 0000 6c27 614d 4143 0001 0001 0026 4242 ..l'aMAC.....&BB 0x0010: 0300 0000 0000 0000 6c27 614d 4143 0000 ........l'aMAC.. 0x0020: 0000 0000 6c27 614d 4143 0000 0000 1400 ....l'aMAC...... 0x0030: 0200 0f00 0000 0000 0000 0000 ............ To prevent confusing the software, force the frame to egress UNTAGGED instead of CONSISTENT. This way, frames can't possibly be received TAGGED by software which would have the special tag field broken. VLAN Tag Egress Procedure For all frames, one of these options set the earliest in this order will apply to the frame: - EG_TAG in certain registers for certain frames. This will apply to frame with matching MAC DA or EtherType. - EG_TAG in the address table. This will apply to frame at its incoming port. - EG_TAG in the PVC register. This will apply to frame at its incoming port. - EG_CON and [EG_TAG per port] in the VLAN table. This will apply to frame at its outgoing port. - EG_TAG in the PCR register. This will apply to frame at its outgoing port. EG_TAG in certain registers for certain frames: PPPoE Discovery_ARP/RARP: PPP_EG_TAG and ARP_EG_TAG in the APC register. IGMP_MLD: IGMP_EG_TAG and MLD_EG_TAG in the IMC register. BPDU and PAE: BPDU_EG_TAG and PAE_EG_TAG in the BPC register. REV_01 and REV_02: R01_EG_TAG and R02_EG_TAG in the RGAC1 register. REV_03 and REV_0E: R03_EG_TAG and R0E_EG_TAG in the RGAC2 register. REV_10 and REV_20: R10_EG_TAG and R20_EG_TAG in the RGAC3 register. REV_21 and REV_UN: R21_EG_TAG and RUN_EG_TAG in the RGAC4 register. With this change, it can be observed that a bridge interface with stp_state and vlan_filtering enabled will properly block ports now. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05net: dsa: mt7530: simplify link operationsArınç ÜNAL
The "MT7621 Giga Switch Programming Guide v0.3", "MT7531 Reference Manual for Development Board v1.0", and "MT7988A Wi-Fi 7 Generation Router Platform: Datasheet (Open Version) v0.1" documents show that these bits are enabled at reset: PMCR_IFG_XMIT(1) (not part of PMCR_LINK_SETTINGS_MASK) PMCR_MAC_MODE (not part of PMCR_LINK_SETTINGS_MASK) PMCR_TX_EN PMCR_RX_EN PMCR_BACKOFF_EN (not part of PMCR_LINK_SETTINGS_MASK) PMCR_BACKPR_EN (not part of PMCR_LINK_SETTINGS_MASK) PMCR_TX_FC_EN PMCR_RX_FC_EN These bits also don't exist on the MT7530_PMCR_P(6) register of the switch on the MT7988 SoC: PMCR_IFG_XMIT() PMCR_MAC_MODE PMCR_BACKOFF_EN PMCR_BACKPR_EN Remove the setting of the bits not part of PMCR_LINK_SETTINGS_MASK on phylink_mac_config as they're already set. The bit for setting the port on force mode is already done on mt7530_setup() and mt7531_setup_common(). So get rid of PMCR_FORCE_MODE_ID() which helped determine which bit to use for the switch model. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05net: dsa: mt7530: get rid of priv->info->cpu_port_config()Arınç ÜNAL
priv->info->cpu_port_config() is used for MT7531 and the switch on the MT7988 SoC. It sets up the ports described as a CPU port earlier than the phylink code path would do. This function is useless as: - Configuring the MACs can be done from the phylink_mac_config code path instead. - All the link configuration it does on the CPU ports are later undone with the port_enable, phylink_mac_config, and then phylink_mac_link_up code path [1]. priv->p5_interface and priv->p6_interface were being used to prevent configuring the MACs from the phylink_mac_config code path. Remove them now that they hold no purpose. Remove priv->info->cpu_port_config(). On mt753x_phylink_mac_config, switch to if statements to simplify the code. Remove the overwriting of the speed and duplex interfaces for certain interface modes. Phylink already provides the speed and duplex variables with proper values. Phylink already sets the max speed of TRGMII to SPEED_1000. Add SPEED_2500 for PHY_INTERFACE_MODE_2500BASEX to where the speed and EEE bits are set instead. On the switch on the MT7988 SoC, PHY_INTERFACE_MODE_INTERNAL is being used to describe the interface mode of the 10G MAC, which is of port 6. On mt7988_cpu_port_config() PMCR_FORCE_SPEED_1000 was set via the PMCR_CPU_PORT_SETTING() mask. Add SPEED_10000 case to where the speed bits are set to cover this. No need to add it to where the EEE bits are set as the "MT7988A Wi-Fi 7 Generation Router Platform: Datasheet (Open Version) v0.1" document shows that these bits don't exist on the MT7530_PMCR_P(6) register. Remove the definition of PMCR_CPU_PORT_SETTING() now that it holds no purpose. Change mt753x_cpu_port_enable() to void now that there're no error cases left. Link: https://lore.kernel.org/netdev/ZHy2jQLesdYFMQtO@shell.armlinux.org.uk/ [1] Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-05net: dsa: mt7530: get rid of useless error returns on phylink code pathArınç ÜNAL
Remove error returns on the cases where they are already handled with the function the mac_port_get_caps member in mt753x_table points to. mt7531_mac_config() is also called from mt7531_cpu_port_config() outside of phylink but the port and interface modes are already handled there. Change the functions and the mac_port_config function pointer to void now that there're no error returns anymore. Remove mt753x_is_mac_port() that used to help the said error returns. On mt7531_mac_config(), switch to if statements to simplify the code. Remove internal phy cases from mt753x_phylink_mac_config(), there is no need to check the interface mode as that's already handled with the function the mac_port_get_caps member in mt753x_table points to. Acked-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-02-07net: dsa: mt7530: remove pad_setup function pointerArınç ÜNAL
The pad_setup function pointer was introduced with 88bdef8be9f6 ("net: dsa: mt7530: Extend device data ready for adding a new hardware"). It was being used to set up the core clock and port 6 of the MT7530 switch, and pll of the MT7531 switch. All of these were moved to more appropriate locations, and it was never used for the switch on the MT7988 SoC. Therefore, this function pointer hasn't got a use anymore. Remove it. Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-5-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: store port 5 SGMII capability of MT7531Arınç ÜNAL
Introduce the p5_sgmii field to store the information for whether port 5 has got SGMII or not. Instead of reading the MT7531_TOP_SIG_SR register multiple times, the register will be read once and the value will be stored on the p5_sgmii field. This saves unnecessary reads of the register. Move the comment about MT7531AE and MT7531BE to mt7531_setup(), where the switch is identified. Get rid of mt7531_dual_sgmii_supported() now that priv->p5_sgmii stores the information. Address the code where mt7531_dual_sgmii_supported() is used. Get rid of mt7531_is_rgmii_port() which just prints the opposite of priv->p5_sgmii. Instead of calling mt7531_pll_setup() then returning, do not call it if port 5 is SGMII. Remove P5_INTF_SEL_GMAC5_SGMII. The p5_interface_select enum is supposed to represent the mode that port 5 is being used in, not the hardware information of port 5. Set p5_intf_sel to P5_INTF_SEL_GMAC5 instead, if port 5 is not dsa_is_unused_port(). Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-3-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: use p5_interface_select as data type for p5_intf_selArınç ÜNAL
Use the p5_interface_select enumeration as the data type for the p5_intf_sel field. This ensures p5_intf_sel can only take the values defined in the p5_interface_select enumeration. Remove the explicit assignment of 0 to P5_DISABLED as the first enum item is automatically assigned 0. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-2-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: always trap frames to active CPU port on MT7530Arınç ÜNAL
On the MT7530 switch, the CPU_PORT field indicates which CPU port to trap frames to, regardless of the affinity of the inbound user port. 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 make trapping frames work including this case, implement ds->ops->conduit_state_change() on this subdriver and set the CPU_PORT field to the numerically smallest CPU port whose conduit interface 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. Currently, the driver doesn't support the use of multiple CPU ports so this is not necessarily a bug fix. Suggested-by: Vladimir Oltean <olteanv@gmail.com> Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-1-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-19net: dsa: mt7530: fix handling of 802.1X PAE framesArınç ÜNAL
802.1X PAE frames are link-local frames, therefore they must be trapped to the CPU port. Currently, the MT753X switches treat 802.1X PAE frames as regular multicast frames, therefore flooding them to user ports. To fix this, set 802.1X PAE frames to be trapped to the CPU port(s). Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20net: dsa: mt7530: fix handling of LLDP framesArınç ÜNAL
LLDP frames are link-local frames, therefore they must be trapped to the CPU port. Currently, the MT753X switches treat LLDP frames as regular multicast frames, therefore flooding them to user ports. To fix this, set LLDP frames to be trapped to the CPU port(s). Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20net: dsa: mt7530: set all CPU ports in MT7531_CPU_PMAPArınç ÜNAL
MT7531_CPU_PMAP represents the destination port mask for trapped-to-CPU frames (further restricted by PCR_MATRIX). Currently the driver sets the first CPU port as the single port in this bit mask, which works fine regardless of whether the device tree defines port 5, 6 or 5+6 as CPU ports. This is because the logic coincides with DSA's logic of picking the first CPU port as the CPU port that all user ports are affine to, by default. An upcoming change would like to influence DSA's selection of the default CPU port to no longer be the first one, and in that case, this logic needs adaptation. Since there is no observed leakage or duplication of frames if all CPU ports are defined in this bit mask, simply include them all. Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Suggested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-19net: dsa: mt7530: fix support for MT7531BEDaniel Golle
There are two variants of the MT7531 switch IC which got different features (and pins) regarding port 5: * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes PCS * MT7531BE: RGMII Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe with commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function") works fine for MT7531AE which got two instances of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup to setup clocks before the single PCS on port 6 (usually used as CPU port) starts to work and hence the PCS creation failed on MT7531BE. Fix this by introducing a pointer to mt7531_create_sgmii function in struct mt7530_priv and call it again at the end of mt753x_setup like it was before commit 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function"). Fixes: 6de285229773 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/ZDvlLhhqheobUvOK@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-03net: dsa: mt7530: introduce driver for MT7988 built-in switchDaniel Golle
Add driver for the built-in Gigabit Ethernet switch which can be found in the MediaTek MT7988 SoC. The switch shares most of its design with MT7530 and MT7531, but has it's registers mapped into the SoCs register space rather than being connected externally or internally via MDIO. Introduce a new platform driver to support that. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-03net: dsa: mt7530: introduce separate MDIO driverDaniel Golle
Split MT7530 switch driver into a common part and a part specific for MDIO connected switches and multi-chip modules. Move MDIO-specific functions to newly introduced mt7530-mdio.c while keeping the common parts in mt7530.c. Introduce new Kconfig symbol CONFIG_NET_DSA_MT7530_MDIO which is implied by CONFIG_NET_DSA_MT7530. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-03net: dsa: mt7530: move p5_intf_modes() function to mt7530.cDaniel Golle
In preparation of splitting mt7530.c into a driver for MDIO-connected as well as MDIO-accessed built-in switches on one hand and MMIO-accessed built-in switches move the p5_inft_modes() function from mt7530.h to mt7530.c. The function is only needed there and will trigger a compiler warning about a defined but unused function otherwise when including mt7530.h in the to-be-introduced bus-specific drivers. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-03net: dsa: mt7530: use regmap to access switch register spaceDaniel Golle
Use regmap API to access the switch register space. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-03-20net: dsa: mt7530: use external PCS driverDaniel Golle
Implement regmap access wrappers, for now only to be used by the pcs-mtk-lynxi driver. Make use of this external PCS driver and drop the now reduntant implementation in mt7530.c. As a nice side effect the SGMII registers can now also more easily be inspected for debugging via /sys/kernel/debug/regmap. Tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-17net: dsa: mt7530: Separate C22 and C45 MDIO bus transactionsAndrew Lunn
mt7530 does support C45, but its uses a mix of registering its MDIO bus and providing its private MDIO bus to the DSA core, too. This makes the change a bit more complex. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-23net: dsa: mt7530: add support for in-band link statusDaniel Golle
Read link status from SGMII PCS for in-band managed 2500Base-X and 1000Base-X connection on a MAC port of the MT7531. This is needed to get the SFP cage working which is connected to SGMII interface of port 5 of the MT7531 switch IC on the Bananapi BPi-R3 board. While at it also handle an_complete for both the autoneg and the non-autoneg codepath. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-06-14net: dsa: mt7530: get cpu-port via dp->cpu_dp instead of constantFrank Wunderlich
Replace last occurences of hardcoded cpu-port by cpu_dp member of dsa_port struct. Now the constant can be dropped. Suggested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-12net: dsa: mt7530: partially convert to phylink_pcsRussell King (Oracle)
Partially convert the mt7530 driver to use phylink's PCS support. This is a partial implementation as we don't move anything into the pcs_config method yet - this driver supports SGMII or 1000BASE-X without in-band. Tested-by: Marek Behún <kabel@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-04-12net: dsa: mt7530: only indicate linkmodes that can be supportedRussell King (Oracle)
Now that mt7530 is not using the basex helper, it becomes unnecessary to indicate support for both 1000baseX and 2500baseX when one of the 803.3z PHY interface modes is being selected. Ensure that the driver indicates only those linkmodes that can actually be supported by the PHY interface mode. Tested-by: Marek Behún <kabel@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-04-12net: dsa: mt7530: remove interface checksRussell King (Oracle)
As phylink checks the interface mode against the supported_interfaces bitmap, we no longer need to validate the interface mode, nor handle PHY_INTERFACE_MODE_NA in the validation function. Remove these to simplify the implementation. Tested-by: Marek Behún <kabel@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-04-12net: dsa: mt7530: populate supported_interfaces and mac_capabilitiesRussell King (Oracle)
Populate the supported interfaces and MAC capabilities for mt7530, mt7531 and mt7621 DSA switches. Filling this in will enable phylink to pre-check the PHY interface mode against the the supported interfaces bitmap prior to calling the validate function, and will eventually allow us to convert to using the generic validation. Tested-by: Marek Behún <kabel@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2021-08-25net: dsa: mt7530: manually set up VLAN ID 0DENG Qingfang
The driver was relying on dsa_slave_vlan_rx_add_vid to add VLAN ID 0. After the blamed commit, VLAN ID 0 won't be set up anymore, breaking software bridging fallback on VLAN-unaware bridges. Manually set up VLAN ID 0 to fix this. Fixes: 06cfb2df7eb0 ("net: dsa: don't advertise 'rx-vlan-filter' when not needed") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06net: dsa: mt7530: drop untagged frames on VLAN-aware ports without PVIDDENG Qingfang
The driver currently still accepts untagged frames on VLAN-aware ports without PVID. Use PVC.ACC_FRM to drop untagged frames in that case. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-04net: dsa: mt7530: always install FDB entries with IVL and FID 1DENG Qingfang
This reverts commit 7e777021780e ("mt7530 mt7530_fdb_write only set ivl bit vid larger than 1"). Before this series, the default value of all ports' PVID is 1, which is copied into the FDB entry, even if the ports are VLAN unaware. So `bridge fdb show` will show entries like `dev swp0 vlan 1 self` even on a VLAN-unaware bridge. The blamed commit does not solve that issue completely, instead it may cause a new issue that FDB is inaccessible in a VLAN-aware bridge with PVID 1. This series sets PVID to 0 on VLAN-unaware ports, so `bridge fdb show` will no longer print `vlan 1` on VLAN-unaware bridges, and that special case in fdb_write is not required anymore. Set FDB entries' filter ID to 1 to match the VLAN table. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-04net: dsa: mt7530: set STP state on filter ID 1DENG Qingfang
As filter ID 1 is the only one used for bridges, set STP state on it. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-04net: dsa: mt7530: use independent VLAN learning on VLAN-unaware bridgesDENG Qingfang
Consider the following bridge configuration, where bond0 is not offloaded: +-- br0 --+ / / | \ / / | \ / | | bond0 / | | / \ swp0 swp1 swp2 swp3 swp4 . . . . . . A B C Ideally, when the switch receives a packet from swp3 or swp4, it should forward the packet to the CPU, according to the port matrix and unknown unicast flood settings. But packet loss will happen if the destination address is at one of the offloaded ports (swp0~2). For example, when client C sends a packet to A, the FDB lookup will indicate that it should be forwarded to swp0, but the port matrix of swp3 and swp4 is configured to only allow the CPU to be its destination, so it is dropped. However, this issue does not happen if the bridge is VLAN-aware. That is because VLAN-aware bridges use independent VLAN learning, i.e. use VID for FDB lookup, on offloaded ports. As swp3 and swp4 are not offloaded, shared VLAN learning with default filter ID of 0 is used instead. So the lookup for A with filter ID 0 never hits and the packet can be forwarded to the CPU. In the current code, only two combinations were used to toggle user ports' VLAN awareness: one is PCR.PORT_VLAN set to port matrix mode with PVC.VLAN_ATTR set to transparent port, the other is PCR.PORT_VLAN set to security mode with PVC.VLAN_ATTR set to user port. It turns out that only PVC.VLAN_ATTR contributes to VLAN awareness, and port matrix mode just skips the VLAN table lookup. The reference manual is somehow misleading when describing PORT_VLAN modes. It states that PORT_MEM (VLAN port member) is used for destination if the VLAN table lookup hits, but actually **PORT_MEM & PORT_MATRIX** (bitwise AND of VLAN port member and port matrix) is used instead, which means we can have two or more separate VLAN-aware bridges with the same PVID and traffic won't leak between them. Therefore, to solve this, enable independent VLAN learning with PVID 0 on VLAN-unaware bridges, by setting their PCR.PORT_VLAN to fallback mode, while leaving standalone ports in port matrix mode. The CPU port is always set to fallback mode to serve those bridges. During testing, it is found that FDB lookup with filter ID of 0 will also hit entries with VID 0 even with independent VLAN learning. To avoid that, install all VLANs with filter ID of 1. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-16mt7530 fix mt7530_fdb_write vid missing ivl bitEric Woudstra
According to reference guides mt7530 (mt7620) and mt7531: NOTE: When IVL is reset, MAC[47:0] and FID[2:0] will be used to read/write the address table. When IVL is set, MAC[47:0] and CVID[11:0] will be used to read/write the address table. Since the function only fills in CVID and no FID, we need to set the IVL bit. The existing code does not set it. This is a fix for the issue I dropped here earlier: http://lists.infradead.org/pipermail/linux-mediatek/2021-June/025697.html With this patch, it is now possible to delete the 'self' fdb entry manually. However, wifi roaming still has the same issue, the entry does not get deleted automatically. Wifi roaming also needs a fix somewhere else to function correctly in combination with vlan. Signed-off-by: Eric Woudstra <ericwouds@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-19net: dsa: mt7530: add interrupt supportDENG Qingfang
Add support for MT7530 interrupt controller to handle internal PHYs. In order to assign an IRQ number to each PHY, the registration of MDIO bus is also done in this driver. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-13net: dsa: mt7530: Add support for EEE featuresRené van Dorst
This patch adds EEE support. Signed-off-by: René van Dorst <opensource@vdorst.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-16net: dsa: mt7530: support MDB and bridge flag operationsDENG Qingfang
Support port MDB and bridge flag operations. As the hardware can manage multicast forwarding itself, offload_fwd_mark can be unconditionally set to true. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-01-25net: dsa: mt7530: MT7530 optional GPIO supportDENG Qingfang
MT7530's LED controller can drive up to 15 LED/GPIOs. Add support for GPIO control and allow users to use its GPIOs by setting gpio-controller property in device tree. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-08net: dsa: mt7530: support setting ageing timeDENG Qingfang
MT7530 has a global address age control register, so use it to set ageing time. The applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-11-04net: dsa: mt7530: support setting MTUDENG Qingfang
MT7530/7531 has a global RX packet length register, which can be used to set MTU. Supported packet length values are 1522 (1518 if untagged), 1536, 1552, and multiple of 1024 (from 2048 to 15360). Signed-off-by: DENG Qingfang <dqfext@gmail.com> Link: https://lore.kernel.org/r/20201103050618.11419-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-14net: dsa: mt7530: Add the support of MT7531 switchLanden Chao
Add new support for MT7531: MT7531 is the next generation of MT7530. It is also a 7-ports switch with 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu port 6 only supports SGMII interface. Cpu port 5 supports either RGMII or SGMII in different HW sku, but cannot be muxed to PHY of port 0/4 like mt7530. Due to SGMII interface support, pll, and pad setting are different from MT7530. This patch adds different initial setting, and SGMII phylink handlers of MT7531. MT7531 SGMII interface can be configured in following mode: - 'SGMII AN mode' with in-band negotiation capability which is compatible with PHY_INTERFACE_MODE_SGMII. - 'SGMII force mode' without in-band negotiation which is compatible with 10B/8B encoding of PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. - 2.5 times faster clocked 'SGMII force mode' without in-band negotiation which is compatible with 10B/8B encoding of PHY_INTERFACE_MODE_2500BASEX with fixed full-duplex and fixed pause. Signed-off-by: Landen Chao <landen.chao@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-14net: dsa: mt7530: Extend device data ready for adding a new hardwareLanden Chao
Add a structure holding required operations for each device such as device initialization, PHY port read or write, a checker whether PHY interface is supported on a certain port, MAC port setup for either bus pad or a specific PHY interface. The patch is done for ready adding a new hardware MT7531, and keep the same setup logic of existing hardware. Signed-off-by: Landen Chao <landen.chao@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
The MSCC bug fix in 'net' had to be slightly adjusted because the register accesses are done slightly differently in net-next. Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-16net: dsa: mt7530: fix roaming from DSA user portsDENG Qingfang
When a client moves from a DSA user port to a software port in a bridge, it cannot reach any other clients that connected to the DSA user ports. That is because SA learning on the CPU port is disabled, so the switch ignores the client's frames from the CPU port and still thinks it is at the user port. Fix it by enabling SA learning on the CPU port. To prevent the switch from learning from flooding frames from the CPU port, set skb->offload_fwd_mark to 1 for unicast and broadcast frames, and let the switch flood them instead of trapping to the CPU port. Multicast frames still need to be trapped to the CPU port for snooping, so set the SA_DIS bit of the MTK tag to 1 when transmitting those frames to disable SA learning. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: dsa: mt7530: set CPU port to fallback modeDENG Qingfang
Currently, setting a bridge's self PVID to other value and deleting the default VID 1 renders untagged ports of that VLAN unable to talk to the CPU port: bridge vlan add dev br0 vid 2 pvid untagged self bridge vlan del dev br0 vid 1 self bridge vlan add dev sw0p0 vid 2 pvid untagged bridge vlan del dev sw0p0 vid 1 # br0 cannot send untagged frames out of sw0p0 anymore That is because the CPU port is set to security mode and its PVID is still 1, and untagged frames are dropped due to VLAN member violation. Set the CPU port to fallback mode so untagged frames can pass through. Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-16net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware modeDENG Qingfang
In VLAN-unaware mode, the Egress Tag (EG_TAG) field in Port VLAN Control register must be set to Consistent to let tagged frames pass through as is, otherwise their tags will be stripped. Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: René van Dorst <opensource@vdorst.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-07net: dsa: mt7530: move mt7623 settings out off the mt7530René van Dorst
Moving mt7623 logic out off mt7530, is required to make hardware setting consistent after we introduce phylink to mtk driver. Fixes: ca366d6c889b ("net: dsa: mt7530: Convert to PHYLINK API") Reviewed-by: Sean Wang <sean.wang@mediatek.com> Tested-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: René van Dorst <opensource@vdorst.com> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-29net: dsa: mt7530: use resolved link config in mac_link_up()René van Dorst
Convert the mt7530 switch driver to use the finalised link parameters in mac_link_up() rather than the parameters in mac_config(). Signed-off-by: René van Dorst <opensource@vdorst.com> Tested-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-10net: dsa: mt7530: fix macro MIRROR_PORTDENG Qingfang
The inner pair of parentheses should be around the variable x Fixes: 37feab6076aa ("net: dsa: mt7530: add support for port mirroring") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-09net: dsa: mt7530: add support for port mirroringDENG Qingfang
Add support for configuring port mirroring through the cls_matchall classifier. We do a full ingress and/or egress capture towards a capture port. MT7530 supports one monitor port and multiple mirrored ports. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-05net: dsa: mt7530: Add support for port 5René van Dorst
Adding support for port 5. Port 5 can muxed/interface to: - internal 5th GMAC of the switch; can be used as 2nd CPU port or as extra port with an external phy for a 6th ethernet port. - internal PHY of port 0 or 4; Used in most applications so that port 0 or 4 is the WAN port and interfaces with the 2nd GMAC of the SOC. Signed-off-by: René van Dorst <opensource@vdorst.com> Tested-by: Frank Wunderlich <frank-w@public-files.de> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-05net: dsa: mt7530: Convert to PHYLINK APIRené van Dorst
Convert mt7530 to PHYLINK API Signed-off-by: René van Dorst <opensource@vdorst.com> Tested-by: Frank Wunderlich <frank-w@public-files.de> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-22net: dsa: mt7530: Add MT7621 TRGMII mode supportRené van Dorst
This patch add support TRGMII mode for MT7621 internal MT7530 switch. MT7621 TRGMII has only one fix speed mode of 1200MBit. Also adding support for mt7530 25MHz and 40MHz crystal clocksource. Values are based on Banana Pi R2 bsp [1]. Don't change MT7623 registers on a MT7621 device. [1] https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/master/linux-mt/drivers/net/ethernet/mediatek/gsw_mt7623.c#L769 Signed-off-by: René van Dorst <opensource@vdorst.com> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-03-31 09:37:05 +0000