- 21 Jul, 2021 2 commits
-
-
Vladimir Oltean authored
The blamed commit was probably not tested on net-next, since it did not refactor the extra phy id check introduced in commit b856150c ("net: phy: at803x: mask 1000 Base-X link mode"). Fixes: 8887ca54 ("net: phy: at803x: simplify custom phy id matching") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King (Oracle) authored
We only need to fiddle about with the supported mask after we have validated the user's requested parameters. Simplify and streamline the code by moving the linkmode copy and update of the autoneg bit after validating the user's request. Signed-off-by:
-
- 20 Jul, 2021 38 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2021-07-20 This series contains updates to e1000e and igc drivers. Sasha adds initial S0ix support for devices with CSME and adds polling for exiting of DPG. He sets the PHY to low power idle when in S0ix. He also adds support for new device IDs for and adds a space to debug messaging to help with readability for e1000e. For igc, he ensures that q_vector array is not accessed beyond its bounds and removes unneeded PHY related checks. Tree Davies corrects a spelling mistake in e1000e. Muhammad corrects the value written when there is no TSN offloading and adjusts timeout value to avoid possible Tx hang for igc. ==================== Signed-off-by: -
Joakim Zhang authored
This patch changs interrupt order which found by dtbs_check. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml arch/arm64/boot/dts/freescale/imx8mp-evk.dt.yaml: ethernet@30bf0000: interrupt-names:0: 'macirq' was expected arch/arm64/boot/dts/freescale/imx8mp-evk.dt.yaml: ethernet@30bf0000: interrupt-names:1: 'eth_wake_irq' was expected According to Documentation/devicetree/bindings/net/snps,dwmac.yaml, we should list interrupt in it's order. Signed-off-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by:
-
Joakim Zhang authored
In order to automate the verification of DT nodes covert imx-dwmac to nxp,dwmac-imx.yaml, and pass below checking. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml Signed-off-by:
-
Joakim Zhang authored
Add missing DWMAC IP version in snps,dwmac.yaml which found by below command, as NXP i.MX8 families support SNPS DWMAC 5.10a IP. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml Documentation/devicetree/bindings/net/nxp,dwmac-imx.example.dt.yaml: ethernet@30bf0000: compatible: None of ['nxp,imx8mp-dwmac-eqos', 'snps,dwmac-5.10a'] are valid under the given schema Signed-off-by:
-
Muhammad Husaini Zulkifli authored
As the cycle time is set to maximum of 1s, the TX Hang timeout need to be increase to avoid possible TX Hang. There is no dedicated number specific in data sheet for the timeout factor. Timeout factor was determined during the debugging to solve the "Tx Hang" issues that happen in some cases mainly during ETF(Earliest TxTime First). This can be test by using TSN Schedule Tx Tools udp_tai sample application. Signed-off-by:
Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Acked-by:
Sasha Neftin <sasha.neftin@intel.com> Tested-by:
Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Muhammad Husaini Zulkifli authored
According to datasheet section 8.12.19, when there's no TSN offloading Shadow_QbvCycle bit[29:0] must be set to zero for basic scheduling. Signed-off-by:
-
Sasha Neftin authored
i225 devices have only one phy->type: copper. There is no point checking phy->type during the igc_has_link method from the watchdog that invoked every 2 seconds. This patch comes to clean up these pointless checkings. Signed-off-by:
-
Sasha Neftin authored
i225 devices have only one PHY vendor. There is no point checking _I_PHY_ID during the link establishment and auto-negotiation process. This patch comes to clean up these pointless checkings. Signed-off-by:
-
Sasha Neftin authored
Ensure that the adapter->q_vector[MAX_Q_VECTORS] array isn't accessed beyond its size. It was fixed by using a local variable num_q_vectors as a limit for loop index, and ensure that num_q_vectors is not bigger than MAX_Q_VECTORS. Suggested-by:
Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by:
-
Tree Davies authored
There is a spelling mistake in the comment block. Signed-off-by:
Tree Davies <tdavies@darkphysics.net> Signed-off-by:
-
Sasha Neftin authored
Minor fixes to allow debug prints more readable. Signed-off-by:
-
Sasha Neftin authored
Add devices IDs for the next LOM generations that will be available on the next Intel Client platforms This patch provides the initial support for these devices Signed-off-by:
-
Sasha Neftin authored
Add devices IDs for the next LOM generations that will be available on the next Intel Client platform (Lunar Lake) This patch provides the initial support for these devices Signed-off-by:
-
Sasha Neftin authored
After transferring the MAC-PHY interface to the SMBus set the PHY to S0ix low power idle mode. Suggested-by:
Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by:
-
Sasha Neftin authored
Per guidance from the CSME architecture team, it may take up to 1 second for unconfiguring dynamic power gating mode. Practically it can take more time. Wait up to 2.5 seconds to indicate dynamic power gating exit from the S0ix configuration. Detect scenarios that take more than 1 second but less than 2.5 seconds will emit warning message. Signed-off-by:
-
Sasha Neftin authored
On the corporate system, the driver will ask from the CSME (manageability engine) to perform device settings are required to allow S0ix residency. This patch provides initial support. Reviewed-by:
-
Russell King authored
The at803x driver contains a function, at803x_match_phy_id(), which tests whether the PHY ID matches the value passed, comparing phy_id with phydev->phy_id and testing all bits that in the driver's mask. This is the same test that is used to match the driver, with phy_id replaced with the driver specified ID, phydev->drv->phy_id. Hence, we already know the value of the bits being tested if we look at phydev->drv->phy_id directly, and we do not require a complicated test to check them. Test directly against phydev->drv->phy_id instead. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Colin Ian King authored
The character sequence ??! is a trigraph and causes the following clang warning: drivers/net/ethernet/marvell/mvneta.c:2604:39: warning: trigraph ignored [-Wtrigraphs] Clean this by replacing it with single ?. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
The character sequence ??) is a trigraph and causes the following clang warning: drivers/atm/idt77252.c:3544:35: warning: trigraph ignored [-Wtrigraphs] Clean this by replacing it with single ?. Signed-off-by:
-
Martin Schiller authored
This adds the possibility to configure the RGMII RX/TX clock skew via devicetree. Simply set phy mode to "rgmii-id", "rgmii-rxid" or "rgmii-txid" and add the "rx-internal-delay-ps" or "tx-internal-delay-ps" property to the devicetree. Furthermore, a warning is now issued if the phy mode is configured to "rgmii" and an internal delay is set in the phy (e.g. by pin-strapping), as in the dp83867 driver. Signed-off-by:
Martin Schiller <ms@dev.tdt.de> Signed-off-by:
-
Russell King (Oracle) authored
Augment the phy link debug prints with the pause state. Signed-off-by:
-
Russell King (Oracle) authored
The documentation for Armada 8040 says: Bit 2 Field InBandAnEn In-band Auto-Negotiation enable. ... When <PortType> = 1 (1000BASE-X) this field must be set to 1. We presently ignore whether userspace requests autonegotiation or not through the ethtool ksettings interface. However, we have some network interfaces that wish to do this. To offer a consistent API across network interfaces, deny the ability to disable autonegotiation on mvpp2 hardware when in 1000BASE-X and 2500BASE-X. This means the only way to switch between 2500BASE-X and 1000BASE-X on SFPs that support this will be: # ethtool -s ethX advertise 0x20000006000 # 1000BASE-X Pause AsymPause # ethtool -s ethX advertise 0xe000 # 2500BASE-X Pause AsymPause Signed-off-by:
Marek Behún <kabel@kernel.org> Acked-by:
Marcin Wojtas <mw@semihalf.com> Signed-off-by:
-
Russell King (Oracle) authored
The documentation for Armada 38x says: Bit 2 Field InBandAnEn In-band Auto-Negotiation enable. ... When <PortType> = 1 (1000BASE-X) this field must be set to 1. We presently ignore whether userspace requests autonegotiation or not through the ethtool ksettings interface. However, we have some network interfaces that wish to do this. To offer a consistent API across network interfaces, deny the ability to disable autonegotiation on mvneta hardware when in 1000BASE-X and 2500BASE-X. This means the only way to switch between 2500BASE-X and 1000BASE-X on SFPs that support this will be: # ethtool -s ethX advertise 0x20000002000 # 1000BASE-X Pause # ethtool -s ethX advertise 0xa000 # 2500BASE-X Pause Signed-off-by:
-
Yang Yang authored
Root in init user namespace can modify /proc/sys/net/ipv4/ip_forward without CAP_NET_ADMIN, this doesn't follow the principle of capabilities. For example, let's take a look at netdev_store(), root can't modify netdev attribute without CAP_NET_ADMIN. So let's keep the consistency of permission check logic. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Yang Yang <yang.yang29@zte.com.cn> Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== arm64: dts: qcom: DTS updates This series updates some IPA-related DT nodes. Newer versions of IPA do not require an interconnect between IPA and SoC internal memory. The first patch updates the DT binding to reflect this. The second patch adds IPA information to "sc7280.dtsi", using only two interconnects. It includes the definition of the reserved memory area used to hold IPA firmware. The last patch defines the reserved IPA firmware memory area in "sc7180.dtsi". ==================== Signed-off-by: -
Alex Elder authored
Define the reserved memory space used for IPA firmware for the Qualcomm SC7180 SoC. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Add IPA-related nodes and definitions to "sc7280.dtsi", including the reserved memory area used for AP-based IPA firmware loading. Signed-off-by:
-
Alex Elder authored
On some newer SoCs, the interconnect between IPA and SoC internal memory (imem) is not used. Reflect this in the binding by moving the definition of the "imem" interconnect to the end and defining minItems to be 2 for both the interconnects and interconnect-names properties. Signed-off-by:
-
Alex Elder authored
Currently three interconnects are defined for the Qualcomm SC7280 SoC, but this was based on a misunderstanding. There should only be two interconnects defined: one between the IPA and system memory; and another between the AP and IPA config space. The bandwidths defined for the memory and config interconnects do not match what I understand to be proper values, so update these. Signed-off-by:
-
Fabio Estevam authored
The following warning is observed when running 'make dtbs_check': Documentation/devicetree/bindings/net/fsl,fec.yaml:85:7: [warning] wrong indentation: expected 8 but found 6 (indentation) Fix the indentation accordingly. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Fan out FDB entries pointing towards the bridge to all switchdev member ports The "DSA RX filtering" series has added some important support for interpreting addresses towards the bridge device as host addresses and installing them as FDB entries towards the CPU port, but it does not cover all circumstances and needs further work. To be precise, the mechanism introduced in that series only works as long as the ports are fairly static and no port joins or leaves the bridge once the configuration is done. If any port leaves, host FDB entries that were installed during runtime (for example the user changes the MAC address of the bridge device) will be prematurely deleted, resulting in a broken setup. I see this work as targeted for "net-next" because technically it was not supposed to work. Also, there are still corner cases and holes to be plugged. For example, today, FDB entries on foreign interfaces are not covered by br_fdb_replay(), which means that there are cases where some host addresses are either lost, or never deleted by DSA. That will be resolved once more work gets accepted, in particular the "Allow forwarding for the software bridge data path to be offloaded to capable devices" series, which moves the br_fdb_replay() call to the bridge core and therefore would be required to solve the problem in a generic way for every switchdev driver and not just for DSA. These patches also pave the way for a cleaner implementation for FDB entries pointing towards a LAG upper interface in DSA (that code needs only to be added, nothing changed), however this is not done here. ==================== Signed-off-by: -
Vladimir Oltean authored
Using the new fan-out helper for FDB entries installed on the software bridge, we can install host addresses with the proper refcount on the CPU port, such that this case: ip link set swp0 master br0 ip link set swp1 master br0 ip link set swp2 master br0 ip link set swp3 master br0 ip link set br0 address 00:01:02:03:04:05 ip link set swp3 nomaster works properly and the br0 address remains installed as a host entry with refcount 3 instead of getting deleted. Signed-off-by:
-
Vladimir Oltean authored
Currently DSA has an issue with FDB entries pointing towards the bridge in the presence of br_fdb_replay() being called at port join and leave time. In particular, each bridge port will ask for a replay for the FDB entries pointing towards the bridge when it joins, and for another replay when it leaves. This means that for example, a bridge with 4 switch ports will notify DSA 4 times of the bridge MAC address. But if the MAC address of the bridge changes during the normal runtime of the system, the bridge notifies switchdev [ once ] of the deletion of the old MAC address as a local FDB towards the bridge, and of the insertion [ again once ] of the new MAC address as a local FDB. This is a problem, because DSA keeps the old MAC address as a host FDB entry with refcount 4 (4 ports asked for it using br_fdb_replay). So the old MAC address will not be deleted. Additionally, the new MAC address will only be installed with refcount 1, and when the first switch port leaves the bridge (leaving 3 others as still members), it will delete with it the new MAC address of the bridge from the local FDB entries kept by DSA (because the br_fdb_replay call on deletion will bring the entry's refcount from 1 to 0). So the problem, really, is that the number of br_fdb_replay() calls is not matched with the refcount that a host FDB is offloaded to DSA during normal runtime. An elegant way to solve the problem would be to make the switchdev notification emitted by br_fdb_change_mac_address() result in a host FDB kept by DSA which has a refcount exactly equal to the number of ports under that bridge. Then, no matter how many DSA ports join or leave that bridge, the host FDB entry will always be deleted when there are exactly zero remaining DSA switch ports members of the bridge. To implement the proposed solution, we remember that the switchdev objects and port attributes have some helpers provided by switchdev, which can be optionally called by drivers: switchdev_handle_port_obj_{add,del} and switchdev_handle_port_attr_set. These helpers: - fan out a switchdev object/attribute emitted for the bridge towards all the lower interfaces that pass the check_cb(). - fan out a switchdev object/attribute emitted for a bridge port that is a LAG towards all the lower interfaces that pass the check_cb(). In other words, this is the model we need for the FDB events too: something that will keep an FDB entry emitted towards a physical port as it is, but translate an FDB entry emitted towards the bridge into N FDB entries, one per physical port. Of course, there are many differences between fanning out a switchdev object (VLAN) on 3 lower interfaces of a LAG and fanning out an FDB entry on 3 lower interfaces of a LAG. Intuitively, an FDB entry towards a LAG should be treated specially, because FDB entries are unicast, we can't just install the same address towards 3 destinations. It is imaginable that drivers might want to treat this case specifically, so create some methods for this case and do not recurse into the LAG lower ports, just the bridge ports. DSA also listens for FDB entries on "foreign" interfaces, aka interfaces bridged with us which are not part of our hardware domain: think an Ethernet switch bridged with a Wi-Fi AP. For those addresses, DSA installs host FDB entries. However, there we have the same problem (those host FDB entries are installed with a refcount of only 1) and an even bigger one which we did not have with FDB entries towards the bridge: br_fdb_replay() is currently not called for FDB entries on foreign interfaces, just for the physical port and for the bridge itself. So when DSA sniffs an address learned by the software bridge towards a foreign interface like an e1000 port, and then that e1000 leaves the bridge, DSA remains with the dangling host FDB address. That will be fixed separately by replaying all FDB entries and not just the ones towards the port and the bridge. Signed-off-by: -
Vladimir Oltean authored
It is a bit difficult to understand what DSA checks when it tries to avoid installing dynamically learned addresses on foreign interfaces as local host addresses, so create a generic switchdev helper that can be reused and is generally more readable. Signed-off-by:
-
Xu Liang authored
Add driver to support the Maxlinear GPY115, GPY211, GPY212, GPY215, GPY241, GPY245 PHYs. Separate from XWAY PHY driver because this series has different register layout and new features not supported in XWAY PHY. Signed-off-by:
Xu Liang <lxu@maxlinear.com> Acked-by:
Hauke Mehrtens <hmehrtens@maxlinear.com> Tested-by:
Wong Vee Khee <vee.khee.wong@linux.intel.com> Tested-by:
-
Xu Liang authored
Add API to read 802.3-c45 IDs so that C22/C45 mixed device can use C45 APIs without failing ID checks. Signed-off-by:
-
David S. Miller authored
Vladimir Olteans says: ==================== Proper cross-chip support for tag_8021q The cross-chip bridging support for tag_8021q/sja1105 introduced here: https://patchwork.ozlabs.org/project/netdev/cover/20200510163743.18032-1-olteanv@gmail.com/ took some shortcuts and is not reusable in other topologies except for the one it was written for: disjoint DSA trees. A diagram of this topology can be seen here: https://patchwork.ozlabs.org/project/netdev/patch/20200510163743.18032-3-olteanv@gmail.com/ However there are sja1105 switches on other boards using other topologies, most notably: - Daisy chained: | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ] - "H" topology: eth0 eth1 | | CPU port CPU port | DSA link | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 -------- sw1p4 sw1p3 sw1p2 sw1p1 sw1p0 | | | | | | user user user user user user port port port port port port In fact, the current code for tag_8021q cross-chip links works for neither of these 2 classes of topologies. The main reasons are: (a) The sja1105 driver does not treat DSA links. In the "disjoint trees" topology, the routing port towards any other switch is also the CPU port, and that was already configured so it already worked. This series does not deal with enabling DSA links in the sja1105 driver, that is a fairly trivial task that will be dealt with separately. (b) The tag_8021q code for cross-chip links assumes that any 2 switches between cross-chip forwarding needs to be enabled (i.e. which have user ports part of the same bridge) are at most 1 hop away from each other. This was true for the "disjoint trees" case because once a packet reached the CPU port, VLAN-unaware bridging was done by the DSA master towards the other switches based on destination MAC address, so the tag_8021q header was not interpreted in any way. However, in a daisy chain setup with 3 switches, all of them will interpret the tag_8021q header, and all tag_8021q VLANs need to be installed in all switches. When looking at the O(n^2) real complexity of the problem, it is clear that the current code had absolutely no chance of working in the general case. So this patch series brings a redesign of tag_8021q, in light of its new requirements. Anything with O(n^2) complexity (where n is the number of switches in a DSA tree) is an obvious candidate for the DSA cross-chip notifier support. One by one, the patches are: - The sja1105 driver is extremely entangled with tag_8021q, to be exact, with that driver's best_effort_vlan_filtering support. We drop this operating mode, which means that sja1105 temporarily loses network stack termination for VLAN-aware bridges. That operating mode raced itself to its own grave anyway due to some hardware limitations in combination with PTP reported by NXP customers. I can't say a lot more, but network stack termination for VLAN-aware bridges in sja1105 will be reimplemented soon with a much, much better solution. - What remains of tag_8021q in sja1105 is support for standalone ports mode and for VLAN-unaware bridging. We refactor the API surface of tag_8021q to a single pair of dsa_tag_8021q_{register,unregister} functions and we clean up everything else related to tag_8021q from sja1105 and felix. - Then we move tag_8021q into the DSA core. I thought about this a lot, and there is really no other way to add a DSA_NOTIFIER_TAG_8021Q_VLAN_ADD cross-chip notifier if DSA has no way to know if the individual switches use tag_8021q or not. So it needs to be part of the core to use notifiers. - Then we modify tag_8021q to update dynamically on bridge_{join,leave} events, instead of what we have today which is simply installing the VLANs on all ports of a switch and leaving port isolation up to somebody else. This change is necessary because port isolation over a DSA link cannot be done in any other way except based on VLAN membership, as opposed to bridging within the same switch which had 2 choices (at least on sja1105). - Finally we add 2 new cross-chip notifiers for adding and deleting a tag_8021q VLAN, which is properly refcounted similar to the bridge FDB and MDB code, and complete cleanup is done on teardown (note that this is unlike regular bridge VLANs, where we currently cannot do refcounting because the user can run "bridge vlan add dev swp0 vid 100" a gazillion times, and "bridge vlan del dev swp0 vid 100" just once, and for some reason expect that the VLAN will be deleted. But I digress). With this opportunity we remove a lot of hard-to-digest code and replace it with much more idiomatic DSA-style code. This series was regression-tested on: - Single-switch boards with SJA1105T - Disjoint-tree boards with SJA1105S and Felix (using ocelot-8021q) - H topology boards using SJA1110A ==================== Signed-off-by:
-
Vladimir Oltean authored
The big problem which mandates cross-chip notifiers for tag_8021q is this: | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] When the user runs: ip link add br0 type bridge ip link set sw0p0 master br0 ip link set sw2p0 master br0 It doesn't work. This is because dsa_8021q_crosschip_bridge_join() assumes that "ds" and "other_ds" are at most 1 hop away from each other, so it is sufficient to add the RX VLAN of {ds, port} into {other_ds, other_port} and vice versa and presto, the cross-chip link works. When there is another switch in the middle, such as in this case switch 1 with its DSA links sw1p3 and sw1p4, somebody needs to tell it about these VLANs too. Which is exactly why the problem is quadratic: when a port joins a bridge, for each port in the tree that's already in that same bridge we notify a tag_8021q VLAN addition of that port's RX VLAN to the entire tree. It is a very complicated web of VLANs. It must be mentioned that currently we install tag_8021q VLANs on too many ports (DSA links - to be precise, on all of them). For example, when sw2p0 joins br0, and assuming sw1p0 was part of br0 too, we add the RX VLAN of sw2p0 on the DSA links of switch 0 too, even though there isn't any port of switch 0 that is a member of br0 (at least yet). In theory we could notify only the switches which sit in between the port joining the bridge and the port reacting to that bridge_join event. But in practice that is impossible, because of the way 'link' properties are described in the device tree. The DSA bindings require DT writers to list out not only the real/physical DSA links, but in fact the entire routing table, like for example switch 0 above will have: sw0p3: port@3 { link = <&sw1p4 &sw2p4>; }; This was done because: /* TODO: ideally DSA ports would have a single dp->link_dp member, * and no dst->rtable nor this struct dsa_link would be needed, * but this would require some more complex tree walking, * so keep it stupid at the moment and list them all. */ but it is a perfect example of a situation where too much information is actively detrimential, because we are now in the position where we cannot distinguish a real DSA link from one that is put there to avoid the 'complex tree walking'. And because DT is ABI, there is not much we can change. And because we do not know which DSA links are real and which ones aren't, we can't really know if DSA switch A is in the data path between switches B and C, in the general case. So this is why tag_8021q RX VLANs are added on all DSA links, and probably why it will never change. On the other hand, at least the number of additions/deletions is well balanced, and this means that once we implement reference counting at the cross-chip notifier level a la fdb/mdb, there is absolutely zero need for a struct dsa_8021q_crosschip_link, it's all self-managing. In fact, with the tag_8021q notifiers emitted from the bridge join notifiers, it becomes so generic that sja1105 does not need to do anything anymore, we can just delete its implementation of the .crosschip_bridge_{join,leave} methods. Among other things we can simply delete is the home-grown implementation of sja1105_notify_crosschip_switches(). The reason why that is wrong is because it is not quadratic - it only covers remote switches to which we have a cross-chip bridging link and that does not cover in-between switches. This deletion is part of the same patch because sja1105 used to poke deep inside the guts of the tag_8021q context in order to do that. Because the cross-chip links went away, so needs the sja1105 code. Last but not least, dsa_8021q_setup_port() is simplified (and also renamed). Because our TAG_8021Q_VLAN_ADD notifier is designed to react on the CPU port too, the four dsa_8021q_vid_apply() calls: - 1 for RX VLAN on user port - 1 for the user port's RX VLAN on the CPU port - 1 for TX VLAN on user port - 1 for the user port's TX VLAN on the CPU port now get squashed into only 2 notifier calls via dsa_port_tag_8021q_vlan_add. And because the notifiers to add and to delete a tag_8021q VLAN are distinct, now we finally break up the port setup and teardown into separate functions instead of relying on a "bool enabled" flag which tells us what to do. Arguably it should have been this way from the get go. Signed-off-by:
-
