<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/net/can/rcar, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/net/can/rcar?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/net/can/rcar?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-05-19T20:15:51Z</updated>
<entry>
<title>can: can-dev: remove obsolete CAN LED support</title>
<updated>2022-05-19T20:15:51Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-05-18T15:45:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6c1e423a3c84953edcf91ff03ab97829b287184a'/>
<id>urn:sha1:6c1e423a3c84953edcf91ff03ab97829b287184a</id>
<content type='text'>
Since commit 30f3b42147ba6f ("can: mark led trigger as broken") the
CAN specific LED support was disabled and marked as BROKEN. As the
common LED support with CONFIG_LEDS_TRIGGER_NETDEV should do this work
now the code can be removed as preparation for a CAN netdevice Kconfig
rework.

Link: https://lore.kernel.org/all/20220518154527.29046-1-socketcan@hartkopp.net
Suggested-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
[mkl: remove led.h from MAINTAINERS]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: can-dev: move to netif_napi_add_weight()</title>
<updated>2022-05-19T20:11:28Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-05-17T00:23:45Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=caf6b7f81e053dfdc5f16e943b355bc954e0de34'/>
<id>urn:sha1:caf6b7f81e053dfdc5f16e943b355bc954e0de34</id>
<content type='text'>
We want to remove the weight argument from the basic version of the
netif_napi_add() call. Move all the callers in drivers/net/can that
pass a custom weight (i.e. not NAPI_POLL_WEIGHT or 64) to the
netif_napi_add_weight() API.

Link: https://lore.kernel.org/all/20220517002345.1812104-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: rcar_canfd: Add support for r8a779a0 SoC</title>
<updated>2022-03-10T08:49:13Z</updated>
<author>
<name>Ulrich Hecht</name>
<email>uli+renesas@fpond.eu</email>
</author>
<published>2022-03-09T16:26:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=45721c406dcf50d4a20f95afafe8e1a2a7fa2341'/>
<id>urn:sha1:45721c406dcf50d4a20f95afafe8e1a2a7fa2341</id>
<content type='text'>
Adds support for the CANFD IP variant in the V3U SoC.

Differences to controllers in other SoCs are limited to an increase in
the number of channels from two to eight, an absence of dedicated
registers for "classic" CAN mode, and a number of differences in magic
numbers (register offsets and layouts).

Inspired by BSP patch by Kazuya Mizuguchi.

Link: https://lore.kernel.org/all/20220309162609.3726306-2-uli+renesas@fpond.eu
Signed-off-by: Ulrich Hecht &lt;uli+renesas@fpond.eu&gt;
Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: rcar_canfd: rcar_canfd_channel_probe(): register the CAN device when fully ready</title>
<updated>2022-02-25T16:46:54Z</updated>
<author>
<name>Lad Prabhakar</name>
<email>prabhakar.mahadev-lad.rj@bp.renesas.com</email>
</author>
<published>2022-02-21T22:59:35Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c5048a7b2c23ab589f3476a783bd586b663eda5b'/>
<id>urn:sha1:c5048a7b2c23ab589f3476a783bd586b663eda5b</id>
<content type='text'>
Register the CAN device only when all the necessary initialization is
completed. This patch makes sure all the data structures and locks are
initialized before registering the CAN device.

Link: https://lore.kernel.org/all/20220221225935.12300-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Reported-by: Pavel Machek &lt;pavel@denx.de&gt;
Signed-off-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Reviewed-by: Pavel Machek &lt;pavel@denx.de&gt;
Reviewed-by: Ulrich Hecht &lt;uli+renesas@fpond.eu&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2022-01-10T01:00:17Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-01-10T00:59:30Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8aaaf2f3af2ae212428f4db1af34214225f5cec3'/>
<id>urn:sha1:8aaaf2f3af2ae212428f4db1af34214225f5cec3</id>
<content type='text'>
Merge in fixes directly in prep for the 5.17 merge window.
No conflicts.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: rcar_canfd: rcar_canfd_channel_probe(): make sure we free CAN network device</title>
<updated>2022-01-09T12:32:28Z</updated>
<author>
<name>Lad Prabhakar</name>
<email>prabhakar.mahadev-lad.rj@bp.renesas.com</email>
</author>
<published>2022-01-06T11:48:00Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=72b1e360572f9fa7d08ee554f1da29abce23f288'/>
<id>urn:sha1:72b1e360572f9fa7d08ee554f1da29abce23f288</id>
<content type='text'>
Make sure we free CAN network device in the error path. There are
several jumps to fail label after allocating the CAN network device
successfully. This patch places the free_candev() under fail label so
that in failure path a jump to fail label frees the CAN network
device.

Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family")
Link: https://lore.kernel.org/all/20220106114801.20563-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Reported-by: Pavel Machek &lt;pavel@denx.de&gt;
Signed-off-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Reviewed-by: Kieran Bingham &lt;kieran.bingham+renesas@ideasonboard.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: add sanity check in can_set_static_ctrlmode()</title>
<updated>2022-01-05T11:09:05Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-13T16:02:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=7d4a101c0bd3c6e5c6e45c705a54f7bc8f6c128d'/>
<id>urn:sha1:7d4a101c0bd3c6e5c6e45c705a54f7bc8f6c128d</id>
<content type='text'>
Previous patch removed can_priv::ctrlmode_static to replace it with
can_get_static_ctrlmode().

A condition sine qua non for this to work is that the controller
static modes should never be set in can_priv::ctrlmode_supported
(c.f. the comment on can_priv::ctrlmode_supported which states that it
is for "options that can be *modified* by netlink"). Also, this
condition is already correctly fulfilled by all existing drivers
which rely on the ctrlmode_static feature.

Nonetheless, we added an extra safeguard in can_set_static_ctrlmode()
to return an error value and to warn the developer who would be
adventurous enough to set to static a given feature that is already
set to supported.

The drivers which rely on the static controller mode are then updated
to check the return value of can_set_static_ctrlmode().

Link: https://lore.kernel.org/all/20211213160226.56219-3-mailhol.vincent@wanadoo.fr
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: do not increase tx_bytes statistics for RTR frames</title>
<updated>2022-01-05T11:09:05Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=cc4b08c31b5c51352f258032cc65e884b3e61e6a'/>
<id>urn:sha1:cc4b08c31b5c51352f258032cc65e884b3e61e6a</id>
<content type='text'>
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::tx_bytes should not be increased when
sending RTR frames.

The function can_get_echo_skb() already returns the correct length,
even for RTR frames (c.f. [1]). However, for historical reasons, the
drivers do not use can_get_echo_skb()'s return value and instead, most
of them store a temporary length (or dlc) in some local structure or
array. Using the return value of can_get_echo_skb() solves the
issue. After doing this, such length/dlc fields become unused and so
this patch does the adequate cleaning when needed.

This patch fixes all the CAN drivers.

Finally, can_get_echo_skb() is decorated with the __must_check
attribute in order to force future drivers to correctly use its return
value (else the compiler would emit a warning).

[1] commit ed3320cec279 ("can: dev: __can_get_echo_skb():
fix real payload length return value for RTR frames")

Link: https://lore.kernel.org/all/20211207121531.42941-6-mailhol.vincent@wanadoo.fr
Cc: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Cc: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: Chen-Yu Tsai &lt;wens@csie.org&gt;
Cc: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Cc: Yasushi SHOJI &lt;yashi@spacecubics.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Stephane Grosjean &lt;s.grosjean@peak-system.com&gt;
Cc: Andreas Larsson &lt;andreas@gaisler.com&gt;
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt; # kvaser
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Acked-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Tested-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
[mkl: add conversion for grcan]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: do not increase rx_bytes statistics for RTR frames</title>
<updated>2022-01-05T11:09:05Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:30Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8e674ca74244eac1cd85c6e9a89b588a03c55ff7'/>
<id>urn:sha1:8e674ca74244eac1cd85c6e9a89b588a03c55ff7</id>
<content type='text'>
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 &lt;mkl@pengutronix.de&gt;
Cc: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Cc: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Cc: Chandrasekar Ramakrishnan &lt;rcsekar@samsung.com&gt;
Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: Chen-Yu Tsai &lt;wens@csie.org&gt;
Cc: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Cc: Yasushi SHOJI &lt;yashi@spacecubics.com&gt;
Cc: Appana Durga Kedareswara rao &lt;appana.durga.rao@xilinx.com&gt;
Cc: Naga Sureshkumar Relli &lt;naga.sureshkumar.relli@xilinx.com&gt;
Cc: Michal Simek &lt;michal.simek@xilinx.com&gt;
Cc: Stephane Grosjean &lt;s.grosjean@peak-system.com&gt;
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt; # kvaser
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Acked-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Tested-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: do not increase rx statistics when generating a CAN rx error message frame</title>
<updated>2022-01-05T11:09:05Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=676068db69b847f06fe054fca15bf6b107bd24da'/>
<id>urn:sha1:676068db69b847f06fe054fca15bf6b107bd24da</id>
<content type='text'>
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 &lt;mkl@pengutronix.de&gt;
CC: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
CC: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
CC: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
CC: Chandrasekar Ramakrishnan &lt;rcsekar@samsung.com&gt;
CC: Maxime Ripard &lt;mripard@kernel.org&gt;
CC: Chen-Yu Tsai &lt;wens@csie.org&gt;
CC: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
CC: Appana Durga Kedareswara rao &lt;appana.durga.rao@xilinx.com&gt;
CC: Naga Sureshkumar Relli &lt;naga.sureshkumar.relli@xilinx.com&gt;
CC: Michal Simek &lt;michal.simek@xilinx.com&gt;
CC: Stephane Grosjean &lt;s.grosjean@peak-system.com&gt;
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt; # kvaser
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Acked-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Tested-by: Stefan Mätje &lt;stefan.maetje@esd.eu&gt; # esd_usb2
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
