- 24 Feb, 2022 40 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Nguyen, Anthony L says: ==================== 10GbE Intel Wired LAN Driver Updates 2022-02-23 Yang Li fixes incorrect indenting as reported by smatch for ixgbevf. Piotr removes non-inclusive language from ixgbe driver. * '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ixgbe: Remove non-inclusive language ixgbevf: clean up some inconsistent indenting ==================== Link: https://lore.kernel.org/r/20220223185424.2129067-1-anthony.l.nguyen@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
David S. Miller authored
Merge tag 'linux-can-next-for-5.18-20220224' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== this is a pull request of 36 patches for net-next/master. The first 5 patches are by me and update various CAN DT bindings. Eric Dumazet's patch for the CAN GW replaces a costly synchronize_rcu() by a call_rcu(). The next 2 patches by me enhance the CAN bit rate handling, the bit rate checking is simplified and the arguments and local variables of functions are marked as const. A patch by me for the kvaser_usb driver removes a redundant variable. The next patch by me lets the c_can driver use the default ethtool drvinfo. Minghao Chi's patch for the softing driver removes a redundant variable. Srinivas Neeli contributes an enhancement for the xilinx_can NAPI poll function. Vincent Mailhol's patch for the etas_es58x driver converts to BITS_PER_TYPE() from of manual calculation. The next 23 patches target the mcp251xfd driver and are by me. The first 15 patches, add support for the internal PLL, which includes simplifying runtime PM handling, better chip detection and error handling after wakeup, and the PLL handling. The last 8 patches prepare the driver to support multiple RX-FIFOs and runtime configurable RX/TX rings. The actual runtime ring configuration via ethtool will be added in a later patch series. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marc Kleine-Budde authored
This patch introduces macros to define the number of supported TEF, RX and TX rings. As well as some assertions as sanity checks. Link: https://lore.kernel.org/all/20220217103826.2299157-9-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.comCo-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>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
can: mcp251xfd: __mcp251xfd_chip_set_mode(): prepare for PLL support: improve error handling and diagnostics 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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deCo-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>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
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.frSigned-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Srinivas Neeli authored
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.comSigned-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Minghao Chi authored
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.cnReported-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>
-
Marc Kleine-Budde authored
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>
-
Marc Kleine-Budde authored
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>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
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.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Eric Dumazet authored
Commit fb8696ab ("can: gw: synchronize rcu operations before removing gw job entry") added three synchronize_rcu() calls to make sure one rcu grace period was observed before freeing a "struct cgw_job" (which are tiny objects). This should be converted to call_rcu() to avoid adding delays in device / network dismantles. Use the rcu_head that was already in struct cgw_job, not yet used. Link: https://lore.kernel.org/all/20220207190706.1499190-1-eric.dumazet@gmail.comSigned-off-by: Eric Dumazet <edumazet@google.com> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Since commit | 1f923440 ("dt-bindings: can: add can-controller.yaml") there is a common CAN controller binding. Add this to the m_can binding. Link: https://lore.kernel.org/all/20220124220653.3477172-4-mkl@pengutronix.deReviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch fixes the indention of the table in the description of the bosch,mram-cfg property. Link: https://lore.kernel.org/all/20220217101111.2291151-1-mkl@pengutronix.deReviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Since Sriram Dash's email bounces, change the maintainer entry to Chandrasekar Ramakrishnan. Chandrasekar Ramakrishnan is already listed as a maintainer in the MAINTAINERS file. Link: https://lore.kernel.org/all/20220217113839.2311417-1-mkl@pengutronix.de Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Since commit | 1f923440 ("dt-bindings: can: add can-controller.yaml") there is a common CAN controller binding. Add this to the sun4i_can binding. Link: https://lore.kernel.org/all/20220124220653.3477172-3-mkl@pengutronix.de Cc: Evgeny Boger <boger@wirenboard.com> Cc: Gerhard Bertelsmann <info@gerhard-bertelsmann.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Since commit | 1f923440 ("dt-bindings: can: add can-controller.yaml") there is a common CAN controller binding. Add this to the mcp251xfd binding. Link: https://lore.kernel.org/all/20220124220653.3477172-2-mkl@pengutronix.de Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Thomas Kopp <thomas.kopp@microchip.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Jakub Kicinski authored
Subbaraya Sundeep says: ==================== Add ethtool support for completion queue event size After a packet is sent or received by NIC then NIC posts a completion queue event which consists of transmission status (like send success or error) and received status(like pointers to packet fragments). These completion events may also use a ring similar to rx and tx rings. This patchset introduces cqe-size ethtool parameter to modify the size of the completion queue event if NIC hardware has that capability. A bigger completion queue event can have more receive buffer pointers inturn NIC can transfer a bigger frame from wire as long as hardware(MAC) receive frame size limit is not exceeded. Patch 1 adds support setting/getting cqe-size via ethtool -G and ethtool -g. Patch 2 includes octeontx2 driver changes to use completion queue event size set from ethtool -G. ==================== Link: https://lore.kernel.org/r/1645555153-4932-1-git-send-email-sbhatta@marvell.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Subbaraya Sundeep authored
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>
-