Re: [EXT] Re: [PATCH v4 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts

["Joseph Guo (OSS)" <qijian.guo@oss.nxp.com>]

On 5/18/2026 11:20 AM, sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> - [High] Architectural flaw preventing the M7 core from using the CAN1 transceiver.
> - [High] Incorrect drive strength in `pinctrl_usdhc2_200mhz` causing potential SD card instability.
> - [Medium] Mismatch between commit message claiming 10G ETH support and device tree implementation.
> - [Medium] Dead pinctrl configuration in the reserved `flexcan1` node.
> - [Low] Unused `reg_3p3v` regulator node.
> --
> 
> commit 65457c99452cde3ade57a7afda12053dd0e2d5ee
> Author: Joseph Guo <qijian.guo@nxp.com>
> 
> arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
> 
> This commit adds the device tree for the NXP i.MX95 19x19 FRDM PRO board,
> which is based on the i.MX95 19x19 SoC. It configures various peripherals
> including USB, PCIe, ethernet, CAN, and regulators.
> 
>> - 10G ETH interface
> 
> The commit message claims support for a 10G ETH interface, but the device tree
> only configures enetc_port0 and enetc_port1 as 1 Gbps rgmii-id interfaces and
> entirely omits the i.MX95 10G Ethernet MAC. Is this omission intentional?
> 
10G ETH interface is not enabled in this device tree. But it is supported by hardware.


>> diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts
>> new file mode 100644
>> index 0000000000000..b87a26b0d7fcf
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts
>> @@ -0,0 +1,1021 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright 2026 NXP
>> + */
> 
> [ ... ]
> 
>> +     flexcan1_phy: can-phy0 {
>> +             compatible = "nxp,tja1057";
>> +             #phy-cells = <0>;
>> +             max-bitrate = <5000000>;
>> +             silent-gpios = <&i2c4_gpio_expander_22 11 GPIO_ACTIVE_HIGH>;
>> +     };
> 
> [ ... ]
> 
>> +     reg_3p3v: regulator-3p3v {
>> +             compatible = "regulator-fixed";
>> +             regulator-name = "+V3.3_SW";
>> +             regulator-max-microvolt = <3300000>;
>> +             regulator-min-microvolt = <3300000>;
>> +     };
> 
> Is this regulator used anywhere? It doesn't have the regulator-always-on
> property and isn't referenced by any device node as a supply.
> 

Reference 3v3 here. I think should keep it here.> [ ... ]
> 
>> +&flexcan1 {
>> +     phys = <&flexcan1_phy>;
>> +     pinctrl-0 = <&pinctrl_flexcan1>;
>> +     pinctrl-names = "default";
>> +     status = "reserved";
>> +};
> 
> Will the M7 core be able to use the CAN1 transceiver with this setup?
> 
> Since flexcan1 is marked as reserved, the Linux CAN driver won't probe it.
> As a result, Linux will never power on flexcan1_phy or drive the standby GPIO
> low. The Linux driver core will also ignore the pinctrl-0 configuration.
> 
> If the M7 core depends on Linux to set up the pin multiplexing and enable the
> PHY, does this need a gpio-hog on the expander and the pinctrl moved to an
> active pinctrl_hog group instead?
> 
M7 core didn't reply any linux side to set up the CAN1.

> [ ... ]
> 
>> +     pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
>> +             fsl,pins = <
>> +                     IMX95_PAD_SD2_CLK__USDHC2_CLK                           0x158e
>> +                     IMX95_PAD_SD2_CMD__USDHC2_CMD                           0x138e
>> +                     IMX95_PAD_SD2_DATA0__USDHC2_DATA0                       0x138e
>> +                     IMX95_PAD_SD2_DATA1__USDHC2_DATA1                       0x138e
>> +                     IMX95_PAD_SD2_DATA2__USDHC2_DATA2                       0x138e
>> +                     IMX95_PAD_SD2_DATA3__USDHC2_DATA3                       0x138e
>> +                     IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT                   0x51e
>> +             >;
>> +     };
> 
> Are these pad settings correct for 200MHz operation?
> 
> These use the exact same pad settings (0x138e and 0x158e) as the 100MHz group,
> whereas usdhc1 and usdhc3 correctly configure higher drive strength (0x13fe and
> 0x15fe) for 200MHz. Can this lower drive strength cause signal integrity
> issues or CRC errors with the SD card at 200MHz?
> 

For SD card. The driver strength is enough for 200Mhz. No CRC error was found during stress test.