<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/net/can, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/net/can?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/net/can?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-11-07T13:00:27Z</updated>
<entry>
<title>can: rcar_canfd: Add missing ECC error checks for channels 2-7</title>
<updated>2022-11-07T13:00:27Z</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2022-10-28T10:06:45Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8b043dfb3dc7c32f9c2c0c93e3c2de346ee5e358'/>
<id>urn:sha1:8b043dfb3dc7c32f9c2c0c93e3c2de346ee5e358</id>
<content type='text'>
When introducing support for R-Car V3U, which has 8 instead of 2
channels, the ECC error bitmask was extended to take into account the
extra channels, but rcar_canfd_global_error() was not updated to act
upon the extra bits.

Replace the RCANFD_GERFL_EEF[01] macros by a new macro that takes the
channel number, fixing R-Car V3U while simplifying the code.

Fixes: 45721c406dcf50d4 ("can: rcar_canfd: Add support for r8a779a0 SoC")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Link: https://lore.kernel.org/all/4edb2ea46cc64d0532a08a924179827481e14b4f.1666951503.git.geert+renesas@glider.be
Cc: stable@vger.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: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://git.zx2c4.com/linux-dev/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: rcar_canfd: fix channel specific IRQ handling for RZ/G2L</title>
<updated>2022-10-27T07:30:59Z</updated>
<author>
<name>Biju Das</name>
<email>biju.das.jz@bp.renesas.com</email>
</author>
<published>2022-10-25T15:56:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d887087c896881715c1a82f1d4f71fbfe5344ffd'/>
<id>urn:sha1:d887087c896881715c1a82f1d4f71fbfe5344ffd</id>
<content type='text'>
RZ/G2L has separate channel specific IRQs for transmit and error
interrupts. But the IRQ handler processes both channels, even if there
no interrupt occurred on one of the channels.

This patch fixes the issue by passing a channel specific context
parameter instead of global one for the IRQ register and the IRQ
handler, it just handles the channel which is triggered the interrupt.

Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family")
Signed-off-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Link: https://lore.kernel.org/all/20221025155657.1426948-3-biju.das.jz@bp.renesas.com
Cc: stable@vger.kernel.org
[mkl: adjust commit message]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: rcar_canfd: rcar_canfd_handle_global_receive(): fix IRQ storm on global FIFO receive</title>
<updated>2022-10-27T07:27:09Z</updated>
<author>
<name>Biju Das</name>
<email>biju.das.jz@bp.renesas.com</email>
</author>
<published>2022-10-25T15:56:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=702de2c21eed04c67cefaaedc248ef16e5f6b293'/>
<id>urn:sha1:702de2c21eed04c67cefaaedc248ef16e5f6b293</id>
<content type='text'>
We are seeing an IRQ storm on the global receive IRQ line under heavy
CAN bus load conditions with both CAN channels enabled.

Conditions:

The global receive IRQ line is shared between can0 and can1, either of
the channels can trigger interrupt while the other channel's IRQ line
is disabled (RFIE).

When global a receive IRQ interrupt occurs, we mask the interrupt in
the IRQ handler. Clearing and unmasking of the interrupt is happening
in rx_poll(). There is a race condition where rx_poll() unmasks the
interrupt, but the next IRQ handler does not mask the IRQ due to
NAPIF_STATE_MISSED flag (e.g.: can0 RX FIFO interrupt is disabled and
can1 is triggering RX interrupt, the delay in rx_poll() processing
results in setting NAPIF_STATE_MISSED flag) leading to an IRQ storm.

This patch fixes the issue by checking IRQ active and enabled before
handling the IRQ on a particular channel.

Fixes: dd3bd23eb438 ("can: rcar_canfd: Add Renesas R-Car CAN FD driver")
Suggested-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Link: https://lore.kernel.org/all/20221025155657.1426948-2-biju.das.jz@bp.renesas.com
Cc: stable@vger.kernel.org
[mkl: adjust commit message]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: kvaser_usb: Fix possible completions during init_completion</title>
<updated>2022-10-27T07:00:39Z</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T18:52:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=2871edb32f4622c3a25ce4b3977bad9050b91974'/>
<id>urn:sha1:2871edb32f4622c3a25ce4b3977bad9050b91974</id>
<content type='text'>
kvaser_usb uses completions to signal when a response event is received
for outgoing commands.

However, it uses init_completion() to reinitialize the start_comp and
stop_comp completions before sending the start/stop commands.

In case the device sends the corresponding response just before the
actual command is sent, complete() may be called concurrently with
init_completion() which is not safe.

This might be triggerable even with a properly functioning device by
stopping the interface (CMD_STOP_CHIP) just after it goes bus-off (which
also causes the driver to send CMD_STOP_CHIP when restart-ms is off),
but that was not tested.

Fix the issue by using reinit_completion() instead.

Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Signed-off-by: Anssi Hannula &lt;anssi.hannula@bitwise.fi&gt;
Signed-off-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Link: https://lore.kernel.org/all/20221010185237.319219-2-extja@kvaser.com
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: mcp251x: mcp251x_can_probe(): add missing unregister_candev() in error path</title>
<updated>2022-10-25T07:13:14Z</updated>
<author>
<name>Dongliang Mu</name>
<email>dzm91@hust.edu.cn</email>
</author>
<published>2022-10-24T09:02:52Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=b1a09b63684cea56774786ca14c13b7041ffee63'/>
<id>urn:sha1:b1a09b63684cea56774786ca14c13b7041ffee63</id>
<content type='text'>
In mcp251x_can_probe(), if mcp251x_gpio_setup() fails, it forgets to
unregister the CAN device.

Fix this by unregistering can device in mcp251x_can_probe().

Fixes: 2d52dabbef60 ("can: mcp251x: add GPIO support")
Signed-off-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Link: https://lore.kernel.org/all/20221024090256.717236-1-dzm91@hust.edu.cn
[mkl: adjust label]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: mscan: mpc5xxx: mpc5xxx_can_probe(): add missing put_clock() in error path</title>
<updated>2022-10-25T07:13:14Z</updated>
<author>
<name>Dongliang Mu</name>
<email>dzm91@hust.edu.cn</email>
</author>
<published>2022-10-24T11:48:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3e5b3418827cefb5e1cc658806f02965791b8f07'/>
<id>urn:sha1:3e5b3418827cefb5e1cc658806f02965791b8f07</id>
<content type='text'>
The commit 1149108e2fbf ("can: mscan: improve clock API use") only
adds put_clock() in mpc5xxx_can_remove() function, forgetting to add
put_clock() in the error handling code.

Fix this bug by adding put_clock() in the error handling code.

Fixes: 1149108e2fbf ("can: mscan: improve clock API use")
Signed-off-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Link: https://lore.kernel.org/all/20221024133828.35881-1-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: kvaser_usb_leaf: Fix CAN state after restart</title>
<updated>2022-10-11T06:50:44Z</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T15:08:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0be1a655fe68c8e6dcadbcbddb69cf2fb29881f5'/>
<id>urn:sha1:0be1a655fe68c8e6dcadbcbddb69cf2fb29881f5</id>
<content type='text'>
can_restart() expects CMD_START_CHIP to set the error state to
ERROR_ACTIVE as it calls netif_carrier_on() immediately afterwards.

Otherwise the user may immediately trigger restart again and hit a
BUG_ON() in can_restart().

Fix kvaser_usb_leaf set_mode(CMD_START_CHIP) to set the expected state.

Cc: stable@vger.kernel.org
Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Signed-off-by: Anssi Hannula &lt;anssi.hannula@bitwise.fi&gt;
Signed-off-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Link: https://lore.kernel.org/all/20221010150829.199676-5-extja@kvaser.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: kvaser_usb_leaf: Fix TX queue out of sync after restart</title>
<updated>2022-10-11T06:50:44Z</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T15:08:28Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=455561fb618fde40558776b5b8435f9420f335db'/>
<id>urn:sha1:455561fb618fde40558776b5b8435f9420f335db</id>
<content type='text'>
The TX queue seems to be implicitly flushed by the hardware during
bus-off or bus-off recovery, but the driver does not reset the TX
bookkeeping.

Despite not resetting TX bookkeeping the driver still re-enables TX
queue unconditionally, leading to "cannot find free context" /
NETDEV_TX_BUSY errors if the TX queue was full at bus-off time.

Fix that by resetting TX bookkeeping on CAN restart.

Tested with 0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778.

Cc: stable@vger.kernel.org
Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Signed-off-by: Anssi Hannula &lt;anssi.hannula@bitwise.fi&gt;
Signed-off-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Link: https://lore.kernel.org/all/20221010150829.199676-4-extja@kvaser.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: kvaser_usb: Fix use of uninitialized completion</title>
<updated>2022-10-11T06:50:44Z</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T15:08:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=cd7f30e174d09a02ca2afa5ef093fb0f0352e0d8'/>
<id>urn:sha1:cd7f30e174d09a02ca2afa5ef093fb0f0352e0d8</id>
<content type='text'>
flush_comp is initialized when CMD_FLUSH_QUEUE is sent to the device and
completed when the device sends CMD_FLUSH_QUEUE_RESP.

This causes completion of uninitialized completion if the device sends
CMD_FLUSH_QUEUE_RESP before CMD_FLUSH_QUEUE is ever sent (e.g. as a
response to a flush by a previously bound driver, or a misbehaving
device).

Fix that by initializing flush_comp in kvaser_usb_init_one() like the
other completions.

This issue is only triggerable after RX URBs have been set up, i.e. the
interface has been opened at least once.

Cc: stable@vger.kernel.org
Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family")
Tested-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Signed-off-by: Anssi Hannula &lt;anssi.hannula@bitwise.fi&gt;
Signed-off-by: Jimmy Assarsson &lt;extja@kvaser.com&gt;
Link: https://lore.kernel.org/all/20221010150829.199676-3-extja@kvaser.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
