summaryrefslogtreecommitdiffstats
path: root/drivers/net/can/m_can
AgeCommit message (Collapse)AuthorFilesLines
2022-07-04can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bitsMarc Kleine-Budde1-2/+2
In commit 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") the RX path for peripheral devices was switched to RX-offload. Received CAN frames are pushed to RX-offload together with a timestamp. RX-offload is designed to handle overflows of the timestamp correctly, if 32 bit timestamps are provided. The timestamps of m_can core are only 16 bits wide. So this patch shifts them to full 32 bit before passing them to RX-offload. Link: https://lore.kernel.org/all/20220612211410.4081390-1-mkl@pengutronix.de Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Cc: <stable@vger.kernel.org> # 5.13 Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Reviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: m_can: m_can_chip_config(): actually enable internal timestampingMarc Kleine-Budde1-1/+3
In commit df06fd678260 ("can: m_can: m_can_chip_config(): enable and configure internal timestamps") the timestamping in the m_can core should be enabled. In peripheral mode, the RX'ed CAN frames, TX compete frames and error events are sorted by the timestamp. The above mentioned commit however forgot to enable the timestamping. Add the missing bits to enable the timestamp counter to the write of the Timestamp Counter Configuration register. Link: https://lore.kernel.org/all/20220612212708.4081756-1-mkl@pengutronix.de Fixes: df06fd678260 ("can: m_can: m_can_chip_config(): enable and configure internal timestamps") Cc: <stable@vger.kernel.org> # 5.13 Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Reviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-19can: can-dev: remove obsolete CAN LED supportOliver Hartkopp2-12/+0
Since commit 30f3b42147ba6f ("can: mark led trigger as broken") the CAN specific LED support was disabled and marked as BROKEN. As the common LED support with CONFIG_LEDS_TRIGGER_NETDEV should do this work now the code can be removed as preparation for a CAN netdevice Kconfig rework. Link: https://lore.kernel.org/all/20220518154527.29046-1-socketcan@hartkopp.net Suggested-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> [mkl: remove led.h from MAINTAINERS] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski3-65/+10
drivers/net/ethernet/mellanox/mlx5/core/main.c b33886971dbc ("net/mlx5: Initialize flow steering during driver probe") 40379a0084c2 ("net/mlx5_fpga: Drop INNOVA TLS support") f2b41b32cde8 ("net/mlx5: Remove ipsec_ops function table") https://lore.kernel.org/all/20220519040345.6yrjromcdistu7vh@sx1/ 16d42d313350 ("net/mlx5: Drain fw_reset when removing device") 8324a02c342a ("net/mlx5: Add exit route when waiting for FW") https://lore.kernel.org/all/20220519114119.060ce014@canb.auug.org.au/ tools/testing/selftests/net/mptcp/mptcp_join.sh e274f7154008 ("selftests: mptcp: add subflow limits test-cases") b6e074e171bc ("selftests: mptcp: add infinite map testcase") 5ac1d2d63451 ("selftests: mptcp: Add tests for userspace PM type") https://lore.kernel.org/all/20220516111918.366d747f@canb.auug.org.au/ net/mptcp/options.c ba2c89e0ea74 ("mptcp: fix checksum byte order") 1e39e5a32ad7 ("mptcp: infinite mapping sending") ea66758c1795 ("tcp: allow MPTCP to update the announced window") https://lore.kernel.org/all/20220519115146.751c3a37@canb.auug.org.au/ net/mptcp/pm.c 95d686517884 ("mptcp: fix subflow accounting on close") 4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs") https://lore.kernel.org/all/20220516111435.72f35dca@canb.auug.org.au/ net/mptcp/subflow.c ae66fb2ba6c3 ("mptcp: Do TCP fallback on early DSS checksum failure") 0348c690ed37 ("mptcp: add the fallback check") f8d4bcacff3b ("mptcp: infinite mapping receiving") https://lore.kernel.org/all/20220519115837.380bb8d4@canb.auug.org.au/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-14can: m_can: remove support for custom bit timing, take #2Jarkko Nikula2-21/+6
Now when Intel Elkhart Lake uses again common bit timing and there are no other users for custom bit timing, we can bring back the changes done by the commit 0ddd83fbebbc ("can: m_can: remove support for custom bit timing"). This effectively reverts commit ea768b2ffec6 ("Revert "can: m_can: remove support for custom bit timing"") while taking into account commit ea22ba40debe ("can: m_can: make custom bittiming fields const") and commit 7d4a101c0bd3 ("can: dev: add sanity check in can_set_static_ctrlmode()"). Link: https://lore.kernel.org/all/20220512124144.536850-2-jarkko.nikula@linux.intel.com Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-14Revert "can: m_can: pci: use custom bit timings for Elkhart Lake"Jarkko Nikula1-44/+4
This reverts commit 0e8ffdf3b86dfd44b651f91b12fcae76c25c453b. Commit 0e8ffdf3b86d ("can: m_can: pci: use custom bit timings for Elkhart Lake") broke the test case using bitrate switching. | ip link set can0 up type can bitrate 500000 dbitrate 4000000 fd on | ip link set can1 up type can bitrate 500000 dbitrate 4000000 fd on | candump can0 & | cangen can1 -I 0x800 -L 64 -e -fb \ | -D 11223344deadbeef55667788feedf00daabbccdd44332211 -n 1 -v -v Above commit does everything correctly according to the datasheet. However datasheet wasn't correct. I got confirmation from hardware engineers that the actual CAN hardware on Intel Elkhart Lake is based on M_CAN version v3.2.0. Datasheet was mirroring values from an another specification which was based on earlier M_CAN version leading to wrong bit timings. Therefore revert the commit and switch back to common bit timings. Fixes: ea4c1787685d ("can: m_can: pci: use custom bit timings for Elkhart Lake") Link: https://lore.kernel.org/all/20220512124144.536850-1-jarkko.nikula@linux.intel.com Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reported-by: Chee Hou Ong <chee.houx.ong@intel.com> Reported-by: Aman Kumar <aman.kumar@intel.com> Reported-by: Pallavi Kumari <kumari.pallavi@intel.com> Cc: <stable@vger.kernel.org> # v5.16+ Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-02can: m_can: remove a copy of the NAPI_POLL_WEIGHT defineJakub Kicinski1-6/+3
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Link: https://lore.kernel.org/all/20220429174446.196655-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-04-19can: rx-offload: rename can_rx_offload_queue_sorted() -> ↵Marc Kleine-Budde1-1/+1
can_rx_offload_queue_timestamp() This patch renames the function can_rx_offload_queue_sorted() to can_rx_offload_queue_timestamp(). This better describes what the function does, it adds a newly RX'ed skb to the sorted queue by its timestamp. Link: https://lore.kernel.org/all/20220417194327.2699059-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-31can: m_can: m_can_tx_handler(): fix use after free of skbMarc Kleine-Budde1-2/+3
can_put_echo_skb() will clone skb then free the skb. Move the can_put_echo_skb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch. Fixes: 80646733f11c ("can: m_can: update to support CAN FD features") Link: https://lore.kernel.org/all/20220317081305.739554-1-mkl@pengutronix.de Cc: stable@vger.kernel.org Reported-by: Hangyu Hua <hbh25y@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-09spi: make remove callback a void functionUwe Kleine-König1-3/+1
The value returned by an spi driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Claudius Heine <ch@denx.de> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC Acked-by: Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by: Łukasz Stelmach <l.stelmach@samsung.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2022-01-24can: tcan4x5x: regmap: fix max register valueMarc Kleine-Budde1-1/+1
The MRAM of the tcan4x5x has a size of 2K and starts at 0x8000. There are no further registers in the tcan4x5x making 0x87fc the biggest addressable register. This patch fixes the max register value of the regmap config from 0x8ffc to 0x87fc. Fixes: 6e1caaf8ed22 ("can: tcan4x5x: fix max register value") Link: https://lore.kernel.org/all/20220119064011.2943292-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-24can: m_can: m_can_fifo_{read,write}: don't read or write from/to FIFO if ↵Marc Kleine-Budde1-0/+6
length is 0 In order to optimize FIFO access, especially on m_can cores attached to slow busses like SPI, in patch | e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors") bulk read/write support has been added to the m_can_fifo_{read,write} functions. That change leads to the tcan driver to call regmap_bulk_{read,write}() with a length of 0 (for CAN frames with 0 data length). regmap treats this as an error: | tcan4x5x spi1.0 tcan4x5x0: FIFO write returned -22 This patch fixes the problem by not calling the cdev->ops->{read,write)_fifo() in case of a 0 length read/write. Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors") Link: https://lore.kernel.org/all/20220114155751.2651888-1-mkl@pengutronix.de Cc: stable@vger.kernel.org Cc: Matt Kline <matt@bitbashing.io> Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Reported-by: Michael Anochin <anochin@photo-meter.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: dev: add sanity check in can_set_static_ctrlmode()Vincent Mailhol1-3/+7
Previous patch removed can_priv::ctrlmode_static to replace it with can_get_static_ctrlmode(). A condition sine qua non for this to work is that the controller static modes should never be set in can_priv::ctrlmode_supported (c.f. the comment on can_priv::ctrlmode_supported which states that it is for "options that can be *modified* by netlink"). Also, this condition is already correctly fulfilled by all existing drivers which rely on the ctrlmode_static feature. Nonetheless, we added an extra safeguard in can_set_static_ctrlmode() to return an error value and to warn the developer who would be adventurous enough to set to static a given feature that is already set to supported. The drivers which rely on the static controller mode are then updated to check the return value of can_set_static_ctrlmode(). Link: https://lore.kernel.org/all/20211213160226.56219-3-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: do not increase rx_bytes statistics for RTR framesVincent Mailhol1-3/+3
The actual payload length of the CAN Remote Transmission Request (RTR) frames is always 0, i.e. no payload is transmitted on the wire. However, those RTR frames still use the DLC to indicate the length of the requested frame. As such, net_device_stats::rx_bytes should not be increased for the RTR frames. This patch fixes all the CAN drivers. Link: https://lore.kernel.org/all/20211207121531.42941-5-mailhol.vincent@wanadoo.fr Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Yasushi SHOJI <yashi@spacecubics.com> Cc: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> Cc: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Stephane Grosjean <s.grosjean@peak-system.com> Tested-by: Jimmy Assarsson <extja@kvaser.com> # kvaser Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Tested-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: do not increase rx statistics when generating a CAN rx error message frameVincent Mailhol1-7/+0
The CAN error message frames (i.e. error skb) are an interface specific to socket CAN. The payload of the CAN error message frames does not correspond to any actual data sent on the wire. Only an error flag and a delimiter are transmitted when an error occurs (c.f. ISO 11898-1 section 10.4.4.2 "Error flag"). For this reason, it makes no sense to increment the rx_packets and rx_bytes fields of struct net_device_stats because no actual payload were transmitted on the wire. This patch fixes all the CAN drivers. Link: https://lore.kernel.org/all/20211207121531.42941-2-mailhol.vincent@wanadoo.fr CC: Marc Kleine-Budde <mkl@pengutronix.de> CC: Nicolas Ferre <nicolas.ferre@microchip.com> CC: Alexandre Belloni <alexandre.belloni@bootlin.com> CC: Ludovic Desroches <ludovic.desroches@microchip.com> CC: Chandrasekar Ramakrishnan <rcsekar@samsung.com> CC: Maxime Ripard <mripard@kernel.org> CC: Chen-Yu Tsai <wens@csie.org> CC: Jernej Skrabec <jernej.skrabec@gmail.com> CC: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> CC: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> CC: Michal Simek <michal.simek@xilinx.com> CC: Stephane Grosjean <s.grosjean@peak-system.com> Tested-by: Jimmy Assarsson <extja@kvaser.com> # kvaser Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Tested-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07can: m_can: pci: use custom bit timings for Elkhart LakeMatthias Schiffer1-4/+44
The relevant datasheet [1] specifies nonstandard limits for the bit timing parameters. While it is unclear what the exact effect of violating these limits is, it seems like a good idea to adhere to the documentation. [1] Intel Atom® x6000E Series, and Intel® Pentium® and Celeron® N and J Series Processors for IoT Applications Datasheet, Volume 2 (Book 3 of 3), July 2021, Revision 001 Fixes: cab7ffc0324f ("can: m_can: add PCI glue driver for Intel Elkhart Lake") Link: https://lore.kernel.org/all/9eba5d7c05a48ead4024ffa6e5926f191d8c6b38.1636967198.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07can: m_can: make custom bittiming fields constMatthias Schiffer1-2/+2
The assigned timing structs will be defined a const anyway, so we can avoid a few casts by declaring the struct fields as const as well. Link: https://lore.kernel.org/all/4508fa4e639164b2584c49a065d90c78a91fa568.1636967198.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07Revert "can: m_can: remove support for custom bit timing"Matthias Schiffer2-6/+21
The timing limits specified by the Elkhart Lake CPU datasheets do not match the defaults. Let's reintroduce the support for custom bit timings. This reverts commit 0ddd83fbebbc5537f9d180d31f659db3564be708. Link: https://lore.kernel.org/all/00c9e2596b1a548906921a574d4ef7a03c0dace0.1636967198.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07can: m_can: pci: fix incorrect reference clock rateMatthias Schiffer1-1/+1
When testing the CAN controller on our Ekhart Lake hardware, we determined that all communication was running with twice the configured bitrate. Changing the reference clock rate from 100MHz to 200MHz fixed this. Intel's support has confirmed to us that 200MHz is indeed the correct clock rate. Fixes: cab7ffc0324f ("can: m_can: add PCI glue driver for Intel Elkhart Lake") Link: https://lore.kernel.org/all/c9cf3995f45c363e432b3ae8eb1275e54f009fc8.1636967198.git.matthias.schiffer@ew.tq-group.com Cc: stable@vger.kernel.org Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07can: m_can: pci: fix iomap_read_fifo() and iomap_write_fifo()Matthias Schiffer1-2/+12
The same fix that was previously done in m_can_platform in commit 99d173fbe894 ("can: m_can: fix iomap_read_fifo() and iomap_write_fifo()") is required in m_can_pci as well to make iomap_read_fifo() and iomap_write_fifo() work for val_count > 1. Fixes: 812270e5445b ("can: m_can: Batch FIFO writes during CAN transmit") Fixes: 1aa6772f64b4 ("can: m_can: Batch FIFO reads during CAN receive") Link: https://lore.kernel.org/all/20211118144011.10921-1-matthias.schiffer@ew.tq-group.com Cc: stable@vger.kernel.org Cc: Matt Kline <matt@bitbashing.io> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07can: m_can: m_can_read_fifo: fix memory leak in error branchVincent Mailhol1-1/+3
In m_can_read_fifo(), if the second call to m_can_fifo_read() fails, the function jump to the out_fail label and returns without calling m_can_receive_skb(). This means that the skb previously allocated by alloc_can_skb() is not freed. In other terms, this is a memory leak. This patch adds a goto label to destroy the skb if an error occurs. Issue was found with GCC -fanalyzer, please follow the link below for details. Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors") Link: https://lore.kernel.org/all/20211107050755.70655-1-mailhol.vincent@wanadoo.fr Cc: stable@vger.kernel.org Cc: Matt Kline <matt@bitbashing.io> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07can: m_can: Disable and ignore ELO interruptBrian Silverman1-8/+6
With the design of this driver, this condition is often triggered. However, the counter that this interrupt indicates an overflow is never read either, so overflowing is harmless. On my system, when a CAN bus starts flapping up and down, this locks up the whole system with lots of interrupts and printks. Specifically, this interrupt indicates the CEL field of ECR has overflowed. All reads of ECR mask out CEL. Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") Link: https://lore.kernel.org/all/20211129222628.7490-1-brian.silverman@bluerivertech.com Cc: stable@vger.kernel.org Signed-off-by: Brian Silverman <brian.silverman@bluerivertech.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-10-17can: m_can: fix iomap_read_fifo() and iomap_write_fifo()Aswath Govindraju1-2/+12
The read and writes from the fifo are from a buffer, with various fields and data at predefined offsets. So, they should not be done to the same address(or port) in case of val_count greater than 1. Therefore, fix this by using iowrite32()/ioread32() instead of ioread32_rep()/iowrite32_rep(). Also, the write into FIFO must be performed with an offset from the message ram base address. Therefore, fix the base address to mram_base. Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors") Link: https://lore.kernel.org/all/20210920123344.2320-1-a-govindraju@ti.com Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-08-19can: m_can: Batch FIFO writes during CAN transmitMatt Kline1-35/+26
Give FIFO writes the same treatment as reads to avoid fixed costs of individual transfers on a slow bus (e.g., tcan4x5x). Link: https://lore.kernel.org/r/20210817050853.14875-4-matt@bitbashing.io Signed-off-by: Matt Kline <matt@bitbashing.io> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-08-19can: m_can: Batch FIFO reads during CAN receiveMatt Kline1-23/+28
On peripherals communicating over a relatively slow SPI line (e.g. tcan4x5x), individual transfers have high fixed costs. This causes the driver to spend most of its time waiting between transfers and severely limits throughput. Reduce these overheads by reading more than one word at a time. Writing could get a similar treatment in follow-on commits. Link: https://lore.kernel.org/r/20210817050853.14875-3-matt@bitbashing.io Signed-off-by: Matt Kline <matt@bitbashing.io> [mkl: remove __packed from struct id_and_dlc] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-08-19can: m_can: Disable IRQs on FIFO bus errorsMatt Kline5-73/+152
If FIFO reads or writes fail due to the underlying regmap (e.g., SPI) I/O, propagate that up to the m_can driver, log an error, and disable interrupts, similar to the mcp251xfd driver. While reworking the FIFO functions to add this error handling, add support for bulk reads and writes of multiple registers. Link: https://lore.kernel.org/r/20210817050853.14875-2-matt@bitbashing.io Signed-off-by: Matt Kline <matt@bitbashing.io> [mkl: re-wrap long lines, remove WARN_ON, convert to netdev block comments] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-08-19can: m_can: fix block comment styleMarc Kleine-Budde1-3/+4
This patch fixes the commenting style in the m_can driver. Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Fixes: df06fd678260 ("can: m_can: m_can_chip_config(): enable and configure internal timestamps") Link: https://lore.kernel.org/r/20210819111703.599686-2-mkl@pengutronix.de Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-08-19can: tcan4x5x: cdev_to_priv(): remove stray empty lineMarc Kleine-Budde1-1/+0
This patch removes a stray empty line in the cdev_to_priv() function. Fixes: ac33ffd3e2b0 ("can: m_can: let m_can_class_allocate_dev() allocate driver specific private data") Link: https://lore.kernel.org/r/20210819111703.599686-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-08-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-4/+4
Conflicts: drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.h 9e26680733d5 ("bnxt_en: Update firmware call to retrieve TX PTP timestamp") 9e518f25802c ("bnxt_en: 1PPS functions to configure TSIO pins") 099fdeda659d ("bnxt_en: Event handler for PPS events") kernel/bpf/helpers.c include/linux/bpf-cgroup.h a2baf4e8bb0f ("bpf: Fix potentially incorrect results with bpf_get_local_storage()") c7603cfa04e7 ("bpf: Add ambient BPF runtime context stored in current") drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c 5957cc557dc5 ("net/mlx5: Set all field of mlx5_irq before inserting it to the xarray") 2d0b41a37679 ("net/mlx5: Refcount mlx5_irq with integer") MAINTAINERS 7b637cd52f02 ("MAINTAINERS: fix Microchip CAN BUS Analyzer Tool entry typo") 7d901a1e878a ("net: phy: add Maxlinear GPY115/21x/24x driver") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-10can: m_can: m_can_set_bittiming(): fix setting M_CAN_DBTP registerHussein Alasadi1-4/+4
This patch fixes the setting of the M_CAN_DBTP register contents: - use DBTP_ (the data bitrate macros) instead of NBTP_ which area used for the nominal bitrate - do not overwrite possibly-existing DBTP_TDC flag by ORing reg_btp instead of overwriting Link: https://lore.kernel.org/r/FRYP281MB06140984ABD9994C0AAF7433D1F69@FRYP281MB0614.DEUP281.PROD.OUTLOOK.COM Fixes: 20779943a080 ("can: m_can: use bits.h macros for all regmasks") Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Hussein Alasadi <alasadi@arecs.eu> [mkl: update patch description, update indention] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-07-25can: m_can: remove support for custom bit timingMarc Kleine-Budde2-21/+6
Since commit aee2b3ccc8a6 ("can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver") there is no use of the device specific bit timing parameters (m_can_classdev::bit_timing and struct m_can_classdev::data_timing). This patch removes the support for custom bit timing from the driver, as the common bit timing works for all known IP core implementations. Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Link: https://lore.kernel.org/r/20210616102811.2449426-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-07-25can: m_can: use devm_platform_ioremap_resource_bynameYang Yingliang1-2/+1
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately. Link: https://lore.kernel.org/r/20210603073441.2983497-1-yangyingliang@huawei.com Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-07-25can: m_can: Add support for transceiver as phyFaiz Abbas3-1/+25
Add support for implementing transceiver node as phy. The max_bitrate is obtained by getting a phy attribute. Link: https://lore.kernel.org/r/20210724174001.553047-1-mkl@pengutronix.de Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-07-25can: rx-offload: can_rx_offload_threaded_irq_finish(): add new function to ↵Marc Kleine-Budde1-1/+1
be called from threaded interrupt After reading all CAN frames from the controller in the IRQ handler and storing them into a skb_queue, the driver calls napi_schedule(). In the napi poll function the skb from the skb_queue are then pushed into the networking stack. However if napi_schedule() is called from a threaded IRQ handler this triggers the following error: | NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! To avoid this, create a new rx-offload function (can_rx_offload_threaded_irq_finish()) with a call to local_bh_disable()/local_bh_enable() around the napi_schedule() call. Convert all drivers that call can_rx_offload_irq_finish() from threaded IRQ context to can_rx_offload_threaded_irq_finish(). Link: https://lore.kernel.org/r/20210724204745.736053-4-mkl@pengutronix.de Suggested-by: Daniel Glöckner <dg@emlix.com> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-07-25can: rx-offload: add skb queue for use during ISRMarc Kleine-Budde1-0/+3
Adding a skb to the skb_queue in rx-offload requires to take a lock. This commit avoids this by adding an unlocked skb queue that is appended at the end of the ISR. Having one lock at the end of the ISR should be OK as the HW is empty, not about to overflow. Link: https://lore.kernel.org/r/20210724204745.736053-2-mkl@pengutronix.de Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Co-developed-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-05-27can: m_can: fix whitespace in a few commentsTorin Cooper-Bennun1-5/+5
Fixes whitespace in comments titling sections of register masks. Link: https://lore.kernel.org/r/20210504125123.500553-5-torin@maxiluxsystems.com Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-05-27can: m_can: make TXESC, RXESC config more explicitTorin Cooper-Bennun1-6/+12
Introduce masks for the three RXESC fields (RBDS, F1DS, F0DS) and the one TXESC field (TBDS). Update m_can_chip_config() to explicitly set all four fields to the 64-byte option (0x7) (and these defs are renamed to be more concise). This is an improvement in maintainability, and also makes it easier to implement more flexible configuration of the M_CAN buffers in the future. Link: https://lore.kernel.org/r/20210504125123.500553-4-torin@maxiluxsystems.com Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-05-27can: m_can: clean up CCCR reg defs, order by revsTorin Cooper-Bennun1-10/+13
Ensures that the different CCCR regmasks for m_can revs 3.0.x, 3.1.x, 3.2.x and 3.3.x are clearly distinguishable. Removes incorrect CCCR_CANFD define. Adds bit fields UTSU and WMM for rev 3.3.x, for completeness. Link: https://lore.kernel.org/r/20210504125123.500553-3-torin@maxiluxsystems.com Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-05-27can: m_can: use bits.h macros for all regmasksTorin Cooper-Bennun1-113/+86
This updates m_can.c to exclusively use GENMASK, FIELD_GET, FIELD_PREP and FIELD_MAX for regmask ops, as is convention in the current kernel (far less error-prone, far more concise). Link: https://lore.kernel.org/r/20210504125123.500553-2-torin@maxiluxsystems.com Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-05-06can: m_can: m_can_tx_work_queue(): fix tx_skb race conditionMarc Kleine-Budde1-1/+2
The m_can_start_xmit() function checks if the cdev->tx_skb is NULL and returns with NETDEV_TX_BUSY in case tx_sbk is not NULL. There is a race condition in the m_can_tx_work_queue(), where first the skb is send to the driver and then the case tx_sbk is set to NULL. A TX complete IRQ might come in between and wake the queue, which results in tx_skb not being cleared yet. Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Tested-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-04-07can: m_can: m_can_receive_skb(): add missing error handling to ↵Marc Kleine-Budde1-3/+10
can_rx_offload_queue_sorted() call In commit 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") the RX path for peripherals (i.e. SPI based m_can controllers) was converted to the rx-offload infrastructure. However, the error handling for can_rx_offload_queue_sorted() was forgotten. can_rx_offload_queue_sorted() will return with an error if the internal queue is full. This patch adds the missing error handling, by increasing the rx_fifo_errors. Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Link: https://lore.kernel.org/r/20210401084515.1455013-1-mkl@pengutronix.de Reported-by: coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1503583 ("Error handling issues") Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: tcan4x5x: remove duplicate include of regmap.hWan Jiabing1-1/+0
linux/regmap.h has been included at line 13, so remove the duplicate one at line 14. Fixes: 67def4ef8bb9 ("can: tcan4x5x: move regmap code into seperate file") Link: https://lore.kernel.org/r/20210323021026.140460-1-wanjiabing@vivo.com Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from ↵Torin Cooper-Bennun2-16/+107
softirq context For peripheral devices, m_can sent skbs directly from a threaded irq instead of from a softirq context, breaking the tcan4x5x peripheral driver completely. This patch transitions the driver to use the rx-offload helper for peripherals, ensuring the skbs are sent from the correct context, with h/w timestamping to ensure correct ordering. Link: https://lore.kernel.org/r/20210308102427.63916-4-torin@maxiluxsystems.com Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> [mkl: m_can_class_register(): update error handling] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: m_can: m_can_chip_config(): enable and configure internal timestampsTorin Cooper-Bennun1-0/+5
This is a prerequisite for transitioning the m_can driver to rx-offload, which works best with TX and RX timestamps. The timestamps provided by M_CAN are 16-bit, timed according to the nominal bit timing, and may be prescaled by a multiplier up to 16. We choose the highest prescalar so that the timestamp wraps every 2^20 bit times, or 209 ms at a bus speed of 5 Mbit/s. Timestamps will have a precision of 16 bit times. Link: https://lore.kernel.org/r/20210308102427.63916-3-torin@maxiluxsystems.com Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: m_can: add infrastructure for internal timestampsTorin Cooper-Bennun1-0/+27
Add infrastucture to allow internal timestamps from the M_CAN to be configured and retrieved. Link: https://lore.kernel.org/r/20210308102427.63916-2-torin@maxiluxsystems.com Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: m_can: m_can_class_allocate_dev(): remove impossible error return judgmentXulin Sun1-5/+0
If the CAN net device has been successfully allocated, its private data structure is impossible to be empty, remove this redundant error return judgment. Link: https://lore.kernel.org/r/20210205072559.13241-2-xulin.sun@windriver.com Signed-off-by: Xulin Sun <xulin.sun@windriver.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: dev: can_free_echo_skb(): extend to return can frame lengthMarc Kleine-Budde1-1/+1
In order to implement byte queue limits (bql) in CAN drivers, the length of the CAN frame needs to be passed into the networking stack even if the transmission failed for some reason. To avoid to calculate this length twice, extend can_free_echo_skb() to return that value. Convert all users of this function, too. This patch is the natural extension of commit: | 9420e1d495e2 ("can: dev: can_get_echo_skb(): extend to return can | frame length") Link: https://lore.kernel.org/r/20210319142700.305648-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-16can: m_can: m_can_rx_peripheral(): fix RX being blocked by errorsTorin Cooper-Bennun1-1/+1
For M_CAN peripherals, m_can_rx_handler() was called with quota = 1, which caused any error handling to block RX from taking place until the next time the IRQ handler is called. This had been observed to cause RX to be blocked indefinitely in some cases. This is fixed by calling m_can_rx_handler with a sensibly high quota. Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Link: https://lore.kernel.org/r/20210303144350.4093750-1-torin@maxiluxsystems.com Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-16can: m_can: m_can_do_rx_poll(): fix extraneous msg loss warningTorin Cooper-Bennun1-3/+0
Message loss from RX FIFO 0 is already handled in m_can_handle_lost_msg(), with netdev output included. Removing this warning also improves driver performance under heavy load, where m_can_do_rx_poll() may be called many times before this interrupt is cleared, causing this message to be output many times (thanks Mariusz Madej for this report). Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") Link: https://lore.kernel.org/r/20210303103151.3760532-1-torin@maxiluxsystems.com Reported-by: Mariusz Madej <mariusz.madej@xtrack.com> Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-01can: tcan4x5x: tcan4x5x_init(): fix initialization - clear MRAM before ↵Torin Cooper-Bennun1-3/+3
entering Normal Mode This patch prevents a potentially destructive race condition. The device is fully operational on the bus after entering Normal Mode, so zeroing the MRAM after entering this mode may lead to loss of information, e.g. new received messages. This patch fixes the problem by first initializing the MRAM, then bringing the device into Normale Mode. Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Link: https://lore.kernel.org/r/20210226163440.313628-1-torin@maxiluxsystems.com Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 03:33:59 +0000