<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/can/usb/usb_8dev.c, branch linux-7.0.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.0.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.0.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-01-16T19:40:52+00:00</updated>
<entry>
<title>can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak</title>
<updated>2026-01-16T19:40:52+00:00</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2026-01-10T11:52:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f7a980b3b8f80fe367f679da376cf76e800f9480'/>
<id>urn:sha1:f7a980b3b8f80fe367f679da376cf76e800f9480</id>
<content type='text'>
Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory leak").

In usb_8dev_open() -&gt; usb_8dev_start(), the URBs for USB-in transfers are
allocated, added to the priv-&gt;rx_submitted anchor and submitted. In the
complete callback usb_8dev_read_bulk_callback(), the URBs are processed and
resubmitted. In usb_8dev_close() -&gt; unlink_all_urbs() the URBs are freed by
calling usb_kill_anchored_urbs(&amp;priv-&gt;rx_submitted).

However, this does not take into account that the USB framework unanchors
the URB before the complete function is called. This means that once an
in-URB has been completed, it is no longer anchored and is ultimately not
released in usb_kill_anchored_urbs().

Fix the memory leak by anchoring the URB in the
usb_8dev_read_bulk_callback() to the priv-&gt;rx_submitted anchor.

Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260116-can_usb-fix-memory-leak-v2-5-4b8cb2915571@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: treewide: remove can_change_mtu()</title>
<updated>2025-10-17T07:57:13+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol@kernel.org</email>
</author>
<published>2025-10-03T03:16:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f968a24cad3da72fdff12a0ae5ac0b679439cca1'/>
<id>urn:sha1:f968a24cad3da72fdff12a0ae5ac0b679439cca1</id>
<content type='text'>
can_change_mtu() became obsolete by commit 23049938605b ("can: populate the
minimum and maximum MTU values"). Now that net_device-&gt;min_mtu and
net_device-&gt;max_mtu are populated, all the checks are already done by
dev_validate_mtu() in net/core/dev.c.

Remove the net_device_ops-&gt;ndo_change_mtu() callback of all the physical
interfaces, then remove can_change_mtu(). Only keep the vcan_change_mtu()
and vxcan_change_mtu() because the virtual interfaces use their own
different MTU logic.

The only functional change this patch introduces is that now the user will
be able to change the MTU even if the interface is up. This does not matter
for Classical CAN and CAN FD because their MTU range is composed of only
one value, respectively CAN_MTU and CANFD_MTU. For the upcoming CAN XL, the
MTU will be configurable within the CANXL_MIN_MTU to CANXL_MAX_MTU range at
any time, even if the interface is up. This is consistent with the other
net protocols and does not contradict ISO 11898-1:2024 as having a
modifiable MTU is a kernel extension.

Signed-off-by: Vincent Mailhol &lt;mailhol@kernel.org&gt;
Link: https://patch.msgid.link/20251003-remove-can_change_mtu-v1-1-337f8bc21181@kernel.org
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: fix skb drop check</title>
<updated>2022-11-07T13:00:27+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-11-02T09:54:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:01+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-27T10:16:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:00+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-26T08:27:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:37+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-19T14:35:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:50+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2022-07-19T14:35:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:51+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-05-18T15:45:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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:27+00:00</updated>
<author>
<name>Hangyu Hua</name>
<email>hbh25y@gmail.com</email>
</author>
<published>2022-03-11T08:06:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/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: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>
</feed>
