summaryrefslogtreecommitdiff
path: root/drivers/net/can/kvaser_pciefd.c
AgeCommit message (Collapse)AuthorFilesLines
2022-07-28can: kvaser_pciefd: advertise timestamping capabilities and add ioctl supportVincent Mailhol1-0/+7
Currently, userland has no method to query which timestamping features are supported by the kvaser_pciefd driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertise what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). Here, we use the CAN specific can_ethtool_op_get_ts_info_hwts() function to achieve this. In addition, the driver currently does not support the hardware timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and SIOCGHWTSTAMP is "should". This patch fills up that gap by implementing net_device_ops::ndo_eth_ioctl() using the CAN specific function can_eth_ioctl_hwts(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers CC: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20220727101641.198847-12-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-20can: add CAN_ERR_CNT flag to notify availability of error counterVincent Mailhol1-1/+1
Add a dedicated flag in uapi/linux/can/error.h to notify the userland that fields data[6] and data[7] of the CAN error frame were respectively populated with the tx and rx error counters. For all driver tree-wide, set up this flags whenever needed. Link: https://lore.kernel.org/all/20220719143550.3681-12-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-5/+6
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-5/+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-09can: kvaser_pciefd: kvaser_pciefd_rx_error_frame(): increase correct ↵Jimmy Assarsson1-1/+7
stats->{rx,tx}_errors counter Check the direction bit in the error frame packet (EPACK) to determine which net_device_stats {rx,tx}_errors counter to increase. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Link: https://lore.kernel.org/all/20211208152122.250852-1-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-16can: kvaser_pciefd: Always disable bus load reportingJimmy Assarsson1-0/+4
Under certain circumstances, when switching from Kvaser's linuxcan driver (kvpciefd) to the SocketCAN driver (kvaser_pciefd), the bus load reporting is not disabled. This is flooding the kernel log with prints like: [3485.574677] kvaser_pciefd 0000:02:00.0: Received unexpected packet type 0x00000009 Always put the controller in the expected state, instead of assuming that bus load reporting is inactive. Note: If bus load reporting is enabled when the driver is loaded, you will still get a number of bus load packages (and printouts), before it is disabled. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Link: https://lore.kernel.org/r/20210309091724.31262-1-jimmyassarsson@gmail.com Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-14can: dev: can_get_echo_skb(): extend to return can frame lengthMarc Kleine-Budde1-2/+2
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 <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20210111141930.693847-14-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
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/20210111061335.39983-1-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20210111141930.693847-13-mkl@pengutronix.de Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
2020-12-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-1/+3
Conflicts: drivers/net/ethernet/ibm/ibmvnic.c Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-30can: kvaser_pciefd: kvaser_pciefd_open(): fix error handlingZhang Qilong1-1/+3
If kvaser_pciefd_bus_on() failed, we should call close_candev() to avoid reference leak. Fixes: 26ad340e582d3 ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201128133922.3276973-3-zhangqilong3@huawei.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-20can: rename CAN FD related can_len2dlc and can_dlc2len helpersOliver Hartkopp1-3/+3
The helper functions can_len2dlc and can_dlc2len are only relevant for CAN FD data length code (DLC) conversion. To fit the introduced can_cc_dlc2len for Classical CAN we rename: can_dlc2len -> can_fd_dlc2len to get the payload length from the DLC can_len2dlc -> can_fd_len2dlc to get the DLC from the payload length Suggested-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/r/20201110101852.1973-6-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-20can: replace can_dlc as variable/element for payload lengthOliver Hartkopp1-2/+2
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 <socketcan@hartkopp.net> Link: https://lore.kernel.org/r/20201120100444.3199-1-socketcan@hartkopp.net [mkl: gs_usb: keep struct gs_host_frame::can_dlc as is] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-18can: kvaser_pciefd: Fix KCAN bittiming limitsJimmy Assarsson1-2/+2
Use correct bittiming limits for the KCAN CAN controller. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20201115163027.16851-1-jimmyassarsson@gmail.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2019-09-03can: kvaser_pciefd: the PWM generator is running at the bus frequency of the ↵Christer Beskow1-1/+5
system. The system clock frequency for the bus connected to the PCIe controller shall be used when calculating the frequency of the PWM, not the CAN system clock frequency. Signed-off-by: Christer Beskow <chbe@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2019-08-13can: kvaser_pciefd: Remove unused including <linux/version.h>YueHaibing1-1/+0
Remove including <linux/version.h> that don't need it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2019-08-13can: kvaser_pciefd: kvaser_pciefd_pwm_stop(): remove unnecessary code when ↵Christer Beskow1-7/+3
setting pwm duty cycle to zero To set the duty cycle to zero (i.e. pwm_stop), the trigger value shall be equal to the top value. This is achieved by reading the value of the top bit field from the pwm register and then writing back this value to the trigger and top bit fields. Addresses-Coverity: ("Logically dead code") Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Christer Beskow <chbe@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2019-07-24can: kvaser_pciefd: Add driver for Kvaser PCIEcan devicesHenning Colliander1-0/+1912
This patch adds support for Kvaser PCIEcan devices. This includes support for up to 4 CAN channels on a single card, depending on device. Signed-off-by: Henning Colliander <henning.colliander@evidente.se> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Christer Beskow <chbe@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 19:58:30 +0000