summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/microchip
AgeCommit message (Collapse)Author
2025-01-16net: lan743x: convert to phylink managed EEERussell King (Oracle)
Convert lan743x to phylink managed EEE: - Set the lpi_capabilties. - Move the call to lan743x_mac_eee_enable() into the enable/disable tx_lpi functions. - Ensure that EEEEN is clear during probe. - Move the setting of the LPI timer into mac_enable_tx_lpi(). - Move reading of LPI timer to phylink initialisation to set the default timer value. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/E1tYAEB-0014QB-4s@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: lan743x: use netdev in lan743x_phylink_mac_link_down()Russell King (Oracle)
Use the netdev that we already have in lan743x_phylink_mac_link_down(). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/E1tYAE5-0014Q5-Up@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: lan969x: add FDMA implementationDaniel Machon
The lan969x switch device supports manual frame injection and extraction to and from the switch core, using a number of injection and extraction queues. This technique is currently supported, but delivers poor performance compared to Frame DMA (FDMA). This lan969x implementation of FDMA, hooks into the existing FDMA for Sparx5, but requires its own RX and TX handling, as lan969x does not support the same native cache coherency that Sparx5 does. Effectively, this means that we are going to use the DMA mapping API for mapping and unmapping TX buffers. The RX loop will utilize the page pool API for efficient RX handling. Other than that, the implementation is largely the same, and utilizes the FDMA library for DCB and DB handling. Some numbers: Manual injection/extraction (before this series): // iperf3 -c 1.0.1.1 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.02 sec 345 MBytes 289 Mbits/sec sender [ 5] 0.00-10.06 sec 345 MBytes 288 Mbits/sec receiver FDMA (after this series): // iperf3 -c 1.0.1.1 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.03 sec 1.10 GBytes 940 Mbits/sec sender [ 5] 0.00-10.07 sec 1.10 GBytes 936 Mbits/sec receiver Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-5-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: ops out certain FDMA functionsDaniel Machon
We are going to implement the RX and TX paths a bit differently on lan969x and therefore need to introduce new ops for FDMA functions: init, deinit, xmit and poll. Assign the Sparx5 equivalents for these and update the code throughout. Also add a 'struct net_device' argument to the xmit() function, as we will be needing that for lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-4-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: activate FDMA tx in start()Daniel Machon
The function sparx5_fdma_tx_activate() is responsible for configuring the TX FDMA instance and activating the channel. TX activation has previously been done in the xmit() function, when the first frame is transmitted. Now that we have separate functions for starting and stopping the FDMA, it seems reasonable to move the TX activation to the start function. This change has no implications on the functionality. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-3-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: split sparx5_fdma_{start(),stop()}Daniel Machon
The two functions: sparx5_fdma_{start(),stop()} are responsible for a number of things, namely: allocation and initialization of FDMA buffers, activation FDMA channels in hardware and activation of the NAPI instance. This patch splits the buffer allocation and initialization into init and deinit functions, and the channel and NAPI activation into start and stop functions. This serves two purposes: 1) the start() and stop() functions can be reused for lan969x and 2) prepares for future MTU change support, where we must be able to stop and start the FDMA channels and NAPI instance, without free'ing and reallocating the FDMA buffers. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-2-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: enable FDMA on lan969xDaniel Machon
In a previous series, we made sure that FDMA was not initialized and started on lan969x. Now that we are going to support it, undo that change. In addition, make sure the chip ID check is only applicable on Sparx5, as this is a check that is only relevant on this platform. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-1-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: pass neg_mode into c22 state decoderRussell King (Oracle)
Pass the current neg_mode into phylink_mii_c22_pcs_get_state() and phylink_mii_c22_pcs_decode_state(). Update all users of phylink PCS that use these functions. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeY-000Et9-8g@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: pass neg_mode into .pcs_get_state() methodRussell King (Oracle)
Pass the current neg_mode into the .pcs_get_state() method. Update all users of phylink PCS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeT-000Et3-4L@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: lan969x: add RGMII implementationDaniel Machon
The lan969x switch device includes two RGMII port interfaces (port 28 and 29) supporting data speeds of 1 Gbps, 100 Mbps and 10 Mbps. MAC level delays are configurable through the HSIO_WRAP target, by choosing a phase shift selector, corresponding to a certain time delay in nano seconds. Add new file: lan969x_rgmii.c that contains the implementation for configuring the RGMII port devices. MAC level delays are configured using the "{rx,tx}-internal-delay-ps" properties. These properties must be specified independently of the phy-mode. If missing, or set to zero, the MAC will not apply any delay. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-8-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: lan969x: add RGMII registersDaniel Machon
Configuration of RGMII is done by configuring the GPIO and clock settings in the HSIOWRAP target, and configuring the RGMII port devices in the DEVRGMII target. Both targets contain registers replicated for the number of RGMII port devices, which is two. Add said targets and register macros required to configure RGMII. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-7-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: sparx5: verify RGMII speedsDaniel Machon
When doing a port config, we verify the port speed against the PHY mode and supported speeds of that PHY mode. Add checks for the four RGMII phy modes: RGMII, RGMII_ID, RGMII_TXID and RGMII_RXID. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-6-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: sparx5: only return PCS for modes that require itDaniel Machon
The RGMII ports have no PCS to configure. Make sure we only return the PCS for port modes that require it. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-5-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: sparx5: skip low-speed configuration when port is RGMIIDaniel Machon
When doing a port config, we configure low-speed port devices, among other things. We have a check to ensure, that the device is indeed a low-speed device, an not a high-speed device. Add an additional check, to ensure that the device is not an RGMII device. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-4-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: sparx5: use is_port_rgmii() throughoutDaniel Machon
Now that we can check if a given port is an RGMII port, use it in the following cases: - To set RGMII PHY modes for RGMII port devices. - To avoid checking for a SerDes node in the devicetree, when the port is an RGMII port. - To bail out of sparx5_port_init() when the common configuration is done. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-3-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: sparx5: add function for RGMII port checkDaniel Machon
The lan969x device contains two RGMII port interfaces, sitting at port 28 and 29. Add function: is_port_rgmii() to the match data ops, that checks if a given port is an RGMII port or not. For Sparx5, this function always returns false. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-2-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-23net: sparx5: do some preparation workDaniel Machon
The sparx5_port_init() does initial configuration of a variety of different features and options for each port. Some are shared for all types of devices, some are not. As it is now, common configuration is done after configuration of low-speed devices. This will not work when adding RGMII support in a subsequent patch. In preparation for lan969x RGMII support, move a block of code, that configures 2g5 devices, down. This ensures that the configuration common to all devices is done before configuration of 2g5, 5g, 10g and 25g devices. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Tested-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241220-sparx5-lan969x-switch-driver-4-v5-1-fa8ba5dff732@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-09net: sparx5: fix the maximum frame length registerDaniel Machon
On port initialization, we configure the maximum frame length accepted by the receive module associated with the port. This value is currently written to the MAX_LEN field of the DEV10G_MAC_ENA_CFG register, when in fact, it should be written to the DEV10G_MAC_MAXLEN_CFG register. Fix this. Fixes: 946e7fd5053a ("net: sparx5: add port module support") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09net: sparx5: fix default value of monitor portsDaniel Machon
When doing port mirroring, the physical port to send the frame to, is written to the FRMC_PORT_VAL field of the QFWD_FRAME_COPY_CFG register. This field is 7 bits wide on sparx5 and 6 bits wide on lan969x, and has a default value of 65 and 30, respectively (the number of front ports). On mirror deletion, we set the default value of the monitor port to 65 for this field, in case no more ports exists for the mirror. Needless to say, this will not fit the 6 bits on lan969x. Fix this by correctly using the n_ports constant instead. Fixes: 3f9e46347a46 ("net: sparx5: use SPX5_CONST for constants which already have a symbol") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09net: sparx5: fix FDMA performance issueDaniel Machon
The FDMA handler is responsible for scheduling a NAPI poll, which will eventually fetch RX packets from the FDMA queue. Currently, the FDMA handler is run in a threaded context. For some reason, this kills performance. Admittedly, I did not do a thorough investigation to see exactly what causes the issue, however, I noticed that in the other driver utilizing the same FDMA engine, we run the FDMA handler in hard IRQ context. Fix this performance issue, by running the FDMA handler in hard IRQ context, not deferring any work to a thread. Prior to this change, the RX UDP performance was: Interval Transfer Bitrate Jitter 0.00-10.20 sec 44.6 MBytes 36.7 Mbits/sec 0.027 ms After this change, the rx UDP performance is: Interval Transfer Bitrate Jitter 0.00-9.12 sec 1.01 GBytes 953 Mbits/sec 0.020 ms Fixes: 10615907e9b5 ("net: sparx5: switchdev: adding frame DMA functionality") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09net: lan969x: fix the use of spin_lock in PTP handlerDaniel Machon
We are mixing the use of spin_lock() and spin_lock_irqsave() functions in the PTP handler of lan969x. Fix this by correctly using the _irqsave variants. Fixes: 24fe83541755 ("net: lan969x: add PTP handler function") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> [1]: https://lore.kernel.org/netdev/20241024-sparx5-lan969x-switch-driver-2-v2-10-a0b5fae88a0f@microchip.com/ Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09net: lan969x: fix cyclic dependency reported by depmodDaniel Machon
Depmod reports a cyclic dependency between modules sparx5-switch.ko and lan969x-switch.ko: depmod: ERROR: Cycle detected: lan969x_switch -> sparx5_switch -> lan969x_switch depmod: ERROR: Found 2 modules in dependency cycles! make[2]: *** [scripts/Makefile.modinst:132: depmod] Error 1 make: *** [Makefile:224: __sub-make] Error 2 This makes sense, as they both require symbols from each other. Fix this by compiling lan969x support into the sparx5-switch.ko module. In order to do this, in a sensible way, we move the lan969x/ dir into the sparx5/ dir and do some code cleanup of code that is no longer required. After this patch, depmod will no longer complain, as lan969x support is compiled into the sparx5-swicth.ko module, and can no longer be compiled as a standalone module. Fixes: 98a01119608d ("net: sparx5: add compatible string for lan969x") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-24net: microchip: vcap: Add typegroup table terminators in kunit testsGuenter Roeck
VCAP API unit tests fail randomly with errors such as # vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:387 Expected 134 + 7 == iter.offset, but 134 + 7 == 141 (0x8d) iter.offset == 17214 (0x433e) # vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:388 Expected 5 == iter.reg_idx, but iter.reg_idx == 702 (0x2be) # vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:389 Expected 11 == iter.reg_bitpos, but iter.reg_bitpos == 15 (0xf) # vcap_api_iterator_init_test: pass:0 fail:1 skip:0 total:1 Comments in the code state that "A typegroup table ends with an all-zero terminator". Add the missing terminators. Some of the typegroups did have a terminator of ".offset = 0, .width = 0, .value = 0,". Replace those terminators with "{ }" (no trailing ',') for consistency and to excplicitly state "this is a terminator". Fixes: 67d637516fa9 ("net: microchip: sparx5: Adding KUNIT test for the VCAP API") Cc: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20241119213202.2884639-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-14net: sparx5: add missing lan969x Kconfig dependencyArnd Bergmann
The sparx5 switchdev driver can be built either with or without support for the Lan969x switch. However, it cannot be built-in when the lan969x driver is a loadable module because of a link-time dependency: arm-linux-gnueabi-ld: drivers/net/ethernet/microchip/sparx5/sparx5_main.o:(.rodata+0xd44): undefined reference to `lan969x_desc' Add a Kconfig dependency to reflect this in Kconfig, allowing all the valid configurations but forcing sparx5 to be a loadable module as well if lan969x is. Fixes: 98a01119608d ("net: sparx5: add compatible string for lan969x") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241113115513.4132548-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: lan969x: add VCAP configuration dataDaniel Machon
Add configuration data (for consumption by the VCAP API) for the four VCAP's that we are going to support. The following VCAP's will be supported: - VCAP CLM: (also known as IS0) is part of the analyzer and enables frame classification using VCAP functionality. - VCAP IS2: is part of ANA_ACL and enables access control lists, using VCAP functionality. - VCAP ES0: is part of the rewriter and enables rewriting of frames using VCAP functionality. - VCAP ES2: is part of EACL and enables egress access control lists using VCAP functionality The two VCAP's: CLM and IS2 use shared resources from the SUPER VCAP. The SUPER VCAP is a shared pool of 6 blocks that can be distributed freely among CLM and IS2. Each block in the pool has 3,072 addresses with entries, actions, and counters. ES0 and ES2 does not use shared resources. In the configuration data for lan969x CLM uses blocks 2-4 with a total of 6 lookups. IS2 uses blocks 0-1 with a total of 4 lookups. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-11-05net: lan969x: add autogenerated VCAP informationDaniel Machon
Platform VCAP data for each VCAP instance is auto-generated using an internal Microchip tool. The generated VCAP data contains information about keyfields, keyfield sets, actionfields, actionfield sets and typegroups, which in combination are used to encode and decode rules in the VCAP. Add the auto-generated VCAP file lan969x_vcap_ag_api.c and assign the two structs: lan969x_vcaps and lan969x_vcap_stats to the match data. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-11-05net: sparx5: execute sparx5_vcap_init() on lan969xDaniel Machon
The is_sparx5() check was introduced in an earlier series, to make sure the sparx5_vcap_init() was not executed on lan969x, as it was not implemented there yet. Now that it is, remove that check. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-11-05net: sparx5: add new VCAP constants to match dataDaniel Machon
In preparation for lan969x VCAP support, add the following three new VCAP constants to match data: - vcaps_cfg (contains configuration data for each VCAP). - vcaps (contains auto-generated information about VCAP keys and actions). - vcap_stats: (contains auto-generated string names of all the keys and actions) Add these constants to the Sparx5 match data constants and use them to initialize the VCAP's in sparx5_vcap_init(). Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-11-05net: sparx5: replace SPX5_PORTS with n_portsDaniel Machon
The Sparx5 VCAP implementation uses the SPX5_PORTS symbol to iterate over the 65 front ports of Sparx5. Replace the use with the n_ports constant from the match data, which translates to 65 of Sparx5 and 30 on lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-11-05net: sparx5: expose some sparx5 VCAP symbolsDaniel Machon
In preparation for lan969x VCAP support, expose the following symbols for use by the lan969x VCAP implementation: - The symbols SPARX5_*_LOOKUPS defines the number of lookups in each VCAP instance. These are the same for lan969x. Move them to the header file. - The struct sparx5_vcap_inst encapsulates information about a single VCAP instance. Move this struct to the header file and declare the sparx5_vcap_inst_cfg as extern. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-30net: sparx5: add feature supportDaniel Machon
Lan969x supports a number of different features, depending on the target. Add new field sparx5->features and initialize the features based on the target. Also add the function sparx5_has_feature() and use it throughout. For now, we only need to handle features: PSFP and PTP - more will come in the future. [1] https://www.microchip.com/en-us/product/lan9698 Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-15-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: sparx5: add compatible string for lan969xDaniel Machon
Add lan9691-switch compatible string to mchp_sparx5_match. Guard it with IS_ENABLED(CONFIG_LAN969X_SWITCH) to make sure Sparx5 can be compiled on its own. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-14-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: sparx5: use is_sparx5() macro throughoutDaniel Machon
Use the is_sparx5() macro (introduced in earlier series [1]), in places where we need to handle things a bit differently on lan969x. These places are: - in sparx5_dsm_calendar_update() we need to switch the calendar from a to b on lan969x. - in sparx5_start() we need to make sure the HSCH_SYS_CLK_PER register is only touched on Sparx5. - in sparx5_start() we need to disable VCAP and FDMA for lan969x (will come in later series). - in sparx5_mirror_port_get() we must make sure the ANA_AC_PROBE_PORT_CFG1 register is only read on Sparx5. - sparx5_netdev.c and sparx5_packet.c we need to use different IFH (Internal Frame Header) offsets for lan969x. - in sparx5_port_fifo_sz() we must bail out on lan969x. - in sparx5_port_config_low_set() we must configure the phase detection registers. - in sparx5_port_config() and sparx5_port_init() we must do some additional configuration of the port devices. - in sparx5_dwrr_conf_set() we must derive the scheduling layer [1] https://lore.kernel.org/netdev/20241004-b4-sparx5-lan969x-switch-driver-v2-8-d3290f581663@microchip.com/ Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-12-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: lan969x: add function for calculating the DSM calendarDaniel Machon
Lan969x has support for RedBox / HSR / PRP (not implemented yet). In order to accommodate for this in the future, we need to give lan969x it's own function for calculating the DSM calendar. The function calculates the calendar for each taxi bus. The calendar is used for bandwidth allocation towards the ports attached to the taxi bus. A calendar configuration consists of up-to 64 slots, which may be allocated to ports or left unused. Each slot accounts for 1 clock cycle. Also expose sparx5_cal_speed_to_value(), sparx5_get_port_cal_speed, sparx5_cal_bw and SPX5_DSM_CAL_EMPTY for use by lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-11-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: lan969x: add PTP handler functionDaniel Machon
Add PTP IRQ handler for lan969x. This is required, as the PTP registers are placed in two different targets on Sparx5 and lan969x. The implementation is otherwise the same as on Sparx5. Also, expose sparx5_get_hwtimestamp() for use by lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-10-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: lan969x: add lan969x ops to match dataDaniel Machon
Add a bunch of small lan969x ops in bulk. These ops are explained in detail in a previous series [1]. [1] https://lore.kernel.org/netdev/20241004-b4-sparx5-lan969x-switch-driver-v2-8-d3290f581663@microchip.com/ Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-9-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: lan969x: add constants to match dataDaniel Machon
Add the lan969x constants to match data. These are already used throughout the Sparx5 code (introduced in earlier series [1]), so no need to update any code use. [1] https://lore.kernel.org/netdev/20241004-b4-sparx5-lan969x-switch-driver-v2-0-d3290f581663@microchip.com/ Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-8-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: lan969x: add register diffs to match dataDaniel Machon
Add new file lan969x_regs.c that defines all the register differences for lan969x, and add it to the lan969x match data. GW_DEV2G5_PHASE_DETECTOR_CTRL, FP_DEV2G5_PHAD_CTRL_PHAD_ENA and FP_DEV2G5_PHAD_CTRL_PHAD_FAILED are required by the new register macros which was introduced earlier. Add these for Sparx5 also. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-7-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: lan969x: add match data for lan969xDaniel Machon
Add match data for lan969x, with initial fields for iomap, iomap_size and ioranges. Add new Kconfig symbol CONFIG_LAN969X_CONFIG for compiling the lan969x driver. It has been decided to give lan969x its own Kconfig symbol, as a considerable amount of code is needed, beside the Sparx5 code, to add full chip support (and more will be added in future series). Also this makes it possible to compile Sparx5 without lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-6-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: sparx5: add registers required by lan969xDaniel Machon
Lan969x will require a few additional registers for certain operations. Some are shared, some are not. Add these. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-5-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: sparx5: add sparx5 context pointer to a few functionsDaniel Machon
In preparation for lan969x, add the sparx5 context pointer to certain IFH (Internal Frame Header) functions. This is required, as the is_sparx5() function will be used here in a subsequent patch. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-4-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: sparx5: change frequency calculation for SDLB'sDaniel Machon
In preparation for lan969x, rework the function that calculates the SDLB (Service Dual Leacky Bucket) clock. This is required, as the HSCH_SYS_CLK_PER register is Sparx5-exclusive. Instead derive the clock from the core clock, using the sparx5_clk_period() function. The clock stays the same before and after this patch, only now, sparx5_sdlb_clk_hz_get() can be used for lan969x too. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-3-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: sparx5: change spx5_wr to spx5_rmw in cal update()Daniel Machon
In preparation for lan969x, use spx5_rmw() for enabling the update of the calendar. This is required to not overwrite the DSM_TAXI_CAL_CFG register, as an additional write will be added before this one, in a subsequent patch. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-2-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-30net: sparx5: add support for lan969x targets and core clockDaniel Machon
In preparation for lan969x, add lan969x targets to sparx5_target_chiptype and set the core clock frequency for these throughout. Lan969x only supports a core clock frequency of 328MHz. Also, set the policer update internal (pol_upd_int) matching the 328 MHz frequency of the lan969x targets. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20241024-sparx5-lan969x-switch-driver-2-v2-1-a0b5fae88a0f@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-21Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni
Cross-merge networking fixes after downstream PR (net-6.12-rc4). Conflicts: 107a034d5c1e ("net/mlx5: qos: Store rate groups in a qos domain") 1da9cfd6c41c ("net/mlx5: Unregister notifier on eswitch init failure") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-15net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()Jinjie Ruan
Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. unreferenced object 0xffffff80ca58b700 (size 192): comm "kunit_try_catch", pid 1215, jiffies 4294898264 hex dump (first 32 bytes): 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ backtrace (crc 9c09c3fe): [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80cc0b0400 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... backtrace (crc daf014e9): [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80cc0b0700 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... backtrace (crc 8d877792): [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80cc0b0900 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... backtrace (crc 34181e56): [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80cc0b0980 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... backtrace (crc 275fd9be): [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 [<000000001396a1a2>] test_add_def_fields+0xb0/0x100 [<000000006e7621f0>] vcap_val_rule+0xa98/0x13e8 [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] ret_from_fork+0x10/0x20 ...... Cc: stable@vger.kernel.org Fixes: a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test") Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20241014121922.1280583-1-ruanjinjie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-14net: lan743x: Remove duplicate checkJinjie Ruan
Since timespec64_valid() has been checked in higher layer pc_clock_settime(), the duplicate check in lan743x_ptpci_settime64() can be removed. Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20241009072302.1754567-3-ruanjinjie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-11net: sparx5: fix source port register when mirroringDaniel Machon
When port mirroring is added to a port, the bit position of the source port, needs to be written to the register ANA_AC_PROBE_PORT_CFG. This register is replicated for n_ports > 32, and therefore we need to derive the correct register from the port number. Before this patch, we wrongly calculate the register from portno / BITS_PER_BYTE, where the divisor ought to be 32, causing any port >=8 to be written to the wrong register. We fix this, by using do_div(), where the dividend is the register, the remainder is the bit position and the divisor is now 32. Fixes: 4e50d72b3b95 ("net: sparx5: add port mirroring implementation") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241009-mirroring-fix-v1-1-9ec962301989@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08net: sparx5: redefine internal ports and PGID's as offsetsDaniel Machon
Internal ports and PGID's are both defined relative to the number of front ports on Sparx5. This will not work on lan969x. Instead make them offsets to the number of front ports and add two helpers to retrieve them. Use the helpers throughout. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: add is_sparx5 macro and use it throughoutDaniel Machon
We dont want to ops out each time a function needs to do some platform specifics. In particular we have a few places, where it would be convenient to just branch out on the platform type. Add the function is_sparx5() and, initially, use it for: - register writes that should only be done on Sparx5 (QSYS_CAL_CTRL, CLKGEN_LCPLL1_CORE_CLK). - function calls that should only be done on Sparx5 (ethtool_op_get_ts_info()) - register writes that are chip-exclusive (MASK_CFG1/2, PGID_CFG1/2, these are replicated for n_ports >32 on Sparx5). The is_sparx5() function simply checks the target chip type, to determine if this is a Sparx5 SKU or not. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit (git 2.34.1) at 2025-06-14 23:38:14 +0000