<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/can/dev.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>2021-01-13T08:42:58Z</updated>
<entry>
<title>can: dev: move driver related infrastructure into separate subdir</title>
<updated>2021-01-13T08:42:58Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2021-01-11T14:19:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3e77f70e734584e0ad1038e459ed3fd2400f873a'/>
<id>urn:sha1:3e77f70e734584e0ad1038e459ed3fd2400f873a</id>
<content type='text'>
This patch moves the CAN driver related infrastructure into a separate subdir.
It will be split into more files in the coming patches.

Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/20210111141930.693847-3-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: rename CAN FD related can_len2dlc and can_dlc2len helpers</title>
<updated>2020-11-20T11:05:14Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2020-11-10T10:18:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3ab4ce0d6fa8c93d41df4a74ec8d2c9198be2109'/>
<id>urn:sha1:3ab4ce0d6fa8c93d41df4a74ec8d2c9198be2109</id>
<content type='text'>
The helper functions can_len2dlc and can_dlc2len are only relevant for
CAN FD data length code (DLC) conversion.

To fit the introduced can_cc_dlc2len for Classical CAN we rename:

can_dlc2len -&gt; can_fd_dlc2len to get the payload length from the DLC
can_len2dlc -&gt; can_fd_len2dlc to get the DLC from the payload length

Suggested-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/r/20201110101852.1973-6-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: replace can_dlc as variable/element for payload length</title>
<updated>2020-11-20T11:04:12Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2020-11-20T10:04:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/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: dev: can_restart(): post buffer from the right context</title>
<updated>2020-11-15T17:24:35Z</updated>
<author>
<name>Alejandro Concepcion Rodriguez</name>
<email>alejandro@acoro.eu</email>
</author>
<published>2020-11-05T21:51:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a1e654070a60d5d4f7cce59c38f4ca790bb79121'/>
<id>urn:sha1:a1e654070a60d5d4f7cce59c38f4ca790bb79121</id>
<content type='text'>
netif_rx() is meant to be called from interrupt contexts. can_restart() may be
called by can_restart_work(), which is called from a worqueue, so it may run in
process context. Use netif_rx_ni() instead.

Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
Co-developed-by: Loris Fauster &lt;loris.fauster@ttcontrol.com&gt;
Signed-off-by: Loris Fauster &lt;loris.fauster@ttcontrol.com&gt;
Signed-off-by: Alejandro Concepcion Rodriguez &lt;alejandro@acoro.eu&gt;
Link: https://lore.kernel.org/r/4e84162b-fb31-3a73-fa9a-9438b4bd5234@acoro.eu
[mkl: use netif_rx_ni() instead of netif_rx_any_context()]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: __can_get_echo_skb(): fix real payload length return value for RTR frames</title>
<updated>2020-11-03T21:30:12Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2020-10-20T06:44:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ed3320cec279407a86bc4c72edc4a39eb49165ec'/>
<id>urn:sha1:ed3320cec279407a86bc4c72edc4a39eb49165ec</id>
<content type='text'>
The can_get_echo_skb() function returns the number of received bytes to
be used for netdev statistics. In the case of RTR frames we get a valid
(potential non-zero) data length value which has to be passed for further
operations. But on the wire RTR frames have no payload length. Therefore
the value to be used in the statistics has to be zero for RTR frames.

Reported-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/r/20201020064443.80164-1-socketcan@hartkopp.net
Fixes: cf5046b309b3 ("can: dev: let can_get_echo_skb() return dlc of CAN frame")
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context</title>
<updated>2020-11-03T21:24:19Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2020-10-02T15:41:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2283f79b22684d2812e5c76fc2280aae00390365'/>
<id>urn:sha1:2283f79b22684d2812e5c76fc2280aae00390365</id>
<content type='text'>
If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but
not always, the case), the 'WARN_ON(in_irq)' in
net/core/skbuff.c#skb_release_head_state() might be triggered, under network
congestion circumstances, together with the potential risk of a NULL pointer
dereference.

The root cause of this issue is the call to kfree_skb() instead of
dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().

This patch prevents the skb to be freed within the call to netif_rx() by
incrementing its reference count with skb_get(). The skb is finally freed by
one of the in-irq-context safe functions: dev_consume_skb_any() or
dev_kfree_skb_any(). The "any" version is used because some drivers might call
can_get_echo_skb() in a normal context.

The reason for this issue to occur is that initially, in the core network
stack, loopback skb were not supposed to be received in hardware IRQ context.
The CAN stack is an exeption.

This bug was previously reported back in 2017 in [1] but the proposed patch
never got accepted.

While [1] directly modifies net/core/dev.c, we try to propose here a
smoother modification local to CAN network stack (the assumption
behind is that only CAN devices are affected by this issue).

[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com

Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/20201002154219.4887-2-mailhol.vincent@wanadoo.fr
Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: add a helper function to calculate the duration of one bit</title>
<updated>2020-10-07T21:17:45Z</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2020-10-02T15:41:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1c47fa6b31c2683f03bc2f9174902bb7dcd35d83'/>
<id>urn:sha1:1c47fa6b31c2683f03bc2f9174902bb7dcd35d83</id>
<content type='text'>
Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available
through include/linux/can/dev.h

Add an helper function can_bit_time() which returns the duration (in
time quanta) of one CAN bit.

Rationale for this patch: the sync segment and the bit time are two
concepts which are defined in the CAN ISO standard. Device drivers for
CAN might need those.

Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
additional information.

Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/20201002154219.4887-6-mailhol.vincent@wanadoo.fr
[mkl: Let can_bit_time() return an unsinged int, make argument const]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: can_bus_off(): print scheduling of restart if activated</title>
<updated>2020-09-21T08:13:17Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2020-09-15T22:35:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0719631a61df4472439c4c00edd256a402d5f506'/>
<id>urn:sha1:0719631a61df4472439c4c00edd256a402d5f506</id>
<content type='text'>
If a CAN device goes into bus-off and has automatic restart enabled, inform
user that a automatic restart is scheduled after the configured delay.

Link: https://lore.kernel.org/r/20200915223527.1417033-14-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: can_change_state(): print human readable state change messages</title>
<updated>2020-09-21T08:13:17Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2020-09-15T22:35:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f81eb48b06fc619c10b47a1b0d5298f0f8bfa803'/>
<id>urn:sha1:f81eb48b06fc619c10b47a1b0d5298f0f8bfa803</id>
<content type='text'>
In order to ease debugging let can_change_state() print the human readable
state change messages. Also print the old and new state.

Link: https://lore.kernel.org/r/20200915223527.1417033-13-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: can_put_echo_skb(): propagate error in case of errors</title>
<updated>2020-09-21T08:13:16Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2020-09-15T22:35:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=80a71815d8cd1be6481ad16fad3167f095045a06'/>
<id>urn:sha1:80a71815d8cd1be6481ad16fad3167f095045a06</id>
<content type='text'>
The function can_put_echo_skb() can fail for several reasons. It may
fail due to OOM, but when it fails it's usually due to locking problems
in the driver.

In order to help developing and debugging of new drivers propagate error
value in case of errors.

Link: https://lore.kernel.org/r/20200915223527.1417033-12-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
