summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ipv6: ioam: Support for IOAM injection with lwtunnelsJustin Iurman2021-07-2110-12/+358
| | | | | | | | | | | | | | | | | | | | Add support for the IOAM inline insertion (only for the host-to-host use case) which is per-route configured with lightweight tunnels. The target is iproute2 and the patch is ready. It will be posted as soon as this patchset is merged. Here is an overview: $ ip -6 ro ad fc00::1/128 encap ioam6 trace type 0x800000 ns 1 size 12 dev eth0 This example configures an IOAM Pre-allocated Trace option attached to the fc00::1/128 prefix. The IOAM namespace (ns) is 1, the size of the pre-allocated trace data block is 12 octets (size) and only the first IOAM data (bit 0: hop_limit + node id) is included in the trace (type) represented as a bitfield. The reason why the in-transit (IPv6-in-IPv6 encapsulation) use case is not implemented is explained on the patchset cover. Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv6: ioam: IOAM Generic Netlink APIJustin Iurman2021-07-213-2/+624
| | | | | | | | | | | | | | | | | | | Add Generic Netlink commands to allow userspace to configure IOAM namespaces and schemas. The target is iproute2 and the patch is ready. It will be posted as soon as this patchset is merged. Here is an overview: $ ip ioam Usage: ip ioam { COMMAND | help } ip ioam namespace show ip ioam namespace add ID [ data DATA32 ] [ wide DATA64 ] ip ioam namespace del ID ip ioam schema show ip ioam schema add ID DATA ip ioam schema del ID ip ioam namespace set ID schema { ID | none } Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv6: ioam: Data plane support for Pre-allocated TraceJustin Iurman2021-07-2113-1/+557
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement support for processing the IOAM Pre-allocated Trace with IPv6, see [1] and [2]. Introduce a new IPv6 Hop-by-Hop TLV option, see IANA [3]. A new per-interface sysctl is introduced. The value is a boolean to accept (=1) or ignore (=0, by default) IPv6 IOAM options on ingress for an interface: - net.ipv6.conf.XXX.ioam6_enabled Two other sysctls are introduced to define IOAM IDs, represented by an integer. They are respectively per-namespace and per-interface: - net.ipv6.ioam6_id - net.ipv6.conf.XXX.ioam6_id The value of the first one represents the IOAM ID of the node itself (u32; max and default value = U32_MAX>>8, due to hop limit concatenation) while the other represents the IOAM ID of an interface (u16; max and default value = U16_MAX). Each "ioam6_id" sysctl has a "_wide" equivalent: - net.ipv6.ioam6_id_wide - net.ipv6.conf.XXX.ioam6_id_wide The value of the first one represents the wide IOAM ID of the node itself (u64; max and default value = U64_MAX>>8, due to hop limit concatenation) while the other represents the wide IOAM ID of an interface (u32; max and default value = U32_MAX). The use of short and wide equivalents is not exclusive, a deployment could choose to leverage both. For example, net.ipv6.conf.XXX.ioam6_id (short format) could be an identifier for a physical interface, whereas net.ipv6.conf.XXX.ioam6_id_wide (wide format) could be an identifier for a logical sub-interface. Documentation about new sysctls is provided at the end of this patchset. Two relativistic hash tables are used: one for IOAM namespaces, the other for IOAM schemas. A namespace can only have a single active schema and a schema can only be attached to a single namespace (1:1 relationship). [1] https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options [2] https://tools.ietf.org/html/draft-ietf-ippm-ioam-data [3] https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: David S. Miller <davem@davemloft.net>
* uapi: IPv6 IOAM headers definitionJustin Iurman2021-07-211-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides the IPv6 IOAM option header [1] as well as the IOAM Trace header [2]. An IOAM option must be 4n-aligned. Here is an overview of a Hop-by-Hop with an IOAM Trace option: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next header | Hdr Ext Len | Padding | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Reserved | IOAM Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | NodeLen | Flags | RemainingLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM-Trace-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | | | | node data [n] | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | | a | node data [n-1] | t | | a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p | | a | node data [1] | c | | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | node data [0] | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ The IOAM option header starts at "Option Type" and ends after "IOAM Type". The IOAM Trace header starts at "Namespace-ID" and ends after "IOAM-Trace-Type/Reserved". IOAM Type: either Pre-allocated Trace (=0), Incremental Trace (=1), Proof-of-Transit (=2) or Edge-to-Edge (=3). Note that both the Pre-allocated Trace and the Incremental Trace look the same. The two others are not implemented. Namespace-ID: IOAM namespace identifier, not to be confused with network namespaces. It adds further context to IOAM options and associated data, and allows devices which are IOAM capable to determine whether IOAM options must be processed or ignored. It can also be used by an operator to distinguish different operational domains or to identify different sets of devices. NodeLen: Length of data added by each node. It depends on the Trace Type. Flags: Only the Overflow (O) flag for now. The O flag is set by a transit node when there are not enough octets left to record its data. RemainingLen: Remaining free space to record data. IOAM-Trace-Type: Bit field where each bit corresponds to a specific kind of IOAM data. See [2] for a detailed list. [1] https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options [2] https://tools.ietf.org/html/draft-ietf-ippm-ioam-data Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: switchdev: recurse into __switchdev_handle_fdb_del_to_deviceVladimir Oltean2021-07-211-4/+4
| | | | | | | | | | | | | | | | | The difference between __switchdev_handle_fdb_del_to_device and switchdev_handle_del_to_device is that the former takes an extra orig_dev argument, while the latter starts with dev == orig_dev. We should recurse into the variant that does not lose the orig_dev along the way. This is relevant when deleting FDB entries pointing towards a bridge (dev changes to the lower interfaces, but orig_dev shouldn't). The addition helper already recurses properly, just the deletion one doesn't. Fixes: 8ca07176ab00 ("net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: switchdev: remove stray semicolon in switchdev_handle_fdb_del_to_device ↵Vladimir Oltean2021-07-211-1/+1
| | | | | | | | | | | | | | | shim With the semicolon at the end, the compiler sees the shim function as a declaration and not as a definition, and warns: 'switchdev_handle_fdb_del_to_device' declared 'static' but never defined Reported-by: kernel test robot <lkp@intel.com> Fixes: 8ca07176ab00 ("net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: at803x: finish the phy id checking simplificationVladimir Oltean2021-07-211-1/+1
| | | | | | | | | | | The blamed commit was probably not tested on net-next, since it did not refactor the extra phy id check introduced in commit b856150c8098 ("net: phy: at803x: mask 1000 Base-X link mode"). Fixes: 8887ca5474bd ("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>
* net: phylink: cleanup ksettings_setRussell King (Oracle)2021-07-211-7/+9
| | | | | | | | | | 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: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch '1GbE' of ↵David S. Miller2021-07-2011-186/+262
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 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: David S. Miller <davem@davemloft.net>
| * igc: Increase timeout value for Speed 100/1000/2500Muhammad Husaini Zulkifli2021-07-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * igc: Set QBVCYCLET_S to 0 for TSN Basic SchedulingMuhammad Husaini Zulkifli2021-07-201-1/+1
| | | | | | | | | | | | | | | | | | 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: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * igc: Remove phy->type checkingSasha Neftin2021-07-201-11/+4
| | | | | | | | | | | | | | | | | | | | | | 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 <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * igc: Remove _I_PHY_ID checkingSasha Neftin2021-07-203-15/+4
| | | | | | | | | | | | | | | | | | | | 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 <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * igc: Check if num of q_vectors is smaller than max before array accessSasha Neftin2021-07-201-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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: 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>
| * net/e1000e: Fix spelling mistake "The" -> "This"Tree Davies2021-07-201-1/+1
| | | | | | | | | | | | | | There is a spelling mistake in the comment block. Signed-off-by: Tree Davies <tdavies@darkphysics.net> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * e1000e: Add space to the debug printSasha Neftin2021-07-201-2/+4
| | | | | | | | | | | | | | | | Minor fixes to allow debug prints more readable. Signed-off-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>
| * e1000e: Add support for the next LOM generationSasha Neftin2021-07-202-0/+8
| | | | | | | | | | | | | | | | | | | | 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 <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * e1000e: Add support for Lunar LakeSasha Neftin2021-07-205-0/+21
| | | | | | | | | | | | | | | | | | | | 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 <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * e1000e: Additional PHY power saving in S0ixSasha Neftin2021-07-201-0/+6
| | | | | | | | | | | | | | | | | | | | 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 <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * e1000e: Add polling mechanism to indicate CSME DPG exitSasha Neftin2021-07-203-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <sasha.neftin@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * e1000e: Add handshake with the CSME to support S0ixSasha Neftin2021-07-202-154/+176
| | | | | | | | | | | | | | | | | | | | | | | | 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: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-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>
* | arm64: dts: imx8mp: change interrupt order per dt-bindingJoakim Zhang2021-07-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
* | dt-bindings: net: imx-dwmac: convert imx-dwmac bindings to yamlJoakim Zhang2021-07-202-56/+93
| | | | | | | | | | | | | | | | | | | | | | 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 <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | dt-bindings: net: snps,dwmac: add missing DWMAC IP versionJoakim Zhang2021-07-201-0/+3
|/ | | | | | | | | | | | 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: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: at803x: simplify custom phy id matchingRussell King2021-07-201-11/+5
| | | | | | | | | | | | | | | | | | 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: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: marvell: clean up trigraph warning on ??! stringColin Ian King2021-07-201-1/+1
| | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
* atm: idt77252: clean up trigraph warning on ??) stringColin Ian King2021-07-201-1/+1
| | | | | | | | | | | | 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: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: intel-xway: Add RGMII internal delay configurationMartin Schiller2021-07-201-0/+76
| | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
* net: phylink: add phy change pause mode debugRussell King (Oracle)2021-07-201-2/+3
| | | | | | | | Augment the phy link debug prints with the pause state. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: mvpp2: deny disabling autoneg for 802.3z modesRussell King (Oracle)2021-07-201-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Marek Behún <kabel@kernel.org> Acked-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: mvneta: deny disabling autoneg for 802.3z modesRussell King (Oracle)2021-07-201-6/+14
| | | | | | | | | | | | | | | | | | | | | | | 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: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipv4: add capability check for net administrationYang Yang2021-07-201-3/+7
| | | | | | | | | | | | 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 <davem@davemloft.net>
* Merge branch 'qcom-dts-updates'David S. Miller2021-07-203-8/+58
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
| * arm64: dts: qcom: sc7180: define ipa_fw_mem nodeAlex Elder2021-07-201-0/+5
| | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
| * arm64: dts: qcom: sc7280: add IPA informationAlex Elder2021-07-201-0/+43
| | | | | | | | | | | | | | | | 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 <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * dt-bindings: net: qcom,ipa: make imem interconnect optionalAlex Elder2021-07-201-8/+10
|/ | | | | | | | | | | 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 <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipa: fix IPA v4.11 interconnect dataAlex Elder2021-07-201-9/+4
| | | | | | | | | | | | 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: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* dt-bindings: net: fec: Fix indentationFabio Estevam2021-07-201-5/+5
| | | | | | | | | | | 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: Fabio Estevam <festevam@gmail.com> Reviewed-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'fdb-fanout'David S. Miller2021-07-204-105/+365
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
| * net: dsa: use switchdev_handle_fdb_{add,del}_to_deviceVladimir Oltean2021-07-202-105/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICEVladimir Oltean2021-07-202-0/+246
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: switchdev: introduce helper for checking dynamically learned FDB entriesVladimir Oltean2021-07-202-1/+7
|/ | | | | | | | | | 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: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: add Maxlinear GPY115/21x/24x driverXu Liang2021-07-204-0/+741
| | | | | | | | | | | | 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: Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: add API to read 802.3-c45 IDsXu Liang2021-07-202-0/+15
| | | | | | | | | | 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: Xu Liang <lxu@maxlinear.com> Acked-by: Hauke Mehrtens <hmehrtens@maxlinear.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'tag_8021q-cross-chip'David S. Miller2021-07-2017-1131/+455
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David S. Miller <davem@davemloft.net>
| * net: dsa: tag_8021q: add proper cross-chip notifier supportVladimir Oltean2021-07-206-340/+256
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: tag_8021q: manage RX VLANs dynamically at bridge join/leave timeVladimir Oltean2021-07-203-38/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There has been at least one wasted opportunity for tag_8021q to be used by a driver: https://patchwork.ozlabs.org/project/netdev/patch/20200710113611.3398-3-kurt@linutronix.de/#2484272 because of a design decision: the declared purpose of tag_8021q is to offer source port/switch identification for a tagging driver for packets coming from a switch with no hardware DSA tagging support. It is not intended to provide VLAN-based port isolation, because its first user, sja1105, had another mechanism for bridging domain isolation, the L2 Forwarding Table. So even if 2 ports are in the same VLAN but they are separated via the L2 Forwarding Table, they will not communicate with one another. The L2 Forwarding Table is managed by the sja1105_bridge_join() and sja1105_bridge_leave() methods. As a consequence, today tag_8021q does not bother too much with hooking into .port_bridge_join() and .port_bridge_leave() because that would introduce yet another degree of freedom, it just iterates statically through all ports of a switch and adds the RX VLAN of one port to all the others. In this way, whenever .port_bridge_join() is called, bridging will magically work because the RX VLANs are already installed everywhere they need to be. This is not to say that the reason for the change in this patch is to satisfy the hellcreek and similar use cases, that is merely a nice side effect. Instead it is to make sja1105 cross-chip links work properly over a DSA link. For context, sja1105 today supports a degenerate form of cross-chip bridging, where the switches are interconnected through their CPU ports ("disjoint trees" topology). There is some code which has been generalized into dsa_8021q_crosschip_link_{add,del}, but it is not enough, and frankly it is impossible to build upon that. Real multi-switch DSA trees, like daisy chains or H trees, which have actual DSA links, do not work. The problem is that sja1105 is unlike mv88e6xxx, and does not have a PVT for cross-chip bridging, which is a table by which the local switch can select the forwarding domain for packets from a certain ingress switch ID and source port. The sja1105 switches cannot parse their own DSA tags, because, well, they don't really have support for DSA tags, it's all VLANs. So to make something like cross-chip bridging between sw0p0 and sw1p0 to work over the sw0p3/sw1p3 DSA link to work with sja1105 in the topology below: | | sw0p0 sw0p1 sw0p2 sw0p3 sw1p3 sw1p2 sw1p1 sw1p0 [ user ] [ user ] [ cpu ] [ dsa ] ---- [ dsa ] [ cpu ] [ user ] [ user ] we need to ask ourselves 2 questions: (1) how should the L2 Forwarding Table be managed? (2) how should the VLAN Lookup Table be managed? i.e. what should prevent packets from going to unwanted ports? Since as mentioned, there is no PVT, the L2 Forwarding Table only contains forwarding rules for local ports. So we can say "all user ports are allowed to forward to all CPU ports and all DSA links". If we allow forwarding to DSA links unconditionally, this means we must prevent forwarding using the VLAN Lookup Table. This is in fact asymmetric with what we do for tag_8021q on ports local to the same switch, and it matters because now that we are making tag_8021q a core DSA feature, we need to hook into .crosschip_bridge_join() to add/remove the tag_8021q VLANs. So for symmetry it makes sense to manage the VLANs for local forwarding in the same way as cross-chip forwarding. Note that there is a very precise reason why tag_8021q hooks into dsa_switch_bridge_join() which acts at the cross-chip notifier level, and not at a higher level such as dsa_port_bridge_join(). We need to install the RX VLAN of the newly joining port into the VLAN table of all the existing ports across the tree that are part of the same bridge, and the notifier already does the iteration through the switches for us. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}registerVladimir Oltean2021-07-204-42/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, setting up tag_8021q is a 2-step operation for a driver, first the context structure needs to be created, then the VLANs need to be installed on the ports. A similar thing is true for teardown. Merge the 2 steps into the register/unregister methods, to be as transparent as possible for the driver as to what tag_8021q does behind the scenes. This also gets rid of the funny "bool setup == true means setup, == false means teardown" API that tag_8021q used to expose. Note that dsa_tag_8021q_register() must be called at least in the .setup() driver method and never earlier (like in the driver probe function). This is because the DSA switch tree is not initialized at probe time, and the cross-chip notifiers will not work. For symmetry with .setup(), the unregister method should be put in .teardown(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: make tag_8021q operations part of the coreVladimir Oltean2021-07-205-30/+17
| | | | | | | | | | | | | | | | | | | | Make tag_8021q a more central element of DSA and move the 2 driver specific operations outside of struct dsa_8021q_context (which is supposed to hold dynamic data and not really constant function pointers). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: let the core manage the tag_8021q contextVladimir Oltean2021-07-207-100/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The basic problem description is as follows: Be there 3 switches in a daisy chain topology: | 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 ] The CPU will not be able to ping through the user ports of the bottom-most switch (like for example sw2p0), simply because tag_8021q was not coded up for this scenario - it has always assumed DSA switch trees with a single switch. To add support for the topology above, we must admit that the RX VLAN of sw2p0 must be added on some ports of switches 0 and 1 as well. This is in fact a textbook example of thing that can use the cross-chip notifier framework that DSA has set up in switch.c. There is only one problem: core DSA (switch.c) is not able right now to make the connection between a struct dsa_switch *ds and a struct dsa_8021q_context *ctx. Right now, it is drivers who call into tag_8021q.c and always provide a struct dsa_8021q_context *ctx pointer, and tag_8021q.c calls them back with the .tag_8021q_vlan_{add,del} methods. But with cross-chip notifiers, it is possible for tag_8021q to call drivers without drivers having ever asked for anything. A good example is right above: when sw2p0 wants to set itself up for tag_8021q, the .tag_8021q_vlan_add method needs to be called for switches 1 and 0, so that they transport sw2p0's VLANs towards the CPU without dropping them. So instead of letting drivers manage the tag_8021q context, add a tag_8021q_ctx pointer inside of struct dsa_switch, which will be populated when dsa_tag_8021q_register() returns success. The patch is fairly long-winded because we are partly reverting commit 5899ee367ab3 ("net: dsa: tag_8021q: add a context structure") which made the driver-facing tag_8021q API use "ctx" instead of "ds". Now that we can access "ctx" directly from "ds", this is no longer needed. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 08:42:28 +0000