linux-kernel - Re: [PATCH v2 2/2] ARM: dts: stm32: add resets property to m

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250903-uncovered-magnetic-marmot-dd7c37-mkl@pengutronix.de>
Date: Wed, 3 Sep 2025 17:16:48 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Alexandre TORGUE <alexandre.torgue@...s.st.com>
Cc: Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Maxime Coquelin <mcoquelin.stm32@...il.com>, Chandrasekar Ramakrishnan <rcsekar@...sung.com>, 
	Vincent Mailhol <mailhol.vincent@...adoo.fr>, devicetree@...r.kernel.org, 
	linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, kernel@...gutronix.de, linux-can@...r.kernel.org
Subject: Re: [PATCH v2 2/2] ARM: dts: stm32: add resets property to m_can
 nodes in the stm32mp153

On 03.09.2025 15:10:42, Alexandre TORGUE wrote:
> Hi Marc
> 
> On 8/7/25 08:09, Marc Kleine-Budde wrote:
> > On the STM32MP153 the m_cam IP cores (a.k.a. FDCAN) have an external
> > shared reset in the RCC. Add the reset to both m_can nodes.
> > 
> > Signed-off-by: Marc Kleine-Budde <mkl@...gutronix.de>
> > ---
> >   arch/arm/boot/dts/st/stm32mp153.dtsi | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/st/stm32mp153.dtsi b/arch/arm/boot/dts/st/stm32mp153.dtsi
> > index 4640dafb1598..92794b942ab2 100644
> > --- a/arch/arm/boot/dts/st/stm32mp153.dtsi
> > +++ b/arch/arm/boot/dts/st/stm32mp153.dtsi
> > @@ -40,6 +40,7 @@ m_can1: can@...0e000 {
> >   		interrupt-names = "int0", "int1";
> >   		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
> >   		clock-names = "hclk", "cclk";
> > +		resets = <&rcc FDCAN_R>;
> >   		bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
> >   		access-controllers = <&etzpc 62>;
> >   		status = "disabled";
> > @@ -54,6 +55,7 @@ m_can2: can@...0f000 {
> >   		interrupt-names = "int0", "int1";
> >   		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
> >   		clock-names = "hclk", "cclk";
> > +		resets = <&rcc FDCAN_R>;
> >   		bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
> >   		access-controllers = <&etzpc 62>;
> >   		status = "disabled";
> > 
> 
> How those reset are handled at driver side ?

I've created a patch that adds a shared reset to the m_can driver:

| https://lore.kernel.org/all/20250812-m_can-fix-state-handling-v1-7-b739e06c0a3b@pengutronix.de/

The reset is de-asserted during probe and when the interface does up,
otherwise it asserted. This way the IP gets reset only when both
interfaces are down.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

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