summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/microchip/sparx5
AgeCommit message (Collapse)Author
2025-02-14net: remove phylink_pcs .neg_mode booleanRussell King (Oracle)
As all PCS are using the neg_mode parameter rather than the legacy an_mode, remove the ability to use the legacy an_mode. We remove the tests in the phylink code, unconditionally passing the PCS neg_mode parameter to PCS methods, and remove setting the flag from drivers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tidPn-0040hd-2R@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 .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-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 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: 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-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>
2024-10-08net: sparx5: ops out function for DSM calendar calculationDaniel Machon
The DSM (Disassembler) calendar grants each port access to internal busses. The configuration of the calendar is done differently on Sparx5 and lan969x. Therefore ops out the function that calculates the calendar. 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>
2024-10-08net: sparx5: ops out PTP IRQ handlerDaniel Machon
The PTP registers are located in two different register targets on Sparx5 and lan969x. We can't handle this with the register macros, so ops out the handler. 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>
2024-10-08net: sparx5: ops out function for setting the port muxDaniel Machon
Port muxing is configured based on the supported port modes. As these modes can differ on Sparx5 and lan969x we ops out the port muxing function. 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>
2024-10-08net: sparx5: ops out functions for getting certain array valuesDaniel Machon
Add getters for getting values in arrays: sdlb_groups and sparx5_hsch_max_group_rate and ops out the getters, as these arrays will differ on lan969x. 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>
2024-10-08net: sparx5: ops out chip port to device index/bit functionsDaniel Machon
The chip port device index and mode bit can be obtained using the port number. However the mapping of port number to chip device index and mode bit differs on Sparx5 and lan969x. Therefore ops out the function. 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>
2024-10-08net: sparx5: add ops to match dataDaniel Machon
Add new struct sparx5_ops, containing functions that needs to be different as the implementation differs on Sparx5 and lan969x. Initially we add functions for checking the port type (2g5, 5g, 10g or 25g) based on the port number. Update the code to use the ops instead of the platform specific functions. 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>
2024-10-08net: sparx5: use SPX5_CONST for constants which do not have a symbolDaniel Machon
Now that we have indentified all the chip constants, update the use of them where a symbol is not defined for the constant. 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: use SPX5_CONST for constants which already have a symbolDaniel Machon
Now that we have indentified all the chip constants, update the use of them where a symbol is already defined for the constant. 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 constants to match dataDaniel Machon
Add new struct sparx5_consts, containing all the chip constants that are known to be different for Sparx5 and lan969x. 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 *sparx5 argument to a few functionsDaniel Machon
The *sparx5 context pointer is required in functions that need to access platform constants (which will be added in a subsequent patch). Prepare for this by updating the prototype and use of such functions. 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>
2024-10-08net: sparx5: modify SPX5_PORTS_ALL macroDaniel Machon
In preparation for lan969x, we need to define the SPX5_PORTS_ALL macro as 70 (65 front ports + 5 internal ports). This is required as the SPX5_PORT_CPU will be redefined as an offset to the number of front ports, in a subsequent patch. 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 v1.2.3 (git 2.39.1) at 2025-07-31 23:04:06 +0000