Marc Kleine-Budde says: ==================== pull-request: can-next 2025-01-10 Pierre-Henry Moussay adds PIC64GX compatibility to the DT bindings for Microchip's mpfs-can IP core. The next 3 patches are by Sean Nyekjaer and target the tcan4x5x driver. First the DT bindings is converted to DT schema, then nWKRQ voltage selection is added to the driver. Dario Binacchi's patch for the sun4i_can makes the driver more consistent by adding a likely() to the driver. Another patch by Sean Nyekjaer for the tcan4x5x driver gets rid of a false error message. Charan Pedumuru converts the atmel-can DT bindings to DT schema. The next 2 patches are by Oliver Hartkopp. The first one maps Oliver's former mail addresses to a dedicated CAN mail address. The second one assigns net/sched/em_canid.c additionally to the CAN maintainers. Ariel Otilibili's patch removes dead code from the CAN dev helper. The next 3 patches are by Sean Nyekjaer and add HW standby support to the tcan4x5x driver. A patch by Dario Binacchi fixes the DT bindings for the st,stm32-bxcan driver. The last 4 patches are by Jimmy Assarsson and target the kvaser_usb and the kvaser_pciefd driver: error statistics are improved and CAN_CTRLMODE_BERR_REPORTING is added. * tag 'linux-can-next-for-6.14-20250110' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: kvaser_pciefd: Add support for CAN_CTRLMODE_BERR_REPORTING can: kvaser_pciefd: Update stats and state even if alloc_can_err_skb() fails can: kvaser_usb: Add support for CAN_CTRLMODE_BERR_REPORTING can: kvaser_usb: Update stats and state even if alloc_can_err_skb() fails dt-bindings: can: st,stm32-bxcan: fix st,gcan property type can: m_can: call deinit/init callback when going into suspend/resume can: tcan4x5x: add deinit callback to set standby mode can: m_can: add deinit callback can: dev: can_get_state_str(): Remove dead code MAINTAINERS: assign em_canid.c additionally to CAN maintainers mailmap: add an entry for Oliver Hartkopp dt-bindings: net: can: atmel: Convert to json schema can: tcan4x5x: get rid of false clock errors can: sun4i_can: continue to use likely() to check skb can: tcan4x5x: add option for selecting nWKRQ voltage dt-bindings: can: tcan4x5x: Document the ti,nwkrq-voltage-vio option dt-bindings: can: convert tcan4x5x.txt to DT schema dt-bindings: can: mpfs: add PIC64GX CAN compatibility ==================== Link: https://patch.msgid.link/20250110112712.3214173-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The default switch case ends with a return; meaning this return is never reached. Coverity-ID: 1497123 Signed-off-by: Ariel Otilibili <ariel.otilibili-anieli@eurecom.fr> Link: https://patch.msgid.link/20241221111454.1074285-4-ariel.otilibili-anieli@eurecom.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
In commit 6e86a1543c37 ("can: dev: provide optional GPIO based
termination support") GPIO based termination support was added.
For no particular reason that patch uses gpiod_set_value() to set the
GPIO. This leads to the following warning, if the systems uses a
sleeping GPIO, i.e. behind an I2C port expander:
| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c
| CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c
Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the
use of sleeping GPIOs.
Cc: Nicolai Buchwitz <nb@tipi-net.de>
Cc: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Cc: stable@vger.kernel.org
Reported-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Tested-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Fixes: 6e86a1543c37 ("can: dev: provide optional GPIO based termination support")
Link: https://patch.msgid.link/20241121-dev-fix-can_set_termination-v1-1-41fa6e29216d@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20240901112803.212753-3-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch moves the evaluation of data[IFLA_CAN_CTRLMODE] in function can_changelink in front of the evaluation of data[IFLA_CAN_BITTIMING]. This avoids a call to do_set_data_bittiming providing a stale can_priv::ctrlmode with a CAN_CTRLMODE_FD flag not matching the requested state when switching between a CAN Classic and CAN-FD bitrate. In the same manner the evaluation of data[IFLA_CAN_CTRLMODE] in function can_validate is also moved in front of the evaluation of data[IFLA_CAN_BITTIMING]. This is a preparation for patches where the nominal and data bittiming may have interdependencies on the driver side depending on the CAN_CTRLMODE_FD flag state. Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Link: https://patch.msgid.link/20240808164224.213522-1-stefan.maetje@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
In prevision to add new UAPI for hwtstamp we will be limited to the struct ethtool_ts_info that is currently passed in fixed binary format through the ETHTOOL_GET_TS_INFO ethtool ioctl. It would be good if new kernel code already started operating on an extensible kernel variant of that structure, similar in concept to struct kernel_hwtstamp_config vs struct hwtstamp_config. Since struct ethtool_ts_info is in include/uapi/linux/ethtool.h, here we introduce the kernel-only structure in include/linux/ethtool.h. The manual copy is then made in the function called by ETHTOOL_GET_TS_INFO. Acked-by: Shannon Nelson <shannon.nelson@amd.com> Acked-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20240709-feature_ptp_netnext-v17-6-b5317f50df2a@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Simon reported that ndo_change_mtu() methods were never
updated to use WRITE_ONCE(dev->mtu, new_mtu) as hinted
in commit 501a90c94510 ("inet: protect against too small
mtu values.")
We read dev->mtu without holding RTNL in many places,
with READ_ONCE() annotations.
It is time to take care of ndo_change_mtu() methods
to use corresponding WRITE_ONCE()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Simon Horman <horms@kernel.org>
Closes: https://lore.kernel.org/netdev/20240505144608.GB67882@kernel.org/
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Simon Horman <horms@kernel.org>
Acked-by: Shannon Nelson <shannon.nelson@amd.com>
Link: https://lore.kernel.org/r/20240506102812.3025432-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The TDCO calculation was done using the currently applied data bittiming,
instead of the newly computed data bittiming, which means that the TDCO
had an invalid value unless setting the same data bittiming twice.
Fixes: d99755f71a80 ("can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)")
Signed-off-by: Maxime Jayat <maxime.jayat@mobile-devices.fr>
Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://lore.kernel.org/all/40579c18-63c0-43a4-8d4c-f3a6c1c0b417@munic.io
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Now that napi_schedule return a bool, we can drop napi_reschedule that
does the same exact function. The function comes from a very old commit
bfe13f54f502 ("ibm_emac: Convert to use napi_struct independent of struct
net_device") and the purpose is actually deprecated in favour of
different logic.
Convert every user of napi_reschedule to napi_schedule.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> # ath10k
Acked-by: Nick Child <nnac123@linux.ibm.com> # ibm
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for can/dev/rx-offload.c
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://lore.kernel.org/r/20231009133754.9834-3-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some CAN controllers do not have a register that contains the current CAN state, but only a register that contains the error counters. Introduce a new function can_state_get_by_berr_counter() that returns the current TX and RX state depending on the provided CAN bit error counters. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-1-9987d53600e0@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>