From: sashiko-bot@kernel.org
To: "Marc Kleine-Budde" <mkl@pengutronix.de>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Vincent Mailhol" <mailhol@kernel.org>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
linux-can@vger.kernel.org
Subject: Re: [PATCH net 17/20] can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured
Date: Thu, 30 Jul 2026 10:30:00 +0000 [thread overview]
Message-ID: <20260730103000.A55EC1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260729102802.505168-18-mkl@pengutronix.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] c_can_set_bittiming() inadvertently resets C_CAN_TEST_REG, breaking loopback and listen-only modes.
--
--- Patch [17]: [PATCH net 17/20] can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured ---
commit 43c179b24ec630378edf5e7aee260bd073975b00
Author: Lucas Martins Alves <lucas.alves@lumal21.com.br>
can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured
c_can_chip_config() was programming C_CAN_CTRL_REG without CONTROL_INIT,
which may allow the controller to become active before
c_can_set_bittiming() finishes.
Link: https://patch.msgid.link/20260714164839.771123-1-lucas.alves@lumal21.com.br
> diff --git a/drivers/net/can/c_can/c_can_main.c b/drivers/net/can/c_can/c_can_main.c
> index 3702cac7fbf0f..b3b321d9ce68d 100644
> --- a/drivers/net/can/c_can/c_can_main.c
> +++ b/drivers/net/can/c_can/c_can_main.c
> @@ -597,20 +597,20 @@ static int c_can_chip_config(struct net_device *dev)
> return err;
>
> /* enable automatic retransmission */
> - priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_ENABLE_AR);
> + priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_ENABLE_AR | CONTROL_INIT);
>
> if ((priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY) &&
> (priv->can.ctrlmode & CAN_CTRLMODE_LOOPBACK)) {
> /* loopback + silent mode : useful for hot self-test */
> - priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_TEST);
> + priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_TEST | CONTROL_INIT);
> priv->write_reg(priv, C_CAN_TEST_REG, TEST_LBACK | TEST_SILENT);
> } else if (priv->can.ctrlmode & CAN_CTRLMODE_LOOPBACK) {
> /* loopback mode : useful for self-test function */
> - priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_TEST);
> + priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_TEST | CONTROL_INIT);
> priv->write_reg(priv, C_CAN_TEST_REG, TEST_LBACK);
> } else if (priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY) {
> /* silent mode : bus-monitoring mode */
> - priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_TEST);
> + priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_TEST | CONTROL_INIT);
> priv->write_reg(priv, C_CAN_TEST_REG, TEST_SILENT);
> }
>
[Severity: High]
This isn't a bug introduced by this patch, but doesn't the subsequent call to
c_can_set_bittiming() at the end of c_can_chip_config() unconditionally clear
the CONTROL_TEST bit?
c_can_set_bittiming() executes this:
priv->write_reg(priv, C_CAN_CTRL_REG, CONTROL_CCE | CONTROL_INIT);
Because this write does not include CONTROL_TEST, it gets cleared. According to
the Bosch C_CAN hardware manual, clearing the Test bit instantly resets the
Test Register to its default value (0x00).
Does this silently erase the loopback and listen-only modes configured here,
causing the controller to incorrectly operate in normal mode and potentially
cause active disruption on a live CAN bus?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729102802.505168-1-mkl@pengutronix.de?part=17
next prev parent reply other threads:[~2026-07-30 10:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 10:12 [PATCH net 0/20] pull-request: can 2026-07-29 Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 01/20] can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-30 13:20 ` patchwork-bot+netdevbpf
2026-07-29 10:12 ` [PATCH net 02/20] can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 03/20] can: isotp: fix timer drain order, wakeup handling and tx_gen ordering Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-30 12:28 ` Oliver Hartkopp
2026-07-29 10:12 ` [PATCH net 04/20] can: isotp: check register_netdevice_notifier() error in module init Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 05/20] can: ctucanfd: unmap BAR0 using base address Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 06/20] can: ctucanfd: mark error-active controller status valid Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-30 11:14 ` Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 07/20] can: ctucanfd: handle bus error interrupts Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-30 11:18 ` Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 08/20] can: ctucanfd: use self-test mode for PRESUME_ACK Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-30 11:25 ` Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 09/20] can: ctucanfd: add missing MODULE_DEVICE_TABLE() Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 10/20] can: peak_usb: add bounds check for USB channel index Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-29 10:12 ` [PATCH net 11/20] can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-29 10:12 ` [PATCH net 12/20] can: peak_usb: validate uCAN receive record lengths Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-29 10:12 ` [PATCH net 13/20] can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in kvaser_usb_hydra_get_busparams() Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 14/20] can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-29 10:12 ` [PATCH net 15/20] can: rcar_canfd: change the initializing flow for clocks and resets Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-29 10:12 ` [PATCH net 16/20] can: softing: fw_parse(): validate firmware record spans Marc Kleine-Budde
2026-07-30 10:29 ` sashiko-bot
2026-07-29 10:12 ` [PATCH net 17/20] can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured Marc Kleine-Budde
2026-07-30 10:30 ` sashiko-bot [this message]
2026-07-29 10:12 ` [PATCH net 18/20] can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb allocation failure Marc Kleine-Budde
2026-07-29 10:12 ` [PATCH net 19/20] can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure Marc Kleine-Budde
2026-07-29 10:13 ` [PATCH net 20/20] can: ems_usb: validate CPC message lengths Marc Kleine-Budde
2026-07-30 10:30 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260730103000.A55EC1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=o.rempel@pengutronix.de \
--cc=sashiko-reviews@lists.linux.dev \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox