Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dario Binacchi" <dario.binacchi@amarulasolutions.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 03/15] arm64: dts: st: add CAN1 support on stm32mp25
Date: Mon, 18 May 2026 14:57:19 +0000	[thread overview]
Message-ID: <20260518145719.84B48C2BCB7@smtp.kernel.org> (raw)
In-Reply-To: <20260518143150.3138712-4-dario.binacchi@amarulasolutions.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `m_can1` device tree node is missing the `resets` property.
--

commit 9a45deb755da217a14f0986f9795adff2ebdf1f4
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>

arm64: dts: st: add CAN1 support on stm32mp25

This commit adds device tree support for the CAN1 controller on the stm32mp25
platform. It configures the necessary memory regions, interrupts, clocks,
access controllers, and power domains for the bosch,m_can compatible node.

> diff --git a/arch/arm64/boot/dts/st/stm32mp253.dtsi b/arch/arm64/boot/dts/st/stm32mp253.dtsi
> index eeceb086252bf..d5871203ccb01 100644
> --- a/arch/arm64/boot/dts/st/stm32mp253.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp253.dtsi
> @@ -43,6 +43,21 @@ &optee {
>  };
>  
>  &rifsc {
> +	m_can1: can@402d0000 {
> +		compatible = "bosch,m_can";
> +		reg = <0x402d0000 0x400>, <0x40310000 0xd50>;
> +		reg-names = "m_can", "message_ram";
> +		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-names = "int0", "int1";
> +		clocks = <&rcc CK_BUS_FDCAN>, <&rcc CK_KER_FDCAN>;
> +		clock-names = "hclk", "cclk";
> +		bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
> +		access-controllers = <&rifsc 56>;
> +		power-domains = <&CLUSTER_PD>;

Should this node include the resets property?

The STM32MP25 RCC bindings define a dedicated hardware reset line for the
FDCAN block. While the generic bosch,m_can driver can fall back to a
software reset when the resets property is omitted, the STM32MP architecture
relies on the hardware reset to guarantee a pristine state.

Could omitting the resets property prevent the driver from acquiring the
hardware reset line and lead to unpredictable initialization failures if
the hardware is left in a fault state after bootloader execution, kexec,
or a warm reboot?

> +		status = "disabled";
> +	};

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518143150.3138712-1-dario.binacchi@amarulasolutions.com?part=3

  reply	other threads:[~2026-05-18 14:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 14:31 [PATCH 00/15] arm64: support Engicam MicroGEA-STM32MP257-RMM board Dario Binacchi
2026-05-18 14:31 ` [PATCH 01/15] dt-bindings: arm: stm32: " Dario Binacchi
2026-05-18 16:44   ` Conor Dooley
2026-05-18 14:31 ` [PATCH 02/15] arm64: dts: st: add SDMMC2 support on stm32mp25 Dario Binacchi
2026-05-18 14:31 ` [PATCH 03/15] arm64: dts: st: add CAN1 " Dario Binacchi
2026-05-18 14:57   ` sashiko-bot [this message]
2026-05-18 14:31 ` [PATCH 04/15] arm64: dts: st: add i2c1 pins for stm32mp25 Dario Binacchi
2026-05-18 14:31 ` [PATCH 05/15] arm64: dts: st: add ltdc " Dario Binacchi
2026-05-18 14:31 ` [PATCH 06/15] arm64: dts: st: add can1 " Dario Binacchi
2026-05-18 14:31 ` [PATCH 07/15] arm64: dts: st: add pwm2/pwm4 " Dario Binacchi
2026-05-18 14:31 ` [PATCH 08/15] arm64: dts: st: add sai1 " Dario Binacchi
2026-05-18 14:31 ` [PATCH 09/15] arm64: dts: st: add sdmmc2 " Dario Binacchi
2026-05-18 14:31 ` [PATCH 10/15] arm64: dts: st: add spi1 " Dario Binacchi
2026-05-18 14:31 ` [PATCH 11/15] arm64: dts: st: add usart1 " Dario Binacchi
2026-05-18 14:31 ` [PATCH 12/15] arm64: dts: st: support Engicam MicroGEA-STM32MP257 SoM Dario Binacchi
2026-05-18 14:31 ` [PATCH 13/15] arm64: dts: st: support Engicam MicroGEA-STM32MP257-RMM board Dario Binacchi
2026-05-18 15:07   ` 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=20260518145719.84B48C2BCB7@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dario.binacchi@amarulasolutions.com \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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