aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2022-02-24can: mcp251xfd: prepare for multiple RX-FIFOsMarc Kleine-Budde4-9/+54
This patch prepares the driver to use more than one RX-FIFO. Having a bigger RX buffer is beneficial in high load situations, where the system temporarily cannot keep up reading CAN frames from the chip. Using a bigger RX buffer also allows to implement RX IRQ coalescing, which will be added in a later patch series. If using more than 1 RX-FIFO the driver has to figure out, which FIFOs have RX'ed CAN frames pending. This is indicated by a set bit in the RXIF register, which is positioned directly after the interrupt status register INT. If more than 1 RX-FIFO is used, the driver reads both registers in 1 transfer. The mcp251xfd_handle_rxif() function iterates over all RX rings and reads out the RX'ed CAN frames for for all pending FIFOs. To keep the logic for the 1 RX-FIFO only case in mcp251xfd_handle_rxif() simple, the driver marks that FIFO pending in mcp251xfd_ring_init(). The chip has a dedicated RX interrupt line to signal pending RX'ed frames. If connected to an input GPIO and the driver will skip the initial read of the interrupt status register (INT) and directly read the pending RX'ed frames if the line is active. The driver assumes the 1st RX-FIFO pending (a read of the RXIF register would re-introduce the skipped initial read of the INT register). Any other pending RX-FIFO will be served in the main interrupt handler. Link: https://lore.kernel.org/all/20220217103826.2299157-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: ring: update FIFO setup debug infoMarc Kleine-Budde1-16/+28
The recent change of the order of the TX and RX FIFOs is not reflected in the debug info of the FIFO setup. This patch adjust the order and additionally prints the base address of each FIFO. Since the mcp251xfd_ring_init() may fail due to wrongly configured FIFOs, printing of the FIFO setup is moved there. In case of an error it would not be printed in mcp251xfd_ring_init(). Link: https://lore.kernel.org/all/20220217103826.2299157-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: ring: mcp251xfd_ring_init(): checked RAM usage of ring setupMarc Kleine-Budde3-4/+16
With this patch the usage of the on-chip RAM is checked. In the current driver the FIFO setup is fixed and always fits into the RAM. With an upcoming patch series the ring and FIFO setup will be more dynamic. Although using more RAM than available should not happen, but add this safety check, just in case. Link: https://lore.kernel.org/all/20220217103826.2299157-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: ring: change order of TX and RX FIFOsMarc Kleine-Budde2-2/+2
This patch actually changes the order of the TX and RX FIFOs. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-5-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: ring: prepare to change order of TX and RX FIFOsMarc Kleine-Budde2-24/+25
This patch improves the initialization of the TX and RX rings. The initialization functions are now called with pointers to the next free address (in the on chip RAM) and next free hardware FIFO. The rings are initialized using these values and the pointers are modified to point to the next free elements. This means the order of the mcp251xfd_ring_init_*() functions specifies the order of the rings in the hardware FIFO. This makes it possible to change the order of the TX and RX FIFOs, which is done in the next patch. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-4-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_ring_init(): split ring_init into separate functionsMarc Kleine-Budde1-38/+62
This patch splits the initialization of the TEF, TX and RX FIFO in the mcp251xfd_ring_init() function into separate functions. This is a preparation patch to move the RX FIFO in front of the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: introduce struct mcp251xfd_tx_ring::nr and ::fifo_nr and make use of itMarc Kleine-Budde5-12/+26
This patch removes the hard coded assumption that the TX ring uses hardware FIFO 1. This allows the hardware FIFO 1 to be used for RX and the next free FIFO for TX. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: add support for internal PLLMarc Kleine-Budde2-20/+75
The PLL is enabled if the configured clock is less than or equal to 10 times the max clock frequency. The device will operate with two different SPI speeds. A slow speed determined by the clock without the PLL enabled, and a fast speed derived from the frequency with the PLL enabled. Link: https://lore.kernel.org/all/20220207131047.282110-16-mkl@pengutronix.de Link: https://lore.kernel.org/all/20201015124401.2766-3-mas@csselectronics.com Co-developed-by: Magnus Aagaard Sørensen <mas@csselectronics.com> Signed-off-by: Magnus Aagaard Sørensen <mas@csselectronics.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_register(): prepare to activate PLL after softresetMarc Kleine-Budde1-0/+6
If the PLL is needed it must be switched on after chip reset. This patch adds the required call to mcp251xfd_register(). Link: https://lore.kernel.org/all/20220207131047.282110-15-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_clock_init(): prepare for PLL support, wait for OSC readyMarc Kleine-Budde1-1/+8
This patch prepares the mcp251xfd_chip_clock_init() function for PLL support. If the PLL is needed is must be switched on after chip reset. This should be done in the mcp251xfd_chip_clock_init() function. Prepare this function to wait for the OSC and PLL to be ready. Link: https://lore.kernel.org/all/20220207131047.282110-14-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: __mcp251xfd_chip_set_mode(): prepare for PLL support: improve error handling and diagnosticsMarc Kleine-Budde1-9/+30
This patch prepares the __mcp251xfd_chip_set_mode() function for PLL support by adding more error checks and diagnostics. Link: https://lore.kernel.org/all/20220207131047.282110-13-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_wake(): renamed from mcp251xfd_chip_clock_enable()Marc Kleine-Budde1-9/+10
This patch renames mcp251xfd_chip_clock_enable() into mcp251xfd_chip_wake() as this function actually wakes the chip. Additionally the documentation is adopted. Link: https://lore.kernel.org/all/20220207131047.282110-12-mkl@pengutronix.de Co-developed-by: Magnus Aagaard Sørensen <mas@csselectronics.com> Signed-off-by: Magnus Aagaard Sørensen <mas@csselectronics.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_timestamp_init(): factor out into separate functionMarc Kleine-Budde1-0/+9
This patch factors out the timestamp initialization from the clock initialization. This is a preparation patch for the PLL support, where clock and timestamp init must be done separately. Link: https://lore.kernel.org/all/20220207131047.282110-11-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_softreset_check(): wait for OSC ready before accessing chipMarc Kleine-Budde1-17/+12
This patch changes the order of reading the Mode and Oscillator Ready bits. Instead of reading the Mode of the chip directly after reset, first wait for the oscillator to get ready and the chip to fully start up. Read the Mode after this. Link: https://lore.kernel.org/all/20220207131047.282110-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): prepare for PLL supportMarc Kleine-Budde1-2/+23
The function mcp251xfd_chip_wait_for_osc_ready() polls the Oscillator Control Register for the oscillator to get ready. By passing the appropriate parameters (osc_reference and osc_mask) it can also poll for PLL ready. This patch adjusts the error message if the Oscillator and/or PLL fail to get ready. Link: https://lore.kernel.org/all/20220207131047.282110-9-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): improve chip detection and error handlingMarc Kleine-Budde1-9/+15
The function mcp251xfd_chip_wait_for_osc_ready() polls the Oscillator Control Register for the oscillator to get ready. This is the first register the driver reads from. Reading implausible values (all bits set or unset) can be caused by the chip starting up after power on, waking up after sleep, or by the chip not being preset at all. Add check for implausible register content mcp251xfd_reg_invalid() to the regmap_read_poll_timeout() loop. In case of a regmap_read_poll_timeout() returns a fatal error (and not a timeout), forward it to the caller. As mcp251xfd_chip_wait_for_osc_ready() will be called after the probe function has finished, (currently during ifup), move error message about failed chip detection from there into the probe function. Link: https://lore.kernel.org/all/20220207131047.282110-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): factor out into separate functionMarc Kleine-Budde1-18/+27
This patch factors out mcp251xfd_chip_wait_for_osc_ready() into a separate function, it will be used in several places in the next patches. Link: https://lore.kernel.org/all/20220207131047.282110-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_stop(): convert to a void functionMarc Kleine-Budde1-3/+3
The mcp251xfd_chip_stop() function tries the best to stop the chip and put it into sleep mode. It continues, even if some intermediate steps fail. As none of the callers use the return value, let this function return void. Link: https://lore.kernel.org/all/20220207131047.282110-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_chip_sleep(): introduce function to bring chip into sleep modeMarc Kleine-Budde1-8/+13
This patch adds a new function to bring the chip into sleep mode, and replaces several occurrences of open coded variants. Link: https://lore.kernel.org/all/20220207131047.282110-5-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_unregister(): simplify runtime PM handlingMarc Kleine-Budde1-4/+4
The mcp251xfd driver supports runtime PM enabled kernels, but also works on !CONFIG_PM configurations. This patch simplifies the runtime PM handling in the mcp251xfd_unregister(). In the CONFIG_PM case, runtime PM has been enabled in the mcp251xfd_probe() function, so we can disable it here. For !CONFIG_PM builds call mcp251xfd_clks_and_vdd_disable() directly. Link: https://lore.kernel.org/all/20220207131047.282110-4-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_regmap_crc_read(): ignore CRC error only if solely OSC register is readMarc Kleine-Budde1-1/+1
MCP251XFD_REG_OSC is the first register the driver reads from. The chip may be in deep sleep and the SPI transfer (i.e. the assertion of the CS) will wake the chip up. This takes about 3ms. The CRC of this transfer is wrong, or there isn't any chip at all, in this case the CRC will be wrong, too. The driver ignores the CRC error and returns the read data to the caller. To avoid any confusion, this patch changes the mcp251xfd_regmap_crc_read() function to only ignore the CRC error if solely the OSC register is read. So when reading more than the OSC registers at once, CRC errors are not ignored. Link: https://lore.kernel.org/all/20220207131047.282110-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_reg_invalid(): rename from mcp251xfd_osc_invalid()Marc Kleine-Budde1-6/+6
This patch renames mcp251xfd_osc_invalid() to mcp251xfd_reg_invalid(), as it will be used for other registers than the "osc" register in a later patch. This patch also moves this function to more towards the beginning of the file, to be available for other functions, too. Link: https://lore.kernel.org/all/20220207131047.282110-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: etas_es58x: use BITS_PER_TYPE() instead of manual calculationVincent Mailhol1-1/+2
The input to the GENMASK() macro was calculated by hand. Replaced it with a dedicated macro: BITS_PER_TYPE() which does the exact same job. Link: https://lore.kernel.org/all/20220212130737.3008-1-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: xilinx_can: Add check for NAPI Poll functionSrinivas Neeli1-4/+5
Add check for NAPI poll function to avoid enabling interrupts with out completing the NAPI call. Link: https://lore.kernel.org/all/20220208162053.39896-1-srinivas.neeli@xilinx.com Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: softing: softing_netdev_open(): remove redundant ret variableMinghao Chi1-4/+1
Return value from softing_startstop() directly instead of taking this in another redundant variable. Link: https://lore.kernel.org/all/20220112080629.667191-1-chi.minghao@zte.com.cn Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: CGEL ZTE <cgel.zte@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: c_can: ethtool: use default drvinfoMarc Kleine-Budde1-9/+0
The ethtool core implements a default drvinfo. There's no need to replicate this in the driver, no additional information is added, so remove this and rely on the default. Link: https://lore.kernel.org/all/20220124215642.3474154-10-mkl@pengutronix.de Cc: Dario Binacchi <dariobin@libero.it> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: kvaser_usb: kvaser_usb_send_cmd(): remove redundant variable actual_lenMarc Kleine-Budde1-3/+1
The function usb_bulk_msg() can be called with a NULL pointer as the "actual_length" parameter. This patch removes this variable. Link: https://lore.kernel.org/all/20220124215642.3474154-9-mkl@pengutronix.de Cc: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: bittiming: mark function arguments and local variables as constMarc Kleine-Budde1-6/+6
This patch marks the arguments of some functions as well as some local variables as constant. Link: https://lore.kernel.org/all/20220124215642.3474154-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: bittiming: can_validate_bitrate(): simplify bit rate checkingMarc Kleine-Budde1-6/+2
This patch simplifies the validation of the fixed bit rates. If a supported bit rate is found, directly return 0. If no valid bit rate is found return -EINVAL; Link: https://lore.kernel.org/all/20220124215642.3474154-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-23octeontx2-pf: Vary completion queue event sizeSubbaraya Sundeep5-5/+21
Completion Queue Entry(CQE) is a descriptor written by hardware to notify software about the send and receive completion status. The CQE can be of size 128 or 512 bytes. A 512 bytes CQE can hold more receive fragments pointers compared to 128 bytes CQE. This patch enables to modify CQE size using: <ethtool -G cqe-size N>. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-23net/mlx5e: Fix VF min/max rate parameters interchange mistakeGal Pressman1-1/+1
The VF min and max rate were passed incorrectly and resulted in wrongly interchanging them. Fix the order of parameters in mlx5_esw_qos_set_vport_rate(). Fixes: d7df09f5e7b4 ("net/mlx5: E-switch, Enable vport QoS on demand") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: Add missing increment of countLama Kayal1-0/+1
Add mistakenly missing increment of count variable when looping over output buffer in mlx5e_self_test(). This resolves the issue of garbage values output when querying with self test via ethtool. before: $ ethtool -t eth2 The test result is PASS The test extra info: Link Test 0 Speed Test 1768697188 Health Test 758528120 Loopback Test 3288687 after: $ ethtool -t eth2 The test result is PASS The test extra info: Link Test 0 Speed Test 0 Health Test 0 Loopback Test 0 Fixes: 7990b1b5e8bd ("net/mlx5e: loopback test is not supported in switchdev mode") Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: MPLSoUDP decap, fix check for unsupported matchesMaor Dickman1-17/+11
Currently offload of rule on bareudp device require tunnel key in order to match on mpls fields and without it the mpls fields are ignored, this is incorrect due to the fact udp tunnel doesn't have key to match on. Fix by returning error in case flow is matching on tunnel key. Fixes: 72046a91d134 ("net/mlx5e: Allow to match on mpls parameters") Signed-off-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: Fix MPLSoUDP encap to use MPLS action informationMaor Dickman7-3/+32
Currently the MPLSoUDP encap builds the MPLS header using encap action information (tunnel id, ttl and tos) instead of the MPLS action information (label, ttl, tc and bos) which is wrong. Fix by storing the MPLS action information during the flow action parse and later using it to create the encap MPLS header. Fixes: f828ca6a2fb6 ("net/mlx5e: Add support for hw encapsulation of MPLS over UDP") Signed-off-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: Add feature check for set fec countersLama Kayal1-3/+3
Fec counters support is checked via the PCAM feature_cap_mask, bit 0: PPCNT_counter_group_Phy_statistical_counter_group. Add feature check to avoid faulty behavior. Fixes: 0a1498ebfa55 ("net/mlx5e: Expose FEC counters via ethtool") Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: TC, Skip redundant ct clear actionsRoi Dayan2-0/+8
Offload of ct clear action is just resetting the reg_c register. It's done by allocating modify hdr resources which is limited. Doing it multiple times is redundant and wasting modify hdr resources and if resources depleted the driver will fail offloading the rule. Ignore redundant ct clear actions after the first one. Fixes: 806401c20a0f ("net/mlx5e: CT, Fix multiple allocations and memleak of mod acts") Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Ariel Levkovich <lariel@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: TC, Reject rules with forward and drop actionsRoi Dayan1-0/+6
Such rules are redundant but allowed and passed to the driver. The driver does not support offloading such rules so return an error. Fixes: 03a9d11e6eeb ("net/mlx5e: Add TC drop and mirred/redirect action parsing for SRIOV offloads") Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Oz Shlomo <ozsh@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: TC, Reject rules with drop and modify hdr actionRoi Dayan1-0/+6
This kind of action is not supported by firmware and generates a syndrome. kernel: mlx5_core 0000:08:00.0: mlx5_cmd_check:777:(pid 102063): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x8708c3) Fixes: d7e75a325cb2 ("net/mlx5e: Add offloading of E-Switch TC pedit (header re-write) actions") Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Oz Shlomo <ozsh@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: kTLS, Use CHECKSUM_UNNECESSARY for device-offloaded packetsTariq Toukan1-1/+2
For RX TLS device-offloaded packets, the HW spec guarantees checksum validation for the offloaded packets, but does not define whether the CQE.checksum field matches the original packet (ciphertext) or the decrypted one (plaintext). This latitude allows architetctural improvements between generations of chips, resulting in different decisions regarding the value type of CQE.checksum. Hence, for these packets, the device driver should not make use of this CQE field. Here we block CHECKSUM_COMPLETE usage for RX TLS device-offloaded packets, and use CHECKSUM_UNNECESSARY instead. Value of the packet's tcp_hdr.csum is not modified by the HW, and it always matches the original ciphertext. Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support") Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5e: Fix wrong return value on ioctl EEPROM query failureGal Pressman1-1/+1
The ioctl EEPROM query wrongly returns success on read failures, fix that by returning the appropriate error code. Fixes: bb64143eee8c ("net/mlx5e: Add ethtool support for dump module EEPROM") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: Fix possible deadlock on rule deletionMaor Gottlieb1-0/+2
Add missing call to up_write_ref_node() which releases the semaphore in case the FTE doesn't have destinations, such in drop rule case. Fixes: 465e7baab6d9 ("net/mlx5: Fix deletion of duplicate rules") Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: Fix tc max supported prio for nic modeChris Mi1-0/+3
Only prio 1 is supported if firmware doesn't support ignore flow level for nic mode. The offending commit removed the check wrongly. Add it back. Fixes: 9a99c8f1253a ("net/mlx5e: E-Switch, Offload all chain 0 priorities when modify header and forward action is not supported") Signed-off-by: Chris Mi <cmi@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: Fix wrong limitation of metadata match on ecpfAriel Levkovich1-4/+0
Match metadata support check returns false for ecpf device. However, this support does exist for ecpf and therefore this limitation should be removed to allow feature such as stacked devices and internal port offloaded to be supported. Fixes: 92ab1eb392c6 ("net/mlx5: E-Switch, Enable vport metadata matching if firmware supports it") Signed-off-by: Ariel Levkovich <lariel@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: Update log_max_qp value to be 17 at mostMaher Sanalla1-1/+1
Currently, log_max_qp value is dependent on what FW reports as its max capability. In reality, due to a bug, some FWs report a value greater than 17, even though they don't support log_max_qp > 17. This FW issue led the driver to exhaust memory on startup. Thus, log_max_qp value is set to be no more than 17 regardless of what FW reports, as it was before the cited commit. Fixes: f79a609ea6bf ("net/mlx5: Update log_max_qp value to FW max capability") Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Avihai Horon <avihaih@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: DR, Fix the threshold that defines when pool sync is initiatedYevgeny Kliteynik1-4/+7
When deciding whether to start syncing and actually free all the "hot" ICM chunks, we need to consider the type of the ICM chunks that we're dealing with. For instance, the amount of available ICM for MODIFY_ACTION is significantly lower than the usual STE ICM, so the threshold should account for that - otherwise we can deplete MODIFY_ACTION memory just by creating and deleting the same modify header action in a continuous loop. This patch replaces the hard-coded threshold with a dynamic value. Fixes: 1c58651412bb ("net/mlx5: DR, ICM memory pools sync optimization") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: DR, Don't allow match on IP w/o matching on full ethertype/ip_versionYevgeny Kliteynik3-17/+45
Currently SMFS allows adding rule with matching on src/dst IP w/o matching on full ethertype or ip_version, which is not supported by HW. This patch fixes this issue and adds the check as it is done in DMFS. Fixes: 26d688e33f88 ("net/mlx5: DR, Add Steering entry (STE) utilities") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fteYevgeny Kliteynik1-7/+26
When adding a rule with 32 destinations, we hit the following out-of-band access issue: BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70 This patch fixes the issue by both increasing the allocated buffers to accommodate for the needed actions and by checking the number of actions to prevent this issue when a rule with too many actions is provided. Fixes: 1ffd498901c1 ("net/mlx5: DR, Increase supported num of actions to 32") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: DR, Cache STE shadow memoryYevgeny Kliteynik2-35/+79
During rule insertion on each ICM memory chunk we also allocate shadow memory used for management. This includes the hw_ste, dr_ste and miss list per entry. Since the scale of these allocations is large we noticed a performance hiccup that happens once malloc and free are stressed. In extreme usecases when ~1M chunks are freed at once, it might take up to 40 seconds to complete this, up to the point the kernel sees this as self-detected stall on CPU: rcu: INFO: rcu_sched self-detected stall on CPU To resolve this we will increase the reuse of shadow memory. Doing this we see that a time in the aforementioned usecase dropped from ~40 seconds to ~8-10 seconds. Fixes: 29cf8febd185 ("net/mlx5: DR, ICM pool memory allocator") Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: Update the list of the PCI supported devicesMeir Lichtinger1-0/+2
Add the upcoming BlueField-4 and ConnectX-8 device IDs. Fixes: 2e9d3e83ab82 ("net/mlx5: Update the list of the PCI supported devices") Signed-off-by: Meir Lichtinger <meirl@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: Add clarification on sync reset failureMoshe Shemesh4-19/+71
In case devlink reload action fw_activate failed in sync reset stage, use the new MFRL field reset_state to find why it failed and share this clarification with the user. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>