<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/can/usb/usb_8dev.c, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2022-11-07T13:00:27Z</updated>
<entry>
<title>can: dev: fix skb drop check</title>
<updated>2022-11-07T13:00:27Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-11-02T09:54:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ae64438be1923e3c1102d90fd41db7afcfaf54cc'/>
<id>urn:sha1:ae64438be1923e3c1102d90fd41db7afcfaf54cc</id>
<content type='text'>
In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only
mode") the priv-&gt;ctrlmode element is read even on virtual CAN
interfaces that do not create the struct can_priv at startup. This
out-of-bounds read may lead to CAN frame drops for virtual CAN
interfaces like vcan and vxcan.

This patch mainly reverts the original commit and adds a new helper
for CAN interface drivers that provide the required information in
struct can_priv.

Fixes: a6d190f8c767 ("can: skb: drop tx skb if in listen only mode")
Reported-by: Dariusz Stojaczyk &lt;Dariusz.Stojaczyk@opensynergy.com&gt;
Cc: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Cc: Max Staudt &lt;max@enpas.org&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Acked-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/all/20221102095431.36831-1-socketcan@hartkopp.net
Cc: stable@vger.kernel.org # 6.0.x
[mkl: patch pch_can, too]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: tree-wide: advertise software timestamping capabilities</title>
<updated>2022-07-28T09:44:01Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-27T10:16:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=409c188c57cdb5cb1dfcac79e72b5169f0463fe4'/>
<id>urn:sha1:409c188c57cdb5cb1dfcac79e72b5169f0463fe4</id>
<content type='text'>
Currently, some CAN drivers support hardware timestamping, some do
not. But userland has no method to query which features are supported
(aside maybe of getting RX messages and observe whether or not
hardware timestamps stay at zero).

The canonical way for a network driver to advertised what kind of
timestamping it supports is to implement ethtool_ops::get_ts_info().

This patch only targets the CAN drivers which *do not* support
hardware timestamping.  For each of those CAN drivers, implement the
get_ts_info() using the generic ethtool_op_get_ts_info().

This way, userland can do:

| $ ethtool --show-time-stamping canX

to confirm the device timestamping capacities.

N.B. the drivers which support hardware timestamping will be migrated
in separate patches.

Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/all/20220727101641.198847-6-mailhol.vincent@wanadoo.fr
[mkl: mscan: add missing mscan_ethtool_ops]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: ubs_8dev: use KBUILD_MODNAME instead of hard coded names</title>
<updated>2022-07-26T08:47:00Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-26T08:27:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6f2660607282df1c9b57aafb131c6e4432a3bf7a'/>
<id>urn:sha1:6f2660607282df1c9b57aafb131c6e4432a3bf7a</id>
<content type='text'>
The driver uses the string "usb_8dev" to populate usb_driver::name and
can_bittiming_const::name. KBUILD_MODNAME also evaluates to
"ubs_8dev". Use KBUILD_MODNAME and get rid on the hardcoded string
names.

Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/all/20220726082707.58758-9-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: add CAN_ERR_CNT flag to notify availability of error counter</title>
<updated>2022-07-20T07:27:37Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-19T14:35:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3e5c291c7942d0909a48bc5ec1b9bba136465166'/>
<id>urn:sha1:3e5c291c7942d0909a48bc5ec1b9bba136465166</id>
<content type='text'>
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 &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: usb_8dev: do not report txerr and rxerr during bus-off</title>
<updated>2022-07-20T07:26:50Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-19T14:35:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aebe8a2433cd090ccdc222861f44bddb75eb01de'/>
<id>urn:sha1:aebe8a2433cd090ccdc222861f44bddb75eb01de</id>
<content type='text'>
During bus off, the error count is greater than 255 and can not fit in
a u8.

Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices")
Link: https://lore.kernel.org/all/20220719143550.3681-10-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: 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://universe.0xinfinity.dev/distro/kernel/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: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path</title>
<updated>2022-03-31T07:55:27Z</updated>
<author>
<name>Hangyu Hua</name>
<email>hbh25y@gmail.com</email>
</author>
<published>2022-03-11T08:06:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3d3925ff6433f98992685a9679613a2cc97f3ce2'/>
<id>urn:sha1:3d3925ff6433f98992685a9679613a2cc97f3ce2</id>
<content type='text'>
There is no need to call dev_kfree_skb() when usb_submit_urb() fails
because can_put_echo_skb() deletes original skb and
can_free_echo_skb() deletes the cloned skb.

Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices")
Link: https://lore.kernel.org/all/20220311080614.45229-1-hbh25y@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Hangyu Hua &lt;hbh25y@gmail.com&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://universe.0xinfinity.dev/distro/kernel/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://universe.0xinfinity.dev/distro/kernel/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://universe.0xinfinity.dev/distro/kernel/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>
