kernel/drivers/net/can, branch linux-5.1.y

can: flexcan: Remove unneeded registration message

2019-07-14T06:09:39Z

[ Upstream commit eb503004a7e563d543c9cb869907156de7efe720 ] Currently the following message is observed when the flexcan driver is probed: flexcan 2090000.flexcan: device registered (reg_base=(ptrval), irq=23) The reason for printing 'ptrval' is explained at Documentation/core-api/printk-formats.rst: "Pointers printed without a specifier extension (i.e unadorned %p) are hashed to prevent leaking information about the kernel memory layout. This has the added benefit of providing a unique identifier. On 64-bit machines the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it gathers enough entropy." Instead of passing %pK, which can print the correct address, simply remove the entire message as it is not really that useful. Signed-off-by: Fabio Estevam Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: m_can: implement errata "Needless activation of MRAF irq"

2019-07-14T06:09:39Z

[ Upstream commit 3e82f2f34c930a2a0a9e69fdc2de2f2f1388b442 ] During frame reception while the MCAN is in Error Passive state and the Receive Error Counter has thevalue MCAN_ECR.REC = 127, it may happen that MCAN_IR.MRAF is set although there was no Message RAM access failure. If MCAN_IR.MRAF is enabled, an interrupt to the Host CPU is generated. Work around: The Message RAM Access Failure interrupt routine needs to check whether MCAN_ECR.RP = '1' and MCAN_ECR.REC = '127'. In this case, reset MCAN_IR.MRAF. No further action is required. This affects versions older than 3.2.0 Errata explained on Sama5d2 SoC which includes this hardware block: http://ww1.microchip.com/downloads/en/DeviceDoc/SAMA5D2-Family-Silicon-Errata-and-Data-Sheet-Clarification-DS80000803B.pdf chapter 6.2 Reproducibility: If 2 devices with m_can are connected back to back, configuring different bitrate on them will lead to interrupt storm on the receiving side, with error "Message RAM access failure occurred". Another way is to have a bad hardware connection. Bad wire connection can lead to this issue as well. This patch fixes the issue according to provided workaround. Signed-off-by: Eugen Hristev Reviewed-by: Ludovic Desroches Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: mcp251x: add support for mcp25625

2019-07-14T06:09:39Z

[ Upstream commit 35b7fa4d07c43ad79b88e6462119e7140eae955c ] Fully compatible with mcp2515, the mcp25625 have integrated transceiver. This patch adds support for the mcp25625 to the existing mcp251x driver. Signed-off-by: Sean Nyekjaer Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: flexcan: fix timeout when set small bitrate

2019-06-25T03:34:53Z

commit 247e5356a709eb49a0d95ff2a7f07dac05c8252c upstream. Current we can meet timeout issue when setting a small bitrate like 10000 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock = 30MHZ): | root@imx6ul7d:~# ip link set can0 up type can bitrate 10000 A link change request failed with some changes committed already. Interface can0 may have been left with an inconsistent configuration, please check. | RTNETLINK answers: Connection timed out It is caused by calling of flexcan_chip_unfreeze() timeout. Originally the code is using usleep_range(10, 20) for unfreeze operation, but the patch (8badd65 can: flexcan: avoid calling usleep_range from interrupt context) changed it into udelay(10) which is only a half delay of before, there're also some other delay changes. After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue. Meanwhile, Rasmus Villemoes reported that even with a timeout of 100, flexcan_probe() fails on the MPC8309, which requires a value of at least 140 to work reliably. 250 works for everyone. Signed-off-by: Joakim Zhang Reviewed-by: Dong Aisheng Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: xilinx_can: use correct bittiming_const for CAN FD core

2019-06-25T03:34:53Z

commit 904044dd8fff43e289c11a2f90fa532e946a1d8b upstream. Commit 9e5f1b273e6a ("can: xilinx_can: add support for Xilinx CAN FD core") added a new can_bittiming_const structure for CAN FD cores that support larger values for tseg1, tseg2, and sjw than previous Xilinx CAN cores, but the commit did not actually take that into use. Fix that. Tested with CAN FD core on a ZynqMP board. Fixes: 9e5f1b273e6a ("can: xilinx_can: add support for Xilinx CAN FD core") Reported-by: Shubhrajyoti Datta Signed-off-by: Anssi Hannula Cc: Michal Simek Reviewed-by: Shubhrajyoti Datta Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

peak_usb: fix clang build warning

2019-03-07T17:39:46Z

Clang points out undefined behavior when building the pcan_usb_pro driver: drivers/net/can/usb/peak_usb/pcan_usb_pro.c:136:15: error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Werror,-Wvarargs] Changing the function prototype to avoid argument promotion in the varargs call avoids the warning, and should make this well-defined. Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: David S. Miller

can: flexcan: fix NULL pointer exception during bringup

2019-01-22T10:35:33Z

Commit cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX") introduced a loop letting i run up to (including) ARRAY_SIZE(regs->mb) and in the body accessed regs->mb[i] which is an out-of-bounds array access that then resulted in an access to an reserved register area. Later this was changed by commit 0517961ccdf1 ("can: flexcan: Add provision for variable payload size") to iterate a bit differently but still runs one iteration too much resulting to call flexcan_get_mb(priv, priv->mb_count) which results in a WARN_ON and then a NULL pointer exception. This only affects devices compatible with "fsl,p1010-flexcan", "fsl,imx53-flexcan", "fsl,imx35-flexcan", "fsl,imx25-flexcan", "fsl,imx28-flexcan", so newer i.MX SoCs are not affected. Fixes: cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX") Signed-off-by: Uwe Kleine-König Cc: linux-stable # >= 4.20 Signed-off-by: Marc Kleine-Budde

can: flexcan: fix 'passing zero to ERR_PTR()' warning

2019-01-22T10:34:17Z

Fix a static code checker warning: drivers/net/can/flexcan.c:1435 flexcan_setup_stop_mode() warn: passing zero to 'PTR_ERR' Fixes: de3578c198c6 ("can: flexcan: add self wakeup support") Signed-off-by: YueHaibing Signed-off-by: Marc Kleine-Budde

can: dev: __can_get_echo_skb(): fix bogous check for non-existing skb by removing it

2019-01-22T10:18:34Z

This patch revert commit 7da11ba5c506 ("can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb") After introduction of this change we encountered following new error message on various i.MX plattforms (flexcan): | flexcan 53fc8000.can can0: __can_get_echo_skb: BUG! Trying to echo non | existing skb: can_priv::echo_skb[0] The introduction of the message was a mistake because priv->echo_skb[idx] = NULL is a perfectly valid in following case: If CAN_RAW_LOOPBACK is disabled (setsockopt) in applications, the pkt_type of the tx skb's given to can_put_echo_skb is set to PACKET_LOOPBACK. In this case can_put_echo_skb will not set priv->echo_skb[idx]. It is therefore kept NULL. As additional argument for revert: The order of check and usage of idx was changed. idx is used to access an array element before checking it's boundaries. Signed-off-by: Manfred Schlaegl Fixes: 7da11ba5c506 ("can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb") Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: flexcan: split the Message Buffer RAM area

2018-11-28T15:52:25Z

The message buffer RAM area is not a contiguous 1KB area but 2 partitions of 512 bytes each. Till now, we used Message buffers with payload size 8 bytes, which translates to 32 MBs per partition and no spare space is left in any partition. However, in upcoming SOC LX2160A the message buffers can have payload size 64 bytes. This results in less than 32 MBs per partition and some empty area is left at the end of each partition.This empty area should not be accessed. Therefore, split the Message Buffer RAM area into two partitions. Signed-off-by: Pankaj Bansal Signed-off-by: Marc Kleine-Budde