[PATCH v3] arm64: dts: nuvoton: ma35d1: add CAN nodes

[PATCH v3] arm64: dts: nuvoton: ma35d1: add CAN nodes

[Zi-Yu Chen]

Add controller nodes for the four Bosch M_CAN blocks found on the
Nuvoton MA35D1 SoC.

Additionally, configure pinctrl and enable CAN1 and CAN3 on the
MA35D1 SOM board. Also, update the APLL frequency to 160MHz to ensure
the CAN controllers receive the required input clock for 80MHz operation.

Reviewed-by: Jacky Huang <ychuang3@nuvoton.com>
Signed-off-by: Zi-Yu Chen <zychennvt@gmail.com>
---
v3:
 - Change CAN clock to 80MHz and APLL to 160MHz to use a higher multiple
   of 40MHz, as suggested by Marc.
v2: 
 - Move assigned-clocks and assigned-clock-rates configurations of
   CAN_DIV from SoC-level ma35d1.dtsi to board-level ma35d1-som-256m.dts
 - Update APLL frequency to 200MHz to ensure the CAN controllers
   receive the required 50MHz input clock.

 .../boot/dts/nuvoton/ma35d1-som-256m.dts      | 32 +++++++++++-
 arch/arm64/boot/dts/nuvoton/ma35d1.dtsi       | 52 +++++++++++++++++++
 2 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
index f6f20a17e501..7bed0287e256 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
@@ -37,6 +37,22 @@ clk_hxt: clock-hxt {
 	};
 };
 
+&can1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can1>;
+	assigned-clocks = <&clk CAN1_DIV>;
+	assigned-clock-rates = <80000000>;
+	status = "okay";
+};
+
+&can3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can3>;
+	assigned-clocks = <&clk CAN3_DIV>;
+	assigned-clock-rates = <80000000>;
+	status = "okay";
+};
+
 &clk {
 	assigned-clocks = <&clk CAPLL>,
 			  <&clk DDRPLL>,
@@ -45,7 +61,7 @@ &clk {
 			  <&clk VPLL>;
 	assigned-clock-rates = <800000000>,
 			       <266000000>,
-			       <180000000>,
+			       <160000000>,
 			       <500000000>,
 			       <102000000>;
 	nuvoton,pll-mode = "integer",
@@ -56,6 +72,20 @@ &clk {
 };
 
 &pinctrl {
+	can-grp {
+		pinctrl_can1: can1-pins {
+			nuvoton,pins = <11 14 4>,
+				       <11 15 4>;
+			bias-disable;
+		};
+
+		pinctrl_can3: can3-pins {
+			nuvoton,pins = <11 10 3>,
+				       <11 11 3>;
+			bias-disable;
+		};
+	};
+
 	uart-grp {
 		pinctrl_uart0: uart0-pins {
 			nuvoton,pins = <4 14 1>,
diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
index e51b98f5bdce..494724a25f3b 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
@@ -244,6 +244,58 @@ gpion: gpio@340 {
 			};
 		};
 
+		can0: can@403c0000 {
+			compatible = "bosch,m_can";
+			reg = <0x0 0x403c0000 0x0 0x200>, <0x0 0x403c0200 0x0 0x2000>;
+			reg-names = "m_can", "message_ram";
+			interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "int0", "int1";
+			clocks = <&clk HCLK3>, <&clk CAN0_GATE>;
+			clock-names = "hclk", "cclk";
+			bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+			status = "disabled";
+		};
+
+		can1: can@403d0000 {
+			compatible = "bosch,m_can";
+			reg = <0x0 0x403d0000 0x0 0x200>, <0x0 0x403d0200 0x0 0x2000>;
+			reg-names = "m_can", "message_ram";
+			interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "int0", "int1";
+			clocks = <&clk HCLK3>, <&clk CAN1_GATE>;
+			clock-names = "hclk", "cclk";
+			bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+			status = "disabled";
+		};
+
+		can2: can@403e0000 {
+			compatible = "bosch,m_can";
+			reg = <0x0 0x403e0000 0x0 0x200>, <0x0 0x403e0200 0x0 0x2000>;
+			reg-names = "m_can", "message_ram";
+			interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "int0", "int1";
+			clocks = <&clk HCLK3>, <&clk CAN2_GATE>;
+			clock-names = "hclk", "cclk";
+			bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+			status = "disabled";
+		};
+
+		can3: can@403f0000 {
+			compatible = "bosch,m_can";
+			reg = <0x0 0x403f0000 0x0 0x200>, <0x0 0x403f0200 0x0 0x2000>;
+			reg-names = "m_can", "message_ram";
+			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "int0", "int1";
+			clocks = <&clk HCLK3>, <&clk CAN3_GATE>;
+			clock-names = "hclk", "cclk";
+			bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+			status = "disabled";
+		};
+
 		uart0: serial@40700000 {
 			compatible = "nuvoton,ma35d1-uart";
 			reg = <0x0 0x40700000 0x0 0x100>;
-- 
2.34.1

Re: [PATCH v3] arm64: dts: nuvoton: ma35d1: add CAN nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The CAN controller nodes omit the hardware `resets` property, despite the SoC providing dedicated CAN reset lines.
--

commit bc194563299d88a0e0b218c2bff6562e1d264119
Author: Zi-Yu Chen <zychennvt@gmail.com>

arm64: dts: nuvoton: ma35d1: add CAN nodes

This commit adds controller nodes for the four Bosch M_CAN blocks found
on the Nuvoton MA35D1 SoC. It also configures pinctrl, enables CAN1 and
CAN3 on the SOM board, and updates the APLL frequency.

> diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> index 7228ad4735b5c..91c0abc1678f2 100644
> --- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
[ ... ]
> @@ -244,6 +244,58 @@ gpion: gpio@340 {
>  			};
>  		};
>  
> +		can0: can@403c0000 {
> +			compatible = "bosch,m_can";
> +			reg = <0x0 0x403c0000 0x0 0x200>, <0x0 0x403c0200 0x0 0x2000>;
> +			reg-names = "m_can", "message_ram";
> +			interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "int0", "int1";
> +			clocks = <&clk HCLK3>, <&clk CAN0_GATE>;
> +			clock-names = "hclk", "cclk";
> +			bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
> +			status = "disabled";
> +		};

[Severity: Medium]
Should this node include the hardware resets property (e.g.,
resets = <&sys MA35D1_RESET_CANFD0>;)?

Without the hardware reset line, the bosch,m_can driver cannot perform a
hardware reset of the CAN controllers during probe or interface toggles.
It must rely solely on software initialization, which can fail to fully
recover the controller if the bootloader or a prior crashed state left
the hardware in an unpredictable state.

This omission pattern is identically repeated across the newly added can1,
can2, and can3 nodes below.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908014526.413399-1-zychennvt@gmail.com?part=1

Re: [PATCH v3] arm64: dts: nuvoton: ma35d1: add CAN nodes

[Jacky Huang]

> [ ... ]
>> @@ -244,6 +244,58 @@ gpion: gpio@340 {
>>                        };
>>                };
>>
>> +             can0: can@403c0000 {
>> +                     compatible = "bosch,m_can";
>> +                     reg = <0x0 0x403c0000 0x0 0x200>, <0x0 0x403c0200 0x0 0x2000>;
>> +                     reg-names = "m_can", "message_ram";
>> +                     interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
>> +                                  <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
>> +                     interrupt-names = "int0", "int1";
>> +                     clocks = <&clk HCLK3>, <&clk CAN0_GATE>;
>> +                     clock-names = "hclk", "cclk";
>> +                     bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
>> +                     status = "disabled";
>> +             };
> [Severity: Medium]
> Should this node include the hardware resets property (e.g.,
> resets = <&sys MA35D1_RESET_CANFD0>;)?
>
> Without the hardware reset line, the bosch,m_can driver cannot perform a
> hardware reset of the CAN controllers during probe or interface toggles.
> It must rely solely on software initialization, which can fail to fully
> recover the controller if the bootloader or a prior crashed state left
> the hardware in an unpredictable state.
>
> This omission pattern is identically repeated across the newly added can1,
> can2, and can3 nodes below.

The reset property is optional for the MA35D1 CAN nodes.

The bosch,m_can binding does not require a reset property, and the
m_can driver obtains the reset control through
devm_reset_control_get_optional_shared().

The MA35D1 CAN controllers also operate correctly without explicit
CAN reset properties in the existing platform DTS. Therefore, no
change is required for this patch.


> [ ... ]
>
> --
> Sashiko AI review · https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsashiko.dev%2F%23%2Fpatchset%2F20260908014526.413399-1-zychennvt%40gmail.com%3Fpart%3D1&data=05%7C02%7Cychuang3%40nuvoton.com%7C0f6b077d07ea424b0be208df0d4c30cd%7Ca3f24931d4034b4a94f17d83ac638e07%7C0%7C0%7C639244293026922482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mOpnaGY2o1KYf6Z5OXNovFUJbA6M5WauNCVif8Ihfn4%3D&reserved=0
>

Re: [PATCH v3] arm64: dts: nuvoton: ma35d1: add CAN nodes

[Jacky Huang]

Hi Zi-Yu,

I reviewed v3 of this patch, including the CAN controller addresses,
interrupts, clocks, Message RAM ranges, pinctrl settings, and the
board-level clock configuration.

Reviewed-by: Jacky Huang <ychuang3@nuvoton.com>

Best regards,
Jacky Huang

Re: [PATCH v3] arm64: dts: nuvoton: ma35d1: add CAN nodes

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

On 11.09.2026 10:15:21, Jacky Huang wrote:
> > [ ... ]
> > > @@ -244,6 +244,58 @@ gpion: gpio@340 {
> > >                        };
> > >                };
> > >
> > > +             can0: can@403c0000 {
> > > +                     compatible = "bosch,m_can";
> > > +                     reg = <0x0 0x403c0000 0x0 0x200>, <0x0 0x403c0200 0x0 0x2000>;
> > > +                     reg-names = "m_can", "message_ram";
> > > +                     interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> > > +                                  <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
> > > +                     interrupt-names = "int0", "int1";
> > > +                     clocks = <&clk HCLK3>, <&clk CAN0_GATE>;
> > > +                     clock-names = "hclk", "cclk";
> > > +                     bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
> > > +                     status = "disabled";
> > > +             };
> > [Severity: Medium]
> > Should this node include the hardware resets property (e.g.,
> > resets = <&sys MA35D1_RESET_CANFD0>;)?
> >
> > Without the hardware reset line, the bosch,m_can driver cannot perform a
> > hardware reset of the CAN controllers during probe or interface toggles.
> > It must rely solely on software initialization, which can fail to fully
> > recover the controller if the bootloader or a prior crashed state left
> > the hardware in an unpredictable state.
> >
> > This omission pattern is identically repeated across the newly added can1,
> > can2, and can3 nodes below.
>
> The reset property is optional for the MA35D1 CAN nodes.

yes, but....

> The bosch,m_can binding does not require a reset property, and the
> m_can driver obtains the reset control through
> devm_reset_control_get_optional_shared().
>
> The MA35D1 CAN controllers also operate correctly without explicit
> CAN reset properties in the existing platform DTS. Therefore, no
> change is required for this patch.

...we've observed that the SW reset doesn't clear the CAN state and
error counters, see commit 9271d0ea07c2 ("can: m_can: add support for
optional reset") for details. As your SoC has a reset line connected to
the M_CAN IP core, please add it to the dtsi.

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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3] arm64: dts: nuvoton: ma35d1: add CAN nodes

[Jacky Huang]

Marc Kleine-Budde 於 2026/9/11 下午 01:56 寫道:
> On 11.09.2026 10:15:21, Jacky Huang wrote:
>>> [ ... ]
>>>> @@ -244,6 +244,58 @@ gpion: gpio@340 {
>>>>                         };
>>>>                 };
>>>>
>>>> +             can0: can@403c0000 {
>>>> +                     compatible = "bosch,m_can";
>>>> +                     reg = <0x0 0x403c0000 0x0 0x200>, <0x0 0x403c0200 0x0 0x2000>;
>>>> +                     reg-names = "m_can", "message_ram";
>>>> +                     interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
>>>> +                                  <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
>>>> +                     interrupt-names = "int0", "int1";
>>>> +                     clocks = <&clk HCLK3>, <&clk CAN0_GATE>;
>>>> +                     clock-names = "hclk", "cclk";
>>>> +                     bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
>>>> +                     status = "disabled";
>>>> +             };
>>> [Severity: Medium]
>>> Should this node include the hardware resets property (e.g.,
>>> resets = <&sys MA35D1_RESET_CANFD0>;)?
>>>
>>> Without the hardware reset line, the bosch,m_can driver cannot perform a
>>> hardware reset of the CAN controllers during probe or interface toggles.
>>> It must rely solely on software initialization, which can fail to fully
>>> recover the controller if the bootloader or a prior crashed state left
>>> the hardware in an unpredictable state.
>>>
>>> This omission pattern is identically repeated across the newly added can1,
>>> can2, and can3 nodes below.
>> The reset property is optional for the MA35D1 CAN nodes.
> yes, but....
>
>> The bosch,m_can binding does not require a reset property, and the
>> m_can driver obtains the reset control through
>> devm_reset_control_get_optional_shared().
>>
>> The MA35D1 CAN controllers also operate correctly without explicit
>> CAN reset properties in the existing platform DTS. Therefore, no
>> change is required for this patch.
> ...we've observed that the SW reset doesn't clear the CAN state and
> error counters, see commit 9271d0ea07c2 ("can: m_can: add support for
> optional reset") for details. As your SoC has a reset line connected to
> the M_CAN IP core, please add it to the dtsi.
>
> regards,
> Marc
>

Hi Marc,

Thanks for pointing this out. I agree that the hardware reset properties 
should
be described for the MA35D1 CAN controllers.

Zi-Yu, please add the corresponding CANFD reset properties to can0 
through can3 in v4.

I will re-review the updated version.

Best regards,
Jacky Huang