<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/can/m_can, branch linux-6.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.1.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.1.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-10-29T13:04:33Z</updated>
<entry>
<title>can: m_can: m_can_plat_remove(): add missing pm_runtime_disable()</title>
<updated>2025-10-29T13:04:33Z</updated>
<author>
<name>Marc Kleine-Budde</name>
</author>
<published>2025-08-06T15:46:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ccc9e794e8cfc9fea271b61c810c6236a8916d61'/>
<id>urn:sha1:ccc9e794e8cfc9fea271b61c810c6236a8916d61</id>
<content type='text'>
[ Upstream commit ba569fb07a7e9e9b71e9282e27e993ba859295c2 ]

Commit 227619c3ff7c ("can: m_can: move runtime PM enable/disable to
m_can_platform") moved the PM runtime enable from the m_can core
driver into the m_can_platform.

That patch forgot to move the pm_runtime_disable() to
m_can_plat_remove(), so that unloading the m_can_platform driver
causes an "Unbalanced pm_runtime_enable!" error message.

Add the missing pm_runtime_disable() to m_can_plat_remove() to fix the
problem.

Cc: Patrik Flykt &lt;patrik.flykt@linux.intel.com&gt;
Fixes: 227619c3ff7c ("can: m_can: move runtime PM enable/disable to m_can_platform")
Reviewed-by: Markus Schneider-Pargmann &lt;msp@baylibre.com&gt;
Link: https://patch.msgid.link/20250929-m_can-fix-state-handling-v4-1-682b49b49d9a@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: m_can: m_can_handle_lost_msg(): downgrade msg lost in rx message to debug level</title>
<updated>2025-07-17T16:32:13Z</updated>
<author>
<name>Sean Nyekjaer</name>
</author>
<published>2025-07-11T10:12:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3808d2849367a7d692da57ce4bd85da599edbd1d'/>
<id>urn:sha1:3808d2849367a7d692da57ce4bd85da599edbd1d</id>
<content type='text'>
[ Upstream commit 58805e9cbc6f6a28f35d90e740956e983a0e036e ]

Downgrade the "msg lost in rx" message to debug level, to prevent
flooding the kernel log with error messages.

Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Sean Nyekjaer &lt;sean@geanix.com&gt;
Link: https://patch.msgid.link/20250711-mcan_ratelimit-v3-1-7413e8e21b84@geanix.com
[mkl: enhance commit message]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: tcan4x5x: fix power regulator retrieval during probe</title>
<updated>2025-06-27T10:07:28Z</updated>
<author>
<name>Brett Werling</name>
</author>
<published>2025-06-12T19:18:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6cb91b73c5a0cece474e0adf985cc85327a48553'/>
<id>urn:sha1:6cb91b73c5a0cece474e0adf985cc85327a48553</id>
<content type='text'>
commit db22720545207f734aaa9d9f71637bfc8b0155e0 upstream.

Fixes the power regulator retrieval in tcan4x5x_can_probe() by ensuring
the regulator pointer is not set to NULL in the successful return from
devm_regulator_get_optional().

Fixes: 3814ca3a10be ("can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the config")
Signed-off-by: Brett Werling &lt;brett.werling@garmin.com&gt;
Link: https://patch.msgid.link/20250612191825.3646364-1-brett.werling@garmin.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>
</entry>
<entry>
<title>can: mcan: m_can_class_unregister(): fix order of unregistration calls</title>
<updated>2025-05-18T06:21:20Z</updated>
<author>
<name>Marc Kleine-Budde</name>
</author>
<published>2025-05-02T14:13:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0de5d055d4a881a23e3a4b20ceab5ffd7d202509'/>
<id>urn:sha1:0de5d055d4a881a23e3a4b20ceab5ffd7d202509</id>
<content type='text'>
commit 0713a1b3276b98c7dafbeefef00d7bc3a9119a84 upstream.

If a driver is removed, the driver framework invokes the driver's
remove callback. A CAN driver's remove function calls
unregister_candev(), which calls net_device_ops::ndo_stop further down
in the call stack for interfaces which are in the "up" state.

The removal of the module causes a warning, as can_rx_offload_del()
deletes the NAPI, while it is still active, because the interface is
still up.

To fix the warning, first unregister the network interface, which
calls net_device_ops::ndo_stop, which disables the NAPI, and then call
can_rx_offload_del().

Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-3-59a9b131589d@pengutronix.de
Reviewed-by: Markus Schneider-Pargmann &lt;msp@baylibre.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>can: m_can: m_can_handle_lec_err(): fix {rx,tx}_errors statistics</title>
<updated>2024-12-14T18:54:19Z</updated>
<author>
<name>Dario Binacchi</name>
</author>
<published>2024-11-22T22:15:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0691005ad74d6842319dbbacb454b1368da51ece'/>
<id>urn:sha1:0691005ad74d6842319dbbacb454b1368da51ece</id>
<content type='text'>
[ Upstream commit 988d4222bf9039a875a3d48f2fe35c317831ff68 ]

The m_can_handle_lec_err() function was incorrectly incrementing only the
receive error counter, even in cases of bit or acknowledgment errors that
occur during transmission.

Fix the issue by incrementing the appropriate counter based on the
type of error.

Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
Signed-off-by: Dario Binacchi &lt;dario.binacchi@amarulasolutions.com&gt;
Link: https://patch.msgid.link/20241122221650.633981-7-dario.binacchi@amarulasolutions.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: m_can: m_can_close(): stop clocks after device has been shut down</title>
<updated>2024-10-17T13:20:43Z</updated>
<author>
<name>Marc Kleine-Budde</name>
</author>
<published>2024-09-09T13:07:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=63969cc95b67756ab999fc78fd140c3078124b90'/>
<id>urn:sha1:63969cc95b67756ab999fc78fd140c3078124b90</id>
<content type='text'>
[ Upstream commit 2c09b50efcad985cf920ca88baa9aa52b1999dcc ]

After calling m_can_stop() an interrupt may be pending or NAPI might
still be executed. This means the driver might still touch registers
of the IP core after the clocks have been disabled. This is not good
practice and might lead to aborts depending on the SoC integration.

To avoid these potential problems, make m_can_close() symmetric to
m_can_open(), i.e. stop the clocks at the end, right before shutting
down the transceiver.

Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
Link: https://patch.msgid.link/20240910-can-m_can-fix-ifup-v3-2-6c1720ba45ce@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: m_can: enable NAPI before enabling interrupts</title>
<updated>2024-10-17T13:20:43Z</updated>
<author>
<name>Jake Hamby</name>
</author>
<published>2024-09-06T23:19:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e5520e9568bec01a530c2e59282d22f37dd87010'/>
<id>urn:sha1:e5520e9568bec01a530c2e59282d22f37dd87010</id>
<content type='text'>
[ Upstream commit 801ad2f87b0c6d0c34a75a4efd6bfd3a2d9f9298 ]

If an interrupt (RX-complete or error flag) is set when bringing up
the CAN device, e.g. due to CAN bus traffic before initializing the
device, when m_can_start() is called and interrupts are enabled,
m_can_isr() is called immediately, which disables all CAN interrupts
and calls napi_schedule().

Because napi_enable() isn't called until later in m_can_open(), the
call to napi_schedule() never schedules the m_can_poll() callback and
the device is left with interrupts disabled and can't receive any CAN
packets until rebooted.

This can be verified by running "cansend" from another device before
setting the bitrate and calling "ip link set up can0" on the test
device. Adding debug lines to m_can_isr() shows it's called with flags
(IR_EP | IR_EW | IR_CRCE), which calls m_can_disable_all_interrupts()
and napi_schedule(), and then m_can_poll() is never called.

Move the call to napi_enable() above the call to m_can_start() to
enable any initial interrupt flags to be handled by m_can_poll() so
that interrupts are reenabled. Add a call to napi_disable() in the
error handling section of m_can_open(), to handle the case where later
functions return errors.

Also, in m_can_close(), move the call to napi_disable() below the call
to m_can_stop() to ensure all interrupts are handled when bringing
down the device. This race condition is much less likely to occur.

Tested on a Microchip SAMA7G54 MPU. The fix should be applicable to
any SoC with a Bosch M_CAN controller.

Signed-off-by: Jake Hamby &lt;Jake.Hamby@Teledyne.com&gt;
Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
Link: https://patch.msgid.link/20240910-can-m_can-fix-ifup-v3-1-6c1720ba45ce@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: m_can: Remove repeated check for is_peripheral</title>
<updated>2024-10-17T13:20:42Z</updated>
<author>
<name>Markus Schneider-Pargmann</name>
</author>
<published>2023-03-15T11:05:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=93a3de94321f632e62063c86a2183d4bf58e428f'/>
<id>urn:sha1:93a3de94321f632e62063c86a2183d4bf58e428f</id>
<content type='text'>
[ Upstream commit 73042934e4a30d9f45ff9cb0b3b029a01dbe7130 ]

Merge both if-blocks to fix this.

Signed-off-by: Markus Schneider-Pargmann &lt;msp@baylibre.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Link: https://lore.kernel.org/all/20230315110546.2518305-2-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Stable-dep-of: 801ad2f87b0c ("can: m_can: enable NAPI before enabling interrupts")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: m_can: Release irq on error in m_can_open</title>
<updated>2024-09-12T09:10:21Z</updated>
<author>
<name>Simon Horman</name>
</author>
<published>2024-08-05T14:01:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=add5c9c820c8412be1845be86e79f19296a298a1'/>
<id>urn:sha1:add5c9c820c8412be1845be86e79f19296a298a1</id>
<content type='text'>
[ Upstream commit 06d4ef3056a7ac31be331281bb7a6302ef5a7f8a ]

It appears that the irq requested in m_can_open() may be leaked
if an error subsequently occurs: if m_can_start() fails.

Address this by calling free_irq in the unwind path for
such cases.

Flagged by Smatch.
Compile tested only.

Fixes: eaacfeaca7ad ("can: m_can: Call the RAM init directly from m_can_chip_config")
Acked-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://lore.kernel.org/all/20240805-mcan-irq-v2-1-7154c0484819@kernel.org
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>can: tcan4x5x: Fix use of register error status mask</title>
<updated>2022-12-31T12:32:27Z</updated>
<author>
<name>Markus Schneider-Pargmann</name>
</author>
<published>2022-12-06T11:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=512dc6796946acd6e49981febf394c87648cb3f9'/>
<id>urn:sha1:512dc6796946acd6e49981febf394c87648cb3f9</id>
<content type='text'>
[ Upstream commit 67727a17a6b375d68fe569b77e6516b034b834c0 ]

TCAN4X5X_ERROR_STATUS is not a status register that needs clearing
during interrupt handling. Instead this is a masking register that masks
error interrupts. Writing TCAN4X5X_CLEAR_ALL_INT to this register
effectively masks everything.

Rename the register and mask all error interrupts only once by writing
to the register in tcan4x5x_init.

Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Signed-off-by: Markus Schneider-Pargmann &lt;msp@baylibre.com&gt;
Link: https://lore.kernel.org/all/20221206115728.1056014-10-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
