summaryrefslogtreecommitdiff
path: root/drivers/net/can
AgeCommit message (Collapse)Author
2020-11-03can: flexcan: flexcan_remove(): disable wakeup completelyJoakim Zhang
With below sequence, we can see wakeup default is enabled after re-load module, if it was enabled before, so we need disable wakeup in flexcan_remove(). | # cat /sys/bus/platform/drivers/flexcan/5a8e0000.can/power/wakeup | disabled | # echo enabled > /sys/bus/platform/drivers/flexcan/5a8e0000.can/power/wakeup | # cat /sys/bus/platform/drivers/flexcan/5a8e0000.can/power/wakeup | enabled | # rmmod flexcan | # modprobe flexcan | # cat /sys/bus/platform/drivers/flexcan/5a8e0000.can/power/wakeup | enabled Fixes: de3578c198c6 ("can: flexcan: add self wakeup support") Fixes: 915f9666421c ("can: flexcan: add support for DT property 'wakeup-source'") Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20201020184527.8190-1-qiangqing.zhang@nxp.com [mkl: streamlined commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: flexcan: add ECC initialization for VF610Joakim Zhang
For SoCs with ECC supported, even use FLEXCAN_QUIRK_DISABLE_MECR quirk to disable non-correctable errors interrupt and freeze mode, had better use FLEXCAN_QUIRK_SUPPORT_ECC quirk to initialize all memory. Fixes: cdce844865bea ("can: flexcan: add vf610 support for FlexCAN") Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20201020155402.30318-6-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: flexcan: add ECC initialization for LX2160AJoakim Zhang
After double check with Layerscape CAN owner (Pankaj Bansal), confirm that LX2160A indeed supports ECC feature, so correct the feature table. For SoCs with ECC supported, even use FLEXCAN_QUIRK_DISABLE_MECR quirk to disable non-correctable errors interrupt and freeze mode, had better use FLEXCAN_QUIRK_SUPPORT_ECC quirk to initialize all memory. Fixes: 2c19bb43e5572 ("can: flexcan: add lx2160ar1 support") Cc: Pankaj Bansal <pankaj.bansal@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20201020155402.30318-5-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: flexcan: remove FLEXCAN_QUIRK_DISABLE_MECR quirk for LS1021AJoakim Zhang
After double check with Layerscape CAN owner (Pankaj Bansal), confirm that LS1021A doesn't support ECC feature, so remove FLEXCAN_QUIRK_DISABLE_MECR quirk. Fixes: 99b7668c04b27 ("can: flexcan: adding platform specific details for LS1021A") Cc: Pankaj Bansal <pankaj.bansal@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20201020155402.30318-4-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: mcp251xfd: remove unneeded breakTom Rix
A break is not needed if it is preceded by a return. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201019172412.31143-1-trix@redhat.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: mcp251xfd: mcp251xfd_regmap_nocrc_read(): fix semicolon.cocci warningskernel test robot
drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c:176:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: 875347fe5756 ("can: mcp25xxfd: add regmap infrastructure") Signed-off-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20201019120805.GA63693@ae4257e0ab22 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: mcp251xfd: mcp251xfd_regmap_crc_read(): increase severity of CRC read ↵Marc Kleine-Budde
error messages During debugging it turned out that some people have setups where the SPI communication is more prone to CRC errors. Increase the severity of both the transfer retry and transfer failure message to give users feedback without the need to recompile the driver with debug enabled. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Thomas Kopp <thomas.kopp@microchip.com> Link: http://lore.kernel.org/r/20201019190524.1285319-15-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: peak_canfd: pucan_handle_can_rx(): fix echo management when loopback is onStephane Grosjean
Echo management is driven by PUCAN_MSG_LOOPED_BACK bit, while loopback frames are identified with PUCAN_MSG_SELF_RECEIVE bit. Those bits are set for each outgoing frame written to the IP core so that a copy of each one will be placed into the rx path. Thus, - when PUCAN_MSG_LOOPED_BACK is set then the rx frame is an echo of a previously sent frame, - when PUCAN_MSG_LOOPED_BACK+PUCAN_MSG_SELF_RECEIVE are set, then the rx frame is an echo AND a loopback frame. Therefore, this frame must be put into the socket rx path too. This patch fixes how CAN frames are handled when these are sent while the can interface is configured in "loopback on" mode. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Link: https://lore.kernel.org/r/20201013153947.28012-1-s.grosjean@peak-system.com Fixes: 8ac8321e4a79 ("can: peak: add support for PEAK PCAN-PCIe FD CAN-FD boards") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: peak_usb: peak_usb_get_ts_time(): fix timestamp wrappingStephane Grosjean
Fabian Inostroza <fabianinostrozap@gmail.com> has discovered a potential problem in the hardware timestamp reporting from the PCAN-USB USB CAN interface (only), related to the fact that a timestamp of an event may precede the timestamp used for synchronization when both records are part of the same USB packet. However, this case was used to detect the wrapping of the time counter. This patch details and fixes the two identified cases where this problem can occur. Reported-by: Fabian Inostroza <fabianinostrozap@gmail.com> Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Link: https://lore.kernel.org/r/20201014085631.15128-1-s.grosjean@peak-system.com Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: peak_usb: add range checking in decode operationsDan Carpenter
These values come from skb->data so Smatch considers them untrusted. I believe Smatch is correct but I don't have a way to test this. The usb_if->dev[] array has 2 elements but the index is in the 0-15 range without checks. The cfd->len can be up to 255 but the maximum valid size is CANFD_MAX_DLEN (64) so that could lead to memory corruption. Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200813140604.GA456946@mwanda Acked-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: xilinx_can: handle failure cases of pm_runtime_get_syncNavid Emamdoost
Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count. Call pm_runtime_put if pm_runtime_get_sync fails. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Link: https://lore.kernel.org/r/20200605033239.60664-1-navid.emamdoost@gmail.com Fixes: 4716620d1b62 ("can: xilinx: Convert to runtime_pm") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: ti_hecc: ti_hecc_probe(): add missed clk_disable_unprepare() in error pathZhang Changzhong
The driver forgets to call clk_disable_unprepare() in error path after a success calling for clk_prepare_enable(). Fix it by adding a clk_disable_unprepare() in error path. Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1594973079-27743-1-git-send-email-zhangchangzhong@huawei.com Fixes: befa60113ce7 ("can: ti_hecc: add missing prepare and unprepare of the clock") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: dev: __can_get_echo_skb(): fix real payload length return value for RTR ↵Oliver Hartkopp
frames The can_get_echo_skb() function returns the number of received bytes to be used for netdev statistics. In the case of RTR frames we get a valid (potential non-zero) data length value which has to be passed for further operations. But on the wire RTR frames have no payload length. Therefore the value to be used in the statistics has to be zero for RTR frames. Reported-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/r/20201020064443.80164-1-socketcan@hartkopp.net Fixes: cf5046b309b3 ("can: dev: let can_get_echo_skb() return dlc of CAN frame") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ contextVincent Mailhol
If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but not always, the case), the 'WARN_ON(in_irq)' in net/core/skbuff.c#skb_release_head_state() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference. The root cause of this issue is the call to kfree_skb() instead of dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog(). This patch prevents the skb to be freed within the call to netif_rx() by incrementing its reference count with skb_get(). The skb is finally freed by one of the in-irq-context safe functions: dev_consume_skb_any() or dev_kfree_skb_any(). The "any" version is used because some drivers might call can_get_echo_skb() in a normal context. The reason for this issue to occur is that initially, in the core network stack, loopback skb were not supposed to be received in hardware IRQ context. The CAN stack is an exeption. This bug was previously reported back in 2017 in [1] but the proposed patch never got accepted. While [1] directly modifies net/core/dev.c, we try to propose here a smoother modification local to CAN network stack (the assumption behind is that only CAN devices are affected by this issue). [1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20201002154219.4887-2-mailhol.vincent@wanadoo.fr Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-03can: rx-offload: don't call kfree_skb() from IRQ contextMarc Kleine-Budde
A CAN driver, using the rx-offload infrastructure, is reading CAN frames (usually in IRQ context) from the hardware and placing it into the rx-offload queue to be delivered to the networking stack via NAPI. In case the rx-offload queue is full, trying to add more skbs results in the skbs being dropped using kfree_skb(). If done from hard-IRQ context this results in the following warning: [ 682.552693] ------------[ cut here ]------------ [ 682.557360] WARNING: CPU: 0 PID: 3057 at net/core/skbuff.c:650 skb_release_head_state+0x74/0x84 [ 682.566075] Modules linked in: can_raw can coda_vpu flexcan dw_hdmi_ahb_audio v4l2_jpeg imx_vdoa can_dev [ 682.575597] CPU: 0 PID: 3057 Comm: cansend Tainted: G W 5.7.0+ #18 [ 682.583098] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 682.589657] [<c0112628>] (unwind_backtrace) from [<c010c1c4>] (show_stack+0x10/0x14) [ 682.597423] [<c010c1c4>] (show_stack) from [<c06c481c>] (dump_stack+0xe0/0x114) [ 682.604759] [<c06c481c>] (dump_stack) from [<c0128f10>] (__warn+0xc0/0x10c) [ 682.611742] [<c0128f10>] (__warn) from [<c0129314>] (warn_slowpath_fmt+0x5c/0xc0) [ 682.619248] [<c0129314>] (warn_slowpath_fmt) from [<c0b95dec>] (skb_release_head_state+0x74/0x84) [ 682.628143] [<c0b95dec>] (skb_release_head_state) from [<c0b95e08>] (skb_release_all+0xc/0x24) [ 682.636774] [<c0b95e08>] (skb_release_all) from [<c0b95eac>] (kfree_skb+0x74/0x1c8) [ 682.644479] [<c0b95eac>] (kfree_skb) from [<bf001d1c>] (can_rx_offload_queue_sorted+0xe0/0xe8 [can_dev]) [ 682.654051] [<bf001d1c>] (can_rx_offload_queue_sorted [can_dev]) from [<bf001d6c>] (can_rx_offload_get_echo_skb+0x48/0x94 [can_dev]) [ 682.666007] [<bf001d6c>] (can_rx_offload_get_echo_skb [can_dev]) from [<bf01efe4>] (flexcan_irq+0x194/0x5dc [flexcan]) [ 682.676734] [<bf01efe4>] (flexcan_irq [flexcan]) from [<c019c1ec>] (__handle_irq_event_percpu+0x4c/0x3ec) [ 682.686322] [<c019c1ec>] (__handle_irq_event_percpu) from [<c019c5b8>] (handle_irq_event_percpu+0x2c/0x88) [ 682.695993] [<c019c5b8>] (handle_irq_event_percpu) from [<c019c64c>] (handle_irq_event+0x38/0x5c) [ 682.704887] [<c019c64c>] (handle_irq_event) from [<c01a1058>] (handle_fasteoi_irq+0xc8/0x180) [ 682.713432] [<c01a1058>] (handle_fasteoi_irq) from [<c019b2c0>] (generic_handle_irq+0x30/0x44) [ 682.722063] [<c019b2c0>] (generic_handle_irq) from [<c019b8f8>] (__handle_domain_irq+0x64/0xdc) [ 682.730783] [<c019b8f8>] (__handle_domain_irq) from [<c06df4a4>] (gic_handle_irq+0x48/0x9c) [ 682.739158] [<c06df4a4>] (gic_handle_irq) from [<c0100b30>] (__irq_svc+0x70/0x98) [ 682.746656] Exception stack(0xe80e9dd8 to 0xe80e9e20) [ 682.751725] 9dc0: 00000001 e80e8000 [ 682.759922] 9de0: e820cf80 00000000 ffffe000 00000000 eaf08fe4 00000000 600d0013 00000000 [ 682.768117] 9e00: c1732e3c c16093a8 e820d4c0 e80e9e28 c018a57c c018b870 600d0013 ffffffff [ 682.776315] [<c0100b30>] (__irq_svc) from [<c018b870>] (lock_acquire+0x108/0x4e8) [ 682.783821] [<c018b870>] (lock_acquire) from [<c0e938e4>] (down_write+0x48/0xa8) [ 682.791242] [<c0e938e4>] (down_write) from [<c02818dc>] (unlink_file_vma+0x24/0x40) [ 682.798922] [<c02818dc>] (unlink_file_vma) from [<c027a258>] (free_pgtables+0x34/0xb8) [ 682.806858] [<c027a258>] (free_pgtables) from [<c02835a4>] (exit_mmap+0xe4/0x170) [ 682.814361] [<c02835a4>] (exit_mmap) from [<c01248e0>] (mmput+0x5c/0x110) [ 682.821171] [<c01248e0>] (mmput) from [<c012e910>] (do_exit+0x374/0xbe4) [ 682.827892] [<c012e910>] (do_exit) from [<c0130888>] (do_group_exit+0x38/0xb4) [ 682.835132] [<c0130888>] (do_group_exit) from [<c0130914>] (__wake_up_parent+0x0/0x14) [ 682.843063] irq event stamp: 1936 [ 682.846399] hardirqs last enabled at (1935): [<c02938b0>] rmqueue+0xf4/0xc64 [ 682.853553] hardirqs last disabled at (1936): [<c0100b20>] __irq_svc+0x60/0x98 [ 682.860799] softirqs last enabled at (1878): [<bf04cdcc>] raw_release+0x108/0x1f0 [can_raw] [ 682.869256] softirqs last disabled at (1876): [<c0b8f478>] release_sock+0x18/0x98 [ 682.876753] ---[ end trace 7bca4751ce44c444 ]--- This patch fixes the problem by replacing the kfree_skb() by dev_kfree_skb_any(), as rx-offload might be called from threaded IRQ handlers as well. Fixes: ca913f1ac024 ("can: rx-offload: can_rx_offload_queue_sorted(): fix error handling, avoid skb mem leak") Fixes: 6caf8a6d6586 ("can: rx-offload: can_rx_offload_queue_tail(): fix error handling, avoid skb mem leak") Link: http://lore.kernel.org/r/20201019190524.1285319-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Minor conflicts in net/mptcp/protocol.h and tools/testing/selftests/net/Makefile. In both cases code was added on both sides in the same place so just keep both. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-07can: xilinx_can: Fix incorrect variable and initialize with a default valueSrinivas Neeli
Some variables with incorrect type were passed to "of_property_read_u32" API, "of_property_read_u32" API was expecting an "u32 *" but the formal parameter that was passed was of type "int *". Fixed the issue by changing the variable types from "int" to "u32" and initialized with a default value. Fixed sparse warning. Addresses-Coverity: "incompatible_param" Addresses-Coverity: "UNINIT(Using uninitialized value)" Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/0651544d22f3c25893ca9d445b14823f0dfddfc8.1600073396.git.michal.simek@xilinx.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07can: xilinx_can: Check return value of set_reset_modeSrinivas Neeli
Check return value of set_reset_mode() for error. Addresses-Coverity: "check_return" Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/bac2c2b857986472a11db341b3f6f7a8905ad0dd.1600073396.git.michal.simek@xilinx.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07can: xilinx_can: Limit CANFD brp to 2Srinivas Neeli
Bit enlarging is observed for CANFD2.0 when brp is 1, So change brp_min value to 2. Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/bca871d7f3ca9c653d50e63c5b60028f2bdf3fb0.1600073396.git.michal.simek@xilinx.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07can: flexcan: remove ack_grp and ack_bit handling from driverMarc Kleine-Budde
Since commit: 048e3a34a2e7 can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment the driver polls the IP core's internal bit MCR[LPM_ACK] as stop mode acknowledge and not the acknowledgment on chip level. This means the 4th and 5th value of the property "fsl,stop-mode" isn't used anymore. This patch removes the used "ack_gpr" and "ack_bit" from the driver. Link: http://lore.kernel.org/r/20201006203748.1750156-15-mkl@pengutronix.de Fixes: 048e3a34a2e7 ("can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment") Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07can: dev: add a helper function to calculate the duration of one bitVincent Mailhol
Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available through include/linux/can/dev.h Add an helper function can_bit_time() which returns the duration (in time quanta) of one CAN bit. Rationale for this patch: the sync segment and the bit time are two concepts which are defined in the CAN ISO standard. Device drivers for CAN might need those. Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for additional information. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20201002154219.4887-6-mailhol.vincent@wanadoo.fr [mkl: Let can_bit_time() return an unsinged int, make argument const] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-06can: m_can_platform: don't call m_can_class_suspend in runtime suspendLucas Stach
0704c5743694 can: m_can_platform: remove unnecessary m_can_class_resume() call removed the m_can_class_resume() call in the runtime resume path to get rid of a infinite recursion, so the runtime resume now only handles the device clocks. Unfortunately it did not remove the complementary m_can_class_suspend() call in the runtime suspend function, so those paths are now unbalanced, which causes the pinctrl state to get stuck on the "sleep" state, which breaks all CAN functionality on SoCs where this state is defined. Remove the m_can_class_suspend() call to fix this. Fixes: 0704c5743694 can: m_can_platform: remove unnecessary m_can_class_resume() call Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20200811081545.19921-1-l.stach@pengutronix.de Acked-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-06can: c_can: reg_map_{c,d}_can: mark as __maybe_unusedMarc Kleine-Budde
This patch marks the arrays reg_map_c_can and reg_map_d_can as __maybe_unused, as they are indeed unused in the c_can driver. This warning shows up, when compiling the kernel with "W=1": drivers/net/can/c_can/c_can.c:45: drivers/net/can/c_can/c_can.h:124:18: warning: ‘reg_map_d_can’ defined but not used [-Wunused-const-variable=] drivers/net/can/c_can/c_can.h:84:18: warning: ‘reg_map_c_can’ defined but not used [-Wunused-const-variable=] Link: http://lore.kernel.org/r/20201006203748.1750156-4-mkl@pengutronix.de Fixes: 33f810097769 ("can: c_can: Move overlay structure to array with offset as index") Fixes: 69927fccd96b ("can: c_can: Add support for Bosch D_CAN controller") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-06can: softing: softing_card_shutdown(): add braces around empty body in an ↵Marc Kleine-Budde
'if' statement This patch fixes the following warning when building the kernel with "W=1": warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] Link: http://lore.kernel.org/r/20201006203748.1750156-3-mkl@pengutronix.de Fixes: 03fd3cf5a179 ("can: add driver for Softing card") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: flexcan: disable runtime PM if register flexcandev failedJoakim Zhang
Disable runtime PM if register flexcandev failed, and balance reference of usage_count. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200929211557.14153-4-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: flexcan: add flexcan driver for i.MX8MPJoakim Zhang
Add flexcan driver for i.MX8MP, which supports CAN FD and ECC. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200929211557.14153-3-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: flexcan: initialize all flexcan memory for ECC functionJoakim Zhang
One issue was reported at a baremetal environment, which is used for FPGA verification. "The first transfer will fail for extended ID format(for both 2.0B and FD format), following frames can be transmitted and received successfully for extended format, and standard format don't have this issue. This issue occurred randomly with high possiblity, when it occurs, the transmitter will detect a BIT1 error, the receiver a CRC error. According to the spec, a non-correctable error may cause this transfer failure." With FLEXCAN_QUIRK_DISABLE_MECR quirk, it supports correctable errors, disable non-correctable errors interrupt and freeze mode. Platform has ECC hardware support, but select this quirk, this issue may not come to light. Initialize all FlexCAN memory before accessing them, at least it can avoid non-correctable errors detected due to memory uninitialized. The internal region can't be initialized when the hardware doesn't support ECC. According to IMX8MPRM, Rev.C, 04/2020. There is a NOTE at the section 11.8.3.13 Detection and correction of memory errors: "All FlexCAN memory must be initialized before starting its operation in order to have the parity bits in memory properly updated. CTRL2[WRMFRZ] grants write access to all memory positions that require initialization, ranging from 0x080 to 0xADF and from 0xF28 to 0xFFF when the CAN FD feature is enabled. The RXMGMASK, RX14MASK, RX15MASK, and RXFGMASK registers need to be initialized as well. MCR[RFEN] must not be set during memory initialization." Memory range from 0x080 to 0xADF, there are reserved memory (unimplemented by hardware, e.g. only configure 64 MBs), these memory can be initialized or not. In this patch, initialize all flexcan memory which includes reserved memory. In this patch, create FLEXCAN_QUIRK_SUPPORT_ECC for platforms which has ECC feature. If you have a ECC platform in your hand, please select this qurik to initialize all flexcan memory firstly, then you can select FLEXCAN_QUIRK_DISABLE_MECR to only enable correctable errors. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200929211557.14153-2-qiangqing.zhang@nxp.com [mkl: wrap long lines] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename all remaining occurrence to mcp251xfdMarc Kleine-Budde
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all non user facing occurrence of "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD". [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename all user facing strings to mcp251xfdMarc Kleine-Budde
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all user facing strings from "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD", including: - kconfig symbols - name of kernel module - DT and SPI compatible [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-9-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename driver files and subdir to mcp251xfdMarc Kleine-Budde
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes the name of the driver subdir and the individual files accordinly. [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: narrow down wildcards in device tree bindings to ↵Thomas Kopp
"microchip,mcp251xfd" The wildcard should be narrowed down to prevent existing and future devices that are not compatible from matching. It is very unlikely that incompatible devices will be released that do not match the wildcard. Discussion Reference: https://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Link: https://lore.kernel.org/r/20200930091423.755-1-thomas.kopp@microchip.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_irq(): add missing initialization of variable ↵Marc Kleine-Budde
set_normal mode This patch fixes the following warning: drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c:2155 mcp25xxfd_irq() error: uninitialized symbol 'set_normal_mode'. by adding the missing initialization. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/r/20200923114726.2704426-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_ring_free(): fix memory leak during cleanupDan Carpenter
This loop doesn't free the first element of the array. The "i > 0" has to be changed to "i >= 0". Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200923112752.GA1473821@mwanda Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_probe(): add SPI clk limit related errata informationThomas Kopp
This patch adds a reference to the recent released MCP2517FD and MCP2518FD errata sheets and paste the explanation. The driver already implements the proposed fix. Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Link: https://lore.kernel.org/r/20200925065606.358-1-thomas.kopp@microchip.com [mkl: split into two patches, adjust subject and commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp25xxfd: mcp25xxfd_handle_eccif(): add ECC related errata and update ↵Thomas Kopp
log messages This patch adds a reference to the recent released MCP2517FD and MCP2518FD errata sheets and paste the explanation. The single error correction does not always work, so always indicate that a single error occurred. If the location of the ECC error is outside of the TX-RAM always use netdev_notice() to log the problem. For ECC errors in the TX-RAM, there is a recovery procedure. Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Link: https://lore.kernel.org/r/20200925065606.358-1-thomas.kopp@microchip.com [mkl: split into two patches, adjust subject and commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: add lx2160ar1 supportJoakim Zhang
The Flexcan on lx2160ar1 supports CAN FD protocol. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20190712075926.7357-9-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: add imx8qm supportJoakim Zhang
The Flexcan on i.MX8QM supports CAN FD protocol. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20190712075926.7357-8-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: add Transceiver Delay Compensation supportJoakim Zhang
The CAN-FD protocol allows the transmission and reception of data at a higher bit rate than the nominal rate used in the arbitration phase when the message's BRS bit is set. The TDC mechanism is effective only during the data phase of FD frames having BRS bit set. It has no effect either on non-FD frames, or on FD frames transmitted at normal bit rate. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20190712075926.7357-7-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: add CAN FD BRS supportJoakim Zhang
This patch adds CAN FD BitRate Switch (BRS) support to driver. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20190712075926.7357-5-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: add ISO CAN FD feature supportJoakim Zhang
ISO CAN FD is introduced to increase the failture detection capability than non-ISO CAN FD. The non-ISO CAN FD is still supported by FlexCAN so that it can be used mainly during an intermediate phase, for evaluation and development purposes. Therefore, it is strongly recommended to configure FlexCAN to the ISO CAN FD protocol by setting the ISOCANFDEN field in the CTRL2 register. NOTE: If you only set "fd on", driver will use ISO FD mode by default. You should set "fd-non-iso on" after setting "fd on" if you want to use NON ISO FD mode. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20190712075926.7357-6-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: add CAN-FD mode supportJoakim Zhang
This patch adds CAN-FD mode support to the driver, it means that payload size can extend up to 64 bytes. Bit timing always set in the CBT register, not in the CTRL1 register any more. This has an extend range of all CAN bit timing variables (PRESDIV, PROPSEG, PSEG1, PSEG2 and RJW), which will improve the bit timing accuracy. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> [mkl: move cbt-based bitrate support into separate function] Link: https://lore.kernel.org/r/20200922144429.2613631-16-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: use struct canfd_frame for CAN classic frameJoakim Zhang
This patch prepares for CAN FD mode, using struct canfd_frame can both for classic format frame and fd format frame. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20190712075926.7357-3-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: flexcan_set_bittiming(): move setup of CAN-2.0 bitiming into ↵Marc Kleine-Budde
separate function This is a patch prepares for the CAN-FD support. In a later patch the setup for canfd bittiming will be added, with this patch the change is easier to read. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200922144429.2613631-14-mkl@pengutronix.de
2020-09-22can: flexcan: add LPSR mode supportJoakim Zhang
On the i.MX7D in LPSR mode, the controller will be powered off and the configuration state is lost after system resume. Upcoming i.MX8QM/QXP will also completely power off the domain, the controller state is lost and needs restore, too. So we need to set the pinctrl state again and re-start chip to re-configuration after resume. For the wakeup case, it should not set pinctrl to sleep state by pinctrl_pm_select_sleep_state. If the interface is down before suspend, we don't need to re-configure it as it will be configured if the interface is brought up later. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20191204113249.3381-7-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: disable clocks during stop modeJoakim Zhang
Disable clocks while CAN core is in stop mode. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Tested-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20191210085721.9853-2-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: flexcan_chip_stop(): add error handling and propagate error valueJoakim Zhang
This patch implements error handling and propagates the error value of flexcan_chip_stop(). This function will be called from flexcan_suspend() in an upcoming patch in some SoCs which support LPSR mode. Add a new function flexcan_chip_stop_disable_on_error() that tries to disable the chip even in case of errors. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> [mkl: introduce flexcan_chip_stop_disable_on_error() and use it in flexcan_close()] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200922144429.2613631-11-mkl@pengutronix.de
2020-09-22can: flexcan: add correctable errors correction when HW supports ECCJoakim Zhang
commit cdce844865be ("can: flexcan: add vf610 support for FlexCAN") From above commit by Stefan Agner, the patch just disables non-correctable errors interrupt and freeze mode. It still can correct the correctable errors since ECC enabled by default after reset (MECR[ECCDIS]=0, enable memory error correct) if HW supports ECC. commit 5e269324db5a ("can: flexcan: disable completely the ECC mechanism") From above commit by Joakim Zhang, the patch disables ECC completely (assert MECR[ECCDIS]) according to the explanation of FLEXCAN_QUIRK_DISABLE_MECR that disable memory error detection. This cause correctable errors cannot be corrected even HW supports ECC. The error correction mechanism ensures that in this 13-bit word, errors in one bit can be corrected (correctable errors) and errors in two bits can be detected but not corrected (non-correctable errors). Errors in more than two bits may not be detected. If HW supports ECC, we can use this to correct the correctable errors detected from FlexCAN memory. Then disable non-correctable errors interrupt and freeze mode to avoid that put FlexCAN in freeze mode. This patch adds correctable errors correction when HW supports ECC, and modify explanation for FLEXCAN_QUIRK_DISABLE_MECR. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20200416093126.15242-1-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: Add check for transceiver maximum bitrate limitationJoakim Zhang
CAN FD can transmit up to 8Mbps, but some transceivers only can support 5Mbps, so add check in driver. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20191030064245.12923-2-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-22can: flexcan: flexcan_probe(): make regulator xceiver optionalMarc Kleine-Budde
As the transcevier regulator is optional, this patch switches from devm_regulator_get() to devm_regulator_get_optional(). This gets rid of "using dummy regulator" warning message from the regulator core, if no regulator is available. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200922144429.2613631-8-mkl@pengutronix.de
2020-09-22can: flexcan: Ack wakeup interrupt separatelyJoakim Zhang
As FLEXCAN_ESR_ALL_INT is for all bus errors and state change IRQ sources, strictly speaking FLEXCAN_ESR_WAK_INT does not belong to these. So add wakeup interrupt ack separately to existing ack of the interrupts. Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20191204113249.3381-3-qiangqing.zhang@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 01:33:33 +0000