linux-kernel - Re: [PATCH 4/7] can: m_can: m_can_chip_config(): bring up interface in correct state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DC74S0QJQ0JV.39VRZ1Y5JSEWS@baylibre.com>
Date: Wed, 20 Aug 2025 11:00:51 +0200
From: "Markus Schneider-Pargmann" <msp@...libre.com>
To: "Marc Kleine-Budde" <mkl@...gutronix.de>, "Chandrasekar Ramakrishnan"
 <rcsekar@...sung.com>, "Vincent Mailhol" <mailhol.vincent@...adoo.fr>,
 "Patrik Flykt" <patrik.flykt@...ux.intel.com>, "Dong Aisheng"
 <b29396@...escale.com>, "Fengguang Wu" <fengguang.wu@...el.com>, "Varka
 Bhadram" <varkabhadram@...il.com>, "Wu Bo" <wubo.oduw@...il.com>, "Philipp
 Zabel" <p.zabel@...gutronix.de>
Cc: <linux-can@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <kernel@...gutronix.de>
Subject: Re: [PATCH 4/7] can: m_can: m_can_chip_config(): bring up interface
 in correct state

Hi,

On Tue Aug 12, 2025 at 7:36 PM CEST, Marc Kleine-Budde wrote:
> In some SoCs (observed on the STM32MP15) the M_CAN IP core keeps the
> CAN state and CAN error counters over an internal reset cycle. An
> external reset is not always possible, due to the shared reset with
> the other CAN core. This caused the core not always be in Error Active
> state when bringing up the controller.
>
> Instead of always setting the CAN state to Error Active in
> m_can_chip_config(), fix this by reading and decoding the Protocol
> Status Regitser (PSR) and set the CAN state accordingly.
>
> Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
> Signed-off-by: Marc Kleine-Budde <mkl@...gutronix.de>
> ---
>  drivers/net/can/m_can/m_can.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index b485d2f3d971..310a907cbb7e 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -1607,6 +1607,7 @@ static int m_can_chip_config(struct net_device *dev)
>  static int m_can_start(struct net_device *dev)
>  {
>  	struct m_can_classdev *cdev = netdev_priv(dev);
> +	u32 reg_psr;
>  	int ret;
>  
>  	/* basic m_can configuration */
> @@ -1617,7 +1618,8 @@ static int m_can_start(struct net_device *dev)
>  	netdev_queue_set_dql_min_limit(netdev_get_tx_queue(cdev->net, 0),
>  				       cdev->tx_max_coalesced_frames);
>  
> -	cdev->can.state = CAN_STATE_ERROR_ACTIVE;
> +	reg_psr = m_can_read(cdev, M_CAN_PSR);
> +	cdev->can.state = m_can_can_state_get_by_psr(reg_psr);

Previous patch makes sense for use here. But how is the state set back
in operation after mcan was in an error state? Maybe I missed the path
back to CAN_STATE_ERROR_ACTIVE somewhere?

Also CAN_STATE_ERROR_ACTIVE is set in resume() as well, should that also
read the PSR instead?

Ans lastly I don't like the function name, because of the repeated can,
maybe something like m_can_error_state_by_psr()?

Best
Markus

Download attachment "signature.asc" of type "application/pgp-signature" (290 bytes)