<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/can, branch v5.15.78</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>can: rcar_canfd: rcar_canfd_handle_global_receive(): fix IRQ storm on global FIFO receive</title>
<updated>2022-11-03T14:59:20+00:00</updated>
<author>
<name>Biju Das</name>
<email>biju.das.jz@bp.renesas.com</email>
</author>
<published>2022-10-25T15:56:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0753069d4431e678565a545b53137d3977c8124c'/>
<id>0753069d4431e678565a545b53137d3977c8124c</id>
<content type='text'>
commit 702de2c21eed04c67cefaaedc248ef16e5f6b293 upstream.

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;
[biju: removed gpriv from RCANFD_RFCC_RFIE macro]
Signed-off-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 702de2c21eed04c67cefaaedc248ef16e5f6b293 upstream.

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;
[biju: removed gpriv from RCANFD_RFCC_RFIE macro]
Signed-off-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: rcar_canfd: fix channel specific IRQ handling for RZ/G2L</title>
<updated>2022-11-03T14:59:20+00:00</updated>
<author>
<name>Biju Das</name>
<email>biju.das.jz@bp.renesas.com</email>
</author>
<published>2022-10-25T15:56:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=17ff99e2240c6f35fd3981383fd9de991a266ff0'/>
<id>17ff99e2240c6f35fd3981383fd9de991a266ff0</id>
<content type='text'>
commit d887087c896881715c1a82f1d4f71fbfe5344ffd upstream.

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;
[biju: fixed the conflicts manually]
Signed-off-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d887087c896881715c1a82f1d4f71fbfe5344ffd upstream.

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;
[biju: fixed the conflicts manually]
Signed-off-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: mcp251x: mcp251x_can_probe(): add missing unregister_candev() in error path</title>
<updated>2022-11-03T14:59:17+00:00</updated>
<author>
<name>Dongliang Mu</name>
<email>dzm91@hust.edu.cn</email>
</author>
<published>2022-10-24T09:02:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3cc8c4088faecae6812423b6424ed32070179939'/>
<id>3cc8c4088faecae6812423b6424ed32070179939</id>
<content type='text'>
[ Upstream commit b1a09b63684cea56774786ca14c13b7041ffee63 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b1a09b63684cea56774786ca14c13b7041ffee63 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: mscan: mpc5xxx: mpc5xxx_can_probe(): add missing put_clock() in error path</title>
<updated>2022-11-03T14:59:17+00:00</updated>
<author>
<name>Dongliang Mu</name>
<email>dzm91@hust.edu.cn</email>
</author>
<published>2022-10-24T11:48:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a3e09eff32d8b73ac04cf9e798d823d12839c188'/>
<id>a3e09eff32d8b73ac04cf9e798d823d12839c188</id>
<content type='text'>
[ Upstream commit 3e5b3418827cefb5e1cc658806f02965791b8f07 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3e5b3418827cefb5e1cc658806f02965791b8f07 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: kvaser_usb: Fix possible completions during init_completion</title>
<updated>2022-11-03T14:59:10+00:00</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T18:52:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=33ddee2b95abecfb503639e1028b70df09f4cb23'/>
<id>33ddee2b95abecfb503639e1028b70df09f4cb23</id>
<content type='text'>
commit 2871edb32f4622c3a25ce4b3977bad9050b91974 upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2871edb32f4622c3a25ce4b3977bad9050b91974 upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: kvaser_usb_leaf: Fix CAN state after restart</title>
<updated>2022-10-26T10:34:20+00:00</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T15:08:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a4df91a88c3fb06663e7fa34a0bcf014df2ad19e'/>
<id>a4df91a88c3fb06663e7fa34a0bcf014df2ad19e</id>
<content type='text'>
commit 0be1a655fe68c8e6dcadbcbddb69cf2fb29881f5 upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0be1a655fe68c8e6dcadbcbddb69cf2fb29881f5 upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: kvaser_usb_leaf: Fix TX queue out of sync after restart</title>
<updated>2022-10-26T10:34:20+00:00</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T15:08:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0c28c2c0cfa2c0f7eb2f6d9237fa48357254cee5'/>
<id>0c28c2c0cfa2c0f7eb2f6d9237fa48357254cee5</id>
<content type='text'>
commit 455561fb618fde40558776b5b8435f9420f335db upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 455561fb618fde40558776b5b8435f9420f335db upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: kvaser_usb_leaf: Fix overread with an invalid command</title>
<updated>2022-10-26T10:34:20+00:00</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T15:08:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b8c4f6345e0edeaf97ebcecb85435c6499008f19'/>
<id>b8c4f6345e0edeaf97ebcecb85435c6499008f19</id>
<content type='text'>
commit 1499ecaea9d2ba68d5e18d80573b4561a8dc4ee7 upstream.

For command events read from the device,
kvaser_usb_leaf_read_bulk_callback() verifies that cmd-&gt;len does not
exceed the size of the received data, but the actual kvaser_cmd handlers
will happily read any kvaser_cmd fields without checking for cmd-&gt;len.

This can cause an overread if the last cmd in the buffer is shorter than
expected for the command type (with cmd-&gt;len showing the actual short
size).

Maximum overread seems to be 22 bytes (CMD_LEAF_LOG_MESSAGE), some of
which are delivered to userspace as-is.

Fix that by verifying the length of command before handling it.

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

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-2-extja@kvaser.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1499ecaea9d2ba68d5e18d80573b4561a8dc4ee7 upstream.

For command events read from the device,
kvaser_usb_leaf_read_bulk_callback() verifies that cmd-&gt;len does not
exceed the size of the received data, but the actual kvaser_cmd handlers
will happily read any kvaser_cmd fields without checking for cmd-&gt;len.

This can cause an overread if the last cmd in the buffer is shorter than
expected for the command type (with cmd-&gt;len showing the actual short
size).

Maximum overread seems to be 22 bytes (CMD_LEAF_LOG_MESSAGE), some of
which are delivered to userspace as-is.

Fix that by verifying the length of command before handling it.

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

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-2-extja@kvaser.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: kvaser_usb: Fix use of uninitialized completion</title>
<updated>2022-10-26T10:34:20+00:00</updated>
<author>
<name>Anssi Hannula</name>
<email>anssi.hannula@bitwise.fi</email>
</author>
<published>2022-10-10T15:08:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=de4434d6823c85c193f4cbf656449764ee6e0eeb'/>
<id>de4434d6823c85c193f4cbf656449764ee6e0eeb</id>
<content type='text'>
commit cd7f30e174d09a02ca2afa5ef093fb0f0352e0d8 upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cd7f30e174d09a02ca2afa5ef093fb0f0352e0d8 upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: c_can: don't cache TX messages for C_CAN cores</title>
<updated>2022-10-05T08:39:37+00:00</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2022-09-23T11:42:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d134b0f7a9b9e2b9a60beb6483585d08dbbbb37d'/>
<id>d134b0f7a9b9e2b9a60beb6483585d08dbbbb37d</id>
<content type='text'>
commit 81d192c2ce74157e717e1fc4b68791f82f7499d4 upstream.

As Jacob noticed, the optimization introduced in 387da6bc7a82 ("can:
c_can: cache frames to operate as a true FIFO") doesn't properly work
on C_CAN, but on D_CAN IP cores. The exact reasons are still unknown.

For now disable caching if CAN frames in the TX path for C_CAN cores.

Fixes: 387da6bc7a82 ("can: c_can: cache frames to operate as a true FIFO")
Link: https://lore.kernel.org/all/20220928083354.1062321-1-mkl@pengutronix.de
Link: https://lore.kernel.org/all/15a8084b-9617-2da1-6704-d7e39d60643b@gmail.com
Reported-by: Jacob Kroon &lt;jacob.kroon@gmail.com&gt;
Tested-by: Jacob Kroon &lt;jacob.kroon@gmail.com&gt;
Cc: stable@vger.kernel.org # v5.15
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 81d192c2ce74157e717e1fc4b68791f82f7499d4 upstream.

As Jacob noticed, the optimization introduced in 387da6bc7a82 ("can:
c_can: cache frames to operate as a true FIFO") doesn't properly work
on C_CAN, but on D_CAN IP cores. The exact reasons are still unknown.

For now disable caching if CAN frames in the TX path for C_CAN cores.

Fixes: 387da6bc7a82 ("can: c_can: cache frames to operate as a true FIFO")
Link: https://lore.kernel.org/all/20220928083354.1062321-1-mkl@pengutronix.de
Link: https://lore.kernel.org/all/15a8084b-9617-2da1-6704-d7e39d60643b@gmail.com
Reported-by: Jacob Kroon &lt;jacob.kroon@gmail.com&gt;
Tested-by: Jacob Kroon &lt;jacob.kroon@gmail.com&gt;
Cc: stable@vger.kernel.org # v5.15
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
