aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/can/usb/mcba_usb.c
AgeCommit message (Collapse)AuthorFilesLines
2024-10-02move asm/unaligned.h to linux/unaligned.hAl Viro1-1/+1
asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
2022-11-24can: mcba_usb: Fix termination command argumentYasushi SHOJI1-3/+7
Microchip USB Analyzer can activate the internal termination resistors by setting the "termination" option ON, or OFF to to deactivate them. As I've observed, both with my oscilloscope and captured USB packets below, you must send "0" to turn it ON, and "1" to turn it OFF. From the schematics in the user's guide, I can confirm that you must drive the CAN_RES signal LOW "0" to activate the resistors. Reverse the argument value of usb_msg.termination to fix this. These are the two commands sequence, ON then OFF. > No. Time Source Destination Protocol Length Info > 1 0.000000 host 1.3.1 USB 46 URB_BULK out > > Frame 1: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) > USB URB > Leftover Capture Data: a80000000000000000000000000000000000a8 > > No. Time Source Destination Protocol Length Info > 2 4.372547 host 1.3.1 USB 46 URB_BULK out > > Frame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) > USB URB > Leftover Capture Data: a80100000000000000000000000000000000a9 Signed-off-by: Yasushi SHOJI <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-11-07can: dev: fix skb drop checkOliver Hartkopp1-1/+1
In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") the priv->ctrlmode element is read even on virtual CAN interfaces that do not create the struct can_priv at startup. This out-of-bounds read may lead to CAN frame drops for virtual CAN interfaces like vcan and vxcan. This patch mainly reverts the original commit and adds a new helper for CAN interface drivers that provide the required information in struct can_priv. Fixes: a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") Reported-by: Dariusz Stojaczyk <[email protected]> Cc: Vincent Mailhol <[email protected]> Cc: Max Staudt <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Acked-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] # 6.0.x [mkl: patch pch_can, too] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: tree-wide: advertise software timestamping capabilitiesVincent Mailhol1-0/+6
Currently, some CAN drivers support hardware timestamping, some do not. But userland has no method to query which features are supported (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertised what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). This patch only targets the CAN drivers which *do not* support hardware timestamping. For each of those CAN drivers, implement the get_ts_info() using the generic ethtool_op_get_ts_info(). This way, userland can do: | $ ethtool --show-time-stamping canX to confirm the device timestamping capacities. N.B. the drivers which support hardware timestamping will be migrated in separate patches. Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] [mkl: mscan: add missing mscan_ethtool_ops] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-19can: can-dev: remove obsolete CAN LED supportOliver Hartkopp1-8/+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/[email protected] Suggested-by: Vincent Mailhol <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> [mkl: remove led.h from MAINTAINERS] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-03-31can: mcba_usb: properly check endpoint typePavel Skripkin1-10/+16
Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. We should check that in endpoint is actually present to prevent this warning. Found pipes are now saved to struct mcba_priv and code uses them directly instead of making pipes in place. Fail log: | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Modules linked in: | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Workqueue: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Call Trace: | <TASK> | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline] | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [inline] Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/all/[email protected] Reported-and-tested-by: [email protected] Signed-off-by: Pavel Skripkin <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-03-31can: mcba_usb: mcba_usb_start_xmit(): fix double dev_kfree_skb in error pathHangyu Hua1-1/+0
There is no need to call dev_kfree_skb() when usb_submit_urb() fails because can_put_echo_skb() deletes original skb and can_free_echo_skb() deletes the cloned skb. Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Hangyu Hua <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-01-05can: do not increase tx_bytes statistics for RTR framesVincent Mailhol1-8/+4
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::tx_bytes should not be increased when sending RTR frames. The function can_get_echo_skb() already returns the correct length, even for RTR frames (c.f. [1]). However, for historical reasons, the drivers do not use can_get_echo_skb()'s return value and instead, most of them store a temporary length (or dlc) in some local structure or array. Using the return value of can_get_echo_skb() solves the issue. After doing this, such length/dlc fields become unused and so this patch does the adequate cleaning when needed. This patch fixes all the CAN drivers. Finally, can_get_echo_skb() is decorated with the __must_check attribute in order to force future drivers to correctly use its return value (else the compiler would emit a warning). [1] commit ed3320cec279 ("can: dev: __can_get_echo_skb(): fix real payload length return value for RTR frames") Link: https://lore.kernel.org/all/[email protected] Cc: Nicolas Ferre <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Ludovic Desroches <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Yasushi SHOJI <[email protected]> Cc: Oliver Hartkopp <[email protected]> Cc: Stephane Grosjean <[email protected]> Cc: Andreas Larsson <[email protected]> Tested-by: Jimmy Assarsson <[email protected]> # kvaser Signed-off-by: Vincent Mailhol <[email protected]> Acked-by: Stefan Mätje <[email protected]> # esd_usb2 Tested-by: Stefan Mätje <[email protected]> # esd_usb2 [mkl: add conversion for grcan] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-01-05can: do not increase rx_bytes statistics for RTR framesVincent Mailhol1-3/+4
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/[email protected] Cc: Marc Kleine-Budde <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Ludovic Desroches <[email protected]> Cc: Chandrasekar Ramakrishnan <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Yasushi SHOJI <[email protected]> Cc: Appana Durga Kedareswara rao <[email protected]> Cc: Naga Sureshkumar Relli <[email protected]> Cc: Michal Simek <[email protected]> Cc: Stephane Grosjean <[email protected]> Tested-by: Jimmy Assarsson <[email protected]> # kvaser Signed-off-by: Vincent Mailhol <[email protected]> Acked-by: Stefan Mätje <[email protected]> # esd_usb2 Tested-by: Stefan Mätje <[email protected]> # esd_usb2 Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-01-05can: do not copy the payload of RTR framesVincent Mailhol1-4/+4
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. For this reason, it is incorrect to copy the payload of RTR frames (the payload buffer would only contain garbage data). This patch encapsulates the payload copy in a check toward the RTR flag. Link: https://lore.kernel.org/all/[email protected] Cc: Yasushi SHOJI <[email protected]> Tested-by: Yasushi SHOJI <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-07-30can: mcba_usb_start(): add missing urb->transfer_dma initializationPavel Skripkin1-0/+2
Yasushi reported, that his Microchip CAN Analyzer stopped working since commit 91c02557174b ("can: mcba_usb: fix memory leak in mcba_usb"). The problem was in missing urb->transfer_dma initialization. In my previous patch to this driver I refactored mcba_usb_start() code to avoid leaking usb coherent buffers. To archive it, I passed local stack variable to usb_alloc_coherent() and then saved it to private array to correctly free all coherent buffers on ->close() call. But I forgot to initialize urb->transfer_dma with variable passed to usb_alloc_coherent(). All of this was causing device to not work, since dma addr 0 is not valid and following log can be found on bug report page, which points exactly to problem described above. | DMAR: [DMA Write] Request device [00:14.0] PASID ffffffff fault addr 0 [fault reason 05] PTE Write access is not set Fixes: 91c02557174b ("can: mcba_usb: fix memory leak in mcba_usb") Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990850 Link: https://lore.kernel.org/r/[email protected] Cc: linux-stable <[email protected]> Reported-by: Yasushi SHOJI <[email protected]> Signed-off-by: Pavel Skripkin <[email protected]> Tested-by: Yasushi SHOJI <[email protected]> [mkl: fixed typos in commit message - thanks Yasushi SHOJI] Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-06-16can: mcba_usb: fix memory leak in mcba_usbPavel Skripkin1-2/+15
Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS Analyzer Tool. The problem was in unfreed usb_coherent. In mcba_usb_start() 20 coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see mcba_usb_start) and this flag cannot be used with coherent buffers. Fail log: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected | [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem) So, all allocated buffers should be freed with usb_free_coherent() explicitly NOTE: The same pattern for allocating and freeing coherent buffers is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/r/[email protected] Cc: linux-stable <[email protected]> Reported-and-tested-by: [email protected] Signed-off-by: Pavel Skripkin <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
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/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-27can: mcba_usb: remove h from printk format specifierTom Rix1-3/+3
This change fixes the checkpatch warning described in this commit commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") Standard integer promotion is already done and %hx and %hhx is useless so do not encourage the use of %hh[xudi] or %h[xudi]. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tom Rix <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-14can: dev: can_get_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 after queueing and after transmission completion. To avoid to calculate this length twice, extend can_get_echo_skb() to return that value. Convert all users of this function, too. Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-14can: dev: can_put_echo_skb(): extend to handle frame_lenVincent Mailhol1-1/+1
Add a frame_len argument to can_put_echo_skb() which is used to save length of the CAN frame into field frame_len of struct can_skb_priv so that it can be later used after transmission completion. Convert all users of this function, too. Drivers which implement BQL call can_put_echo_skb() with the output of can_skb_get_frame_len(skb) and drivers which do not simply pass zero as an input (in the same way that NULL would be given to can_get_echo_skb()). This way, we have a nice symmetry between the two echo functions. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vincent Mailhol <[email protected]>
2020-11-20can: replace can_dlc as variable/element for payload lengthOliver Hartkopp1-5/+5
The naming of can_dlc as element of struct can_frame and also as variable name is misleading as it claims to be a 'data length CODE' but in reality it always was a plain data length. With the indroduction of a new 'len' element in struct can_frame we can now remove can_dlc as name and make clear which of the former uses was a plain length (-> 'len') or a data length code (-> 'dlc') value. Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/r/[email protected] [mkl: gs_usb: keep struct gs_host_frame::can_dlc as is] Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-11-20can: rename get_can_dlc() macro with can_cc_dlc2len()Oliver Hartkopp1-1/+1
The get_can_dlc() macro is used to ensure the payload length information of the Classical CAN frame to be max 8 bytes (the CAN_MAX_DLEN). Rename the macro and use the correct constant in preparation of the len/dlc cleanup for Classical CAN frames. Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-11-15can: mcba_usb: mcba_usb_start_xmit(): first fill skb, then pass to ↵Marc Kleine-Budde1-2/+2
can_put_echo_skb() The driver has to first fill the skb with data and then handle it to can_put_echo_skb(). This patch moves the can_put_echo_skb() down, right before sending the skb out via USB. Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Cc: Remigiusz Kołłątaj <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-09-21can: mcba_usb: remove redundant initialization of variable errColin Ian King1-1/+1
The variable err is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-09-21can: drivers: fix spelling mistakesMarc Kleine-Budde1-1/+1
This patch fixes spelling erros found by "codespell" in the drivers/net/can subtree. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2019-11-04can: mcba_usb: fix use-after-free on disconnectJohan Hovold1-2/+1
The driver was accessing its driver data after having freed it. Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Cc: stable <[email protected]> # 4.12 Cc: Remigiusz Kołłątaj <[email protected]> Reported-by: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 412Thomas Gleixner1-12/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 2 file(s). Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Allison Randal <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-08can: mcba_usb: cancel urb on -EPROTOMartin Kelly1-0/+1
When we unplug the device, we can see both -EPIPE and -EPROTO depending on exact timing and what system we run on. If we continue to resubmit URBs, they will immediately fail, and they can cause stalls, especially on slower CPUs. Fix this by not resubmitting on -EPROTO, as we already do on -EPIPE. Signed-off-by: Martin Kelly <[email protected]> Cc: linux-stable <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2017-12-01can: mcba_usb: fix device disconnect bugMartin Kelly1-0/+1
Currently, when you disconnect the device, the driver infinitely resubmits all URBs, so you see: Rx URB aborted (-32) in an infinite loop. Fix this by catching -EPIPE (what we get in urb->status when the device disconnects) and not resubmitting. With this patch, I can plug and unplug many times and the driver recovers correctly. Signed-off-by: Martin Kelly <[email protected]> Cc: linux-stable <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2017-12-01can: mcba_usb: fix typoMartin Kelly1-1/+1
Fix typo "analizer" --> "Analyzer". Signed-off-by: Martin Kelly <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2017-04-25can: mcba_usb: Add support for Microchip CAN BUS AnalyzerRemigiusz Kołłątaj1-0/+904
SocketCAN driver for Microchip CAN BUS Analyzer (http://www.microchip.com/development-tools/) Changes in v4: - possible memory leak fixed in mcba_usb_write_bulk_callback - LED support added - failure handling in mcba_usb_probe improved - C99 initializers for structs on stack Changes in v3: - improved/simplified CAN ID conversion - functions for transmission of skb and cmd separated - fixed/improved netif_stop_queue handling - style/cosmetic corrections Changes in v2: - Termination handling reimplemented to fit new netlink API (IFLA_CAN_TERMINATION) - Bitrate handling reimplemented to fit new netlink API (IFLA_CAN_BITRATE) - CAN ID conversion refactored (changed from macro to inline functions) - CAN DLC handling using get_can_dlc() - Endianness handling for can_speed introduced - Debugging removed - Redundant error prints removed - Style/cosmetic corrections (i.e. macro names, redefs, inits etc.) Signed-off-by: Remigiusz Kołłątaj <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>