aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/can/xilinx_can.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2018-11-28can: xilinx: add can 2.0 supportShubhrajyoti Datta1-1/+33
Add support for can 2.0. Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-28can: xilinx: fix return type of ndo_start_xmit functionYueHaibing1-1/+1
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-27can: xilinx_can: add support for Xilinx CAN FD coreAnssi Hannula1-44/+259
Add support for Xilinx CAN FD core. The major difference from the previously supported cores is that there are TX mailboxes instead of a TX FIFO and the RX FIFO access method is different. We only transmit one frame at a time to prevent the HW from reordering frames (it uses CAN ID priority order). Support for CAN FD protocol is not added yet. v2: Removed unnecessary "rx-mode" DT property and wrapped some long lines. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-27can: xilinx_can: refactor code in preparation for CAN FD supportAnssi Hannula1-88/+118
Xilinx CAN FD cores are different enough from the previous Zynq and AXI CAN cores that some refactoring of the driver is needed. This commit contains most of the required refactoring to existing code and should not alter behavior on existing supported HW. The changes are: - Reading and writing to frame registers is parametrized to allow reading/writing a different frame in the future. - Slightly misleading (as it did not specify *all* the interrupts supported by the HW) XCAN_INTR_ALL is replaced with specifying the interrupts inline in interrupt enabling code. - xcan_devtype_data.caps is renamed to xcan_devtype_data.flags to allow for flags that define alternative functionality (e.g. mailboxes vs. FIFO) instead of purely additive capabilities. - can_bittiming_const is added to xcan_devtype_data as CAN FD cores will have wider setting ranges. - bus_clk clock name is now determined through xcan_devtype_data instead of comparing compatible string in probe(). - xcan_devtype_data is added to xcan_priv to allow flag checks after probe(). - XCAN_CAP_WATERMARK is now XCAN_FLAG_TXFEMP. CAN FD cores have watermark support but no TXFEMP interrupt, which is what we are actually interested in. - xcan_start_xmit() is split to in two parts to prepare for TX mailboxes instead of FIFO in CAN FD cores. v2: Wrapped some long lines in xcan_write_frame(). Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-27can: xilinx_can: update stats.tx_bytes after transmissionAnssi Hannula1-4/+2
The driver updates stats.tx_bytes in start_xmit() even though it could do so in TX interrupt handler. Change the code to update tx_bytes in the interrupt handler, using the return value of can_get_echo_skb(). Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-27can: xilinx_can: use can_change_state()Anssi Hannula1-27/+7
Replace some custom code with a call to can_change_state(). This subtly changes the error reporting behavior when both RX and TX error counters indicate the same state. Previously, if both RX and TX counters indicated the same state: - if overall state is PASSIVE, report CAN_ERR_CRTL_RX_PASSIVE - if overall state is WARNING, report CAN_ERR_CRTL_TX_WARNING or CAN_ERR_CRTL_RX_WARNING depending on which counter is higher, or CAN_ERR_CRTL_RX_WARNING if the counters have the same value. After this commit: - report RX_* or TX_* depending on which counter is higher, or both if the counters have exactly the same value. This behavior is consistent with many other CAN drivers that use this same code pattern. Tested with the integrated CAN on Zynq-7000 SoC. v2: Simplify resolving states as suggested by Andri Yngvason. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-27can: xilinx_can: only report warning and passive states on state changesAnssi Hannula1-1/+2
The xilinx_can driver currently increments error-warning and error-passive statistics on every error interrupt regardless of whether the interface was already in the same state. Similarly, the error frame sent on error interrupts is always sent with CAN_ERR_CRTL_(RX|TX)_(PASSIVE|WARNING) bit set. To make the error-warning and error-passive statistics more useful, add a check to only set the error state when the state has actually been changed. Tested with the integrated CAN on Zynq-7000 SoC. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-27can: xilinx: fix xcan_start_xmit()'s return typeLuc Van Oostenryck1-2/+2
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, but the implementation in this driver returns an 'int'. Fix this by returning 'netdev_tx_t' in this driver too. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Acked-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-23can: xilinx_can: fix power management handlingAnssi Hannula1-41/+28
There are several issues with the suspend/resume handling code of the driver: - The device is attached and detached in the runtime_suspend() and runtime_resume() callbacks if the interface is running. However, during xcan_chip_start() the interface is considered running, causing the resume handler to incorrectly call netif_start_queue() at the beginning of xcan_chip_start(), and on xcan_chip_start() error return the suspend handler detaches the device leaving the user unable to bring-up the device anymore. - The device is not brought properly up on system resume. A reset is done and the code tries to determine the bus state after that. However, after reset the device is always in Configuration mode (down), so the state checking code does not make sense and communication will also not work. - The suspend callback tries to set the device to sleep mode (low-power mode which monitors the bus and brings the device back to normal mode on activity), but then immediately disables the clocks (possibly before the device reaches the sleep mode), which does not make sense to me. If a clean shutdown is wanted before disabling clocks, we can just bring it down completely instead of only sleep mode. Reorganize the PM code so that only the clock logic remains in the runtime PM callbacks and the system PM callbacks contain the device bring-up/down logic. This makes calling the runtime PM callbacks during e.g. xcan_chip_start() safe. The system PM callbacks now simply call common code to start/stop the HW if the interface was running, replacing the broken code from before. xcan_chip_stop() is updated to use the common reset code so that it will wait for the reset to complete. Reset also disables all interrupts so do not do that separately. Also, the device_may_wakeup() checks are removed as the driver does not have wakeup support. Tested on Zynq-7000 integrated CAN. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Michal Simek <michal.simek@xilinx.com> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-23can: xilinx_can: fix incorrect clear of non-processed interruptsAnssi Hannula1-5/+5
xcan_interrupt() clears ERROR|RXOFLV|BSOFF|ARBLST interrupts if any of them is asserted. This does not take into account that some of them could have been asserted between interrupt status read and interrupt clear, therefore clearing them without handling them. Fix the code to only clear those interrupts that it knows are asserted and therefore going to be processed in xcan_err_interrupt(). Fixes: b1201e44f50b ("can: xilinx CAN controller support") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Michal Simek <michal.simek@xilinx.com> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-23can: xilinx_can: fix RX overflow interrupt not being enabledAnssi Hannula1-1/+1
RX overflow interrupt (RXOFLW) is disabled even though xcan_interrupt() processes it. This means that an RX overflow interrupt will only be processed when another interrupt gets asserted (e.g. for RX/TX). Fix that by enabling the RXOFLW interrupt. Fixes: b1201e44f50b ("can: xilinx CAN controller support") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Michal Simek <michal.simek@xilinx.com> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-23can: xilinx_can: keep only 1-2 frames in TX FIFO to fix TX accountingAnssi Hannula1-16/+123
The xilinx_can driver assumes that the TXOK interrupt only clears after it has been acknowledged as many times as there have been successfully sent frames. However, the documentation does not mention such behavior, instead saying just that the interrupt is cleared when the clear bit is set. Similarly, testing seems to also suggest that it is immediately cleared regardless of the amount of frames having been sent. Performing some heavy TX load and then going back to idle has the tx_head drifting further away from tx_tail over time, steadily reducing the amount of frames the driver keeps in the TX FIFO (but not to zero, as the TXOK interrupt always frees up space for 1 frame from the driver's perspective, so frames continue to be sent) and delaying the local echo frames. The TX FIFO tracking is also otherwise buggy as it does not account for TX FIFO being cleared after software resets, causing BUG!, TX FIFO full when queue awake! messages to be output. There does not seem to be any way to accurately track the state of the TX FIFO for local echo support while using the full TX FIFO. The Zynq version of the HW (but not the soft-AXI version) has watermark programming support and with it an additional TX-FIFO-empty interrupt bit. Modify the driver to only put 1 frame into TX FIFO at a time on soft-AXI and 2 frames at a time on Zynq. On Zynq the TXFEMP interrupt bit is used to detect whether 1 or 2 frames have been sent at interrupt processing time. Tested with the integrated CAN on Zynq-7000 SoC. The 1-frame-FIFO mode was also tested. An alternative way to solve this would be to drop local echo support but keep using the full TX FIFO. v2: Add FIFO space check before TX queue wake with locking to synchronize with queue stop. This avoids waking the queue when xmit() had just filled it. v3: Keep local echo support and reduce the amount of frames in FIFO instead as suggested by Marc Kleine-Budde. Fixes: b1201e44f50b ("can: xilinx CAN controller support") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-23can: xilinx_can: fix recovery from error states not being propagatedAnssi Hannula1-28/+127
The xilinx_can driver contains no mechanism for propagating recovery from CAN_STATE_ERROR_WARNING and CAN_STATE_ERROR_PASSIVE. Add such a mechanism by factoring the handling of XCAN_STATE_ERROR_PASSIVE and XCAN_STATE_ERROR_WARNING out of xcan_err_interrupt and checking for recovery after RX and TX if the interface is in one of those states. Tested with the integrated CAN on Zynq-7000 SoC. Fixes: b1201e44f50b ("can: xilinx CAN controller support") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-23can: xilinx_can: fix RX loop if RXNEMP is asserted without RXOKAnssi Hannula1-13/+5
If the device gets into a state where RXNEMP (RX FIFO not empty) interrupt is asserted without RXOK (new frame received successfully) interrupt being asserted, xcan_rx_poll() will continue to try to clear RXNEMP without actually reading frames from RX FIFO. If the RX FIFO is not empty, the interrupt will not be cleared and napi_schedule() will just be called again. This situation can occur when: (a) xcan_rx() returns without reading RX FIFO due to an error condition. The code tries to clear both RXOK and RXNEMP but RXNEMP will not clear due to a frame still being in the FIFO. The frame will never be read from the FIFO as RXOK is no longer set. (b) A frame is received between xcan_rx_poll() reading interrupt status and clearing RXOK. RXOK will be cleared, but RXNEMP will again remain set as the new message is still in the FIFO. I'm able to trigger case (b) by flooding the bus with frames under load. There does not seem to be any benefit in using both RXNEMP and RXOK in the way the driver does, and the polling example in the reference manual (UG585 v1.10 18.3.7 Read Messages from RxFIFO) also says that either RXOK or RXNEMP can be used for detecting incoming messages. Fix the issue and simplify the RX processing by only using RXNEMP without RXOK. Tested with the integrated CAN on Zynq-7000 SoC. Fixes: b1201e44f50b ("can: xilinx CAN controller support") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-07-23can: xilinx_can: fix device dropping off bus on RX overrunAnssi Hannula1-1/+0
The xilinx_can driver performs a software reset when an RX overrun is detected. This causes the device to enter Configuration mode where no messages are received or transmitted. The documentation does not mention any need to perform a reset on an RX overrun, and testing by inducing an RX overflow also indicated that the device continues to work just fine without a reset. Remove the software reset. Tested with the integrated CAN on Zynq-7000 SoC. Fixes: b1201e44f50b ("can: xilinx CAN controller support") Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Cc: <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2017-01-30drivers: net: generalize napi_complete_done()Eric Dumazet1-1/+1
napi_complete_done() allows to opt-in for gro_flush_timeout, added back in linux-3.19, commit 3b47d30396ba ("net: gro: add a per device gro flush timer") This allows for more efficient GRO aggregation without sacrifying latencies. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-6/+3
Conflicts: drivers/net/ethernet/renesas/ravb_main.c kernel/bpf/syscall.c net/ipv4/ipmr.c All three conflicts were cases of overlapping changes. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-23can: xilinx: Convert to runtime_pmKedareswara rao Appana1-75/+101
Instead of enabling/disabling clocks at several locations in the driver, Use the runtime_pm framework. This consolidates the actions for runtime PM In the appropriate callbacks and makes the driver more readable and mantainable. Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-11-23can: remove obsolete assignment for CAN protocol error typeOliver Hartkopp1-3/+1
The assignment 'cf->data[2] |= CAN_ERR_PROT_UNSPEC' used at CAN error message creation time is obsolete as CAN_ERR_PROT_UNSPEC is zero and cf->data[2] is initialized with zero in alloc_can_err_skb() anyway. So we could either assign 'cf->data[2] = CAN_ERR_PROT_UNSPEC' correctly or we can remove the obsolete OR operation entirely. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-11-23can: fix assignment of error location in CAN error messagesOliver Hartkopp1-3/+2
As Dan Carpenter reported in http://marc.info/?l=linux-can&m=144793696016187 the assignment of the error location in CAN error messages had some bit wise overlaps. Indeed the value to be assigned in data[3] is no bitfield but defines a single value which points to a location inside the CAN frame on the wire. This patch fixes the assignments for the error locations in error messages. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-05-01net: can: xilinx_can: fix extended frame handlingJeppe Ledet-Pedersen1-3/+4
Using IDR_SRR in RXFIFO_ID to test for the presence of data is only valid for standard frames. For extended frames the bit is always 1 and IDR_RTR should be used instead. This patch switches the check to use CAN_RTR_FLAG which is correctly set when reading the ID. The patch also changes the DW1/DW2 to be read unconditionally, since this is necessary to remove the frame from the RXFIFO. Signed-off-by: Jeppe Ledet-Pedersen <jlp@gomspace.com> Acked-by: Kedareswara rao Appana <appanad@xilinx.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-03-17can: constify of_device_id arrayFabian Frederick1-1/+1
of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-14Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-coreLinus Torvalds1-1/+0
Pull driver core update from Greg KH: "Here's the set of driver core patches for 3.19-rc1. They are dominated by the removal of the .owner field in platform drivers. They touch a lot of files, but they are "simple" changes, just removing a line in a structure. Other than that, a few minor driver core and debugfs changes. There are some ath9k patches coming in through this tree that have been acked by the wireless maintainers as they relied on the debugfs changes. Everything has been in linux-next for a while" * tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits) Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries" fs: debugfs: add forward declaration for struct device type firmware class: Deletion of an unnecessary check before the function call "vunmap" firmware loader: fix hung task warning dump devcoredump: provide a one-way disable function device: Add dev_<level>_once variants ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries ath: use seq_file api for ath9k debugfs files debugfs: add helper function to create device related seq_file drivers/base: cacheinfo: remove noisy error boot message Revert "core: platform: add warning if driver has no owner" drivers: base: support cpu cache information interface to userspace via sysfs drivers: base: add cpu_device_create to support per-cpu devices topology: replace custom attribute macros with standard DEVICE_ATTR* cpumask: factor out show_cpumap into separate helper function driver core: Fix unbalanced device reference in drivers_probe driver core: fix race with userland in device_add() sysfs/kernfs: make read requests on pre-alloc files use the buffer. sysfs/kernfs: allow attributes to request write buffer be pre-allocated. fs: sysfs: return EGBIG on write if offset is larger than file size ...
2014-11-18can: xilinx_can: add .ndo_change_mtu functionMarc Kleine-Budde1-0/+1
Use common can_change_mtu function. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-11-18can: xilinx_can: fix comparison of unsigned variableSudip Mukherjee1-1/+2
The variable err was of the type u32. It was being compared with < 0, and being an unsigned variable the comparison would have been always false. Moreover, err was getting the return value from set_reset_mode() and xcan_set_bittiming(), and both are returning int. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Reviewed-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2014-10-20net: can: drop owner assignment from platform_driversWolfram Sang1-1/+0
A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-05-26can: xilinx CAN controller supportKedareswara rao Appana1-0/+1208
This patch adds xilinx CAN controller support. This driver supports both ZYNQ CANPS and Soft IP AXI CAN controller. Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>