<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/can/cc770, branch v5.19</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-01-05T11:09:05+00:00</updated>
<entry>
<title>can: do not increase tx_bytes statistics for RTR frames</title>
<updated>2022-01-05T11:09:05+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:05+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:05+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-12-07T12:15:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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>
<entry>
<title>can: dev: can_get_echo_skb(): extend to return can frame length</title>
<updated>2021-01-14T07:43:43+00:00</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2021-01-11T14:19:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9420e1d495e2a3b5f673148b7e3ebc861b1441f7'/>
<id>urn:sha1:9420e1d495e2a3b5f673148b7e3ebc861b1441f7</id>
<content type='text'>
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 &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/20210111141930.693847-14-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: can_put_echo_skb(): extend to handle frame_len</title>
<updated>2021-01-14T07:43:43+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-01-11T14:19:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1dcb6e57db833419483d0df2d956b1cc2a802683'/>
<id>urn:sha1:1dcb6e57db833419483d0df2d956b1cc2a802683</id>
<content type='text'>
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 &lt;mkl@pengutronix.de&gt;
Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/20210111141930.693847-13-mkl@pengutronix.de
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
</content>
</entry>
<entry>
<title>can: replace can_dlc as variable/element for payload length</title>
<updated>2020-11-20T11:04:12+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2020-11-20T10:04:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c7b74967799b1af52b3045d69d4c26836b2d41de'/>
<id>urn:sha1:c7b74967799b1af52b3045d69d4c26836b2d41de</id>
<content type='text'>
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 (-&gt; 'len') or a data length code (-&gt; 'dlc') value.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
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 &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: rename get_can_dlc() macro with can_cc_dlc2len()</title>
<updated>2020-11-20T08:43:29+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2020-11-10T10:18:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69d98969a0540039fc04e0f22bbe9f41b0a13d66'/>
<id>urn:sha1:69d98969a0540039fc04e0f22bbe9f41b0a13d66</id>
<content type='text'>
The get_can_dlc() macro is used to ensure the payload length information of
the Classical CAN frame to be max 8 bytes (the CAN_MAX_DLEN).

Rename the macro and use the correct constant in preparation of the len/dlc
cleanup for Classical CAN frames.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/r/20201110101852.1973-3-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: drivers: fix spelling mistakes</title>
<updated>2020-09-21T08:13:16+00:00</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2020-09-15T22:34:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=88bfb9a713563550b1febb1a89b3a192efe2d091'/>
<id>urn:sha1:88bfb9a713563550b1febb1a89b3a192efe2d091</id>
<content type='text'>
This patch fixes spelling erros found by "codespell" in the
drivers/net/can subtree.

Link: https://lore.kernel.org/r/20200915223527.1417033-6-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>treewide: replace '---help---' in Kconfig files with 'help'</title>
<updated>2020-06-13T16:57:21+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2020-06-13T16:50:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a7f7f6248d9740d710fd6bd190293fe5e16410ac'/>
<id>urn:sha1:a7f7f6248d9740d710fd6bd190293fe5e16410ac</id>
<content type='text'>
Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.

This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.

There are a variety of indentation styles found.

  a) 4 spaces + '---help---'
  b) 7 spaces + '---help---'
  c) 8 spaces + '---help---'
  d) 1 space + 1 tab + '---help---'
  e) 1 tab + '---help---'    (correct indentation)
  f) 1 tab + 1 space + '---help---'
  g) 1 tab + 2 spaces + '---help---'

In order to convert all of them to 1 tab + 'help', I ran the
following commend:

  $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>remove ioremap_nocache and devm_ioremap_nocache</title>
<updated>2020-01-06T08:45:59+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2020-01-06T08:43:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4bdc0d676a643140bdf17dbf7eafedee3d496a3c'/>
<id>urn:sha1:4bdc0d676a643140bdf17dbf7eafedee3d496a3c</id>
<content type='text'>
ioremap has provided non-cached semantics by default since the Linux 2.6
days, so remove the additional ioremap_nocache interface.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
</feed>
