Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Duplicate and conflicting pin configurations for SD0_DATA4..7.
- [Medium] Incorrect regulator voltage definition for 1.2V regulator (configured as 1.8V).
--
--- Patch [3]: [PATCH v5 3/5] arm64: dts: renesas: add support for solidrun rzg2l som and hb-iiot evb ---
commit a06fa05f228a45d469963a631b35258ab838f598
Author: Josua Mayer <[email protected]>
arm64: dts: renesas: add support for solidrun rzg2l som and hb-iiot evb
This commit adds device tree support for the SolidRun RZ/G2L SoM on the
Hummingboard IIoT. The SoM features dual Ethernet, eMMC, DDR, and WiFi/BT.
Overlays are included for eMMC, microSD, and RS485 features that depend on
configurable mux states.
Link: https://www.solid-run.com/embedded-industrial-iot/renesas-rz-family/rz-g2l-som/
Link: https://www.solid-run.com/embedded-industrial-iot/renesas-rz-family/hummingboard-rz-series-sbcs/hummingboard-rz-g2l-iot-sbc/
> diff --git a/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-common.dtsi b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-common.dtsi
> new file mode 100644
> index 0000000000000..ca5a647d43dcc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2l-hummingboard-iiot-common.dtsi
> @@ -0,0 +1,560 @@
[ ... ]
> + v_1_2: regulator-1-2 {
> + compatible = "regulator-fixed";
> + regulator-name = "1v2";
> + regulator-max-microvolt = <1800000>;
> + regulator-min-microvolt = <1800000>;
> + };
[Severity: Medium]
Are the regulator limits set to the intended values here?
The regulator is named v_1_2 in the node name and "1v2" in the regulator-name
property, but the regulator-max-microvolt and regulator-min-microvolt fields
are configured for 1.8V (1800000).
Could this misconfiguration cause issues on boot when downstream drivers
like the USB hub driver query this regulator?
> +
> + v_3_3: regulator-3-3 {
[ ... ]
> diff --git a/arch/arm64/boot/dts/renesas/rzg2l-sr-som.dtsi b/arch/arm64/boot/dts/renesas/rzg2l-sr-som.dtsi
> new file mode 100644
> index 0000000000000..f08d2fbaa5211
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2l-sr-som.dtsi
> @@ -0,0 +1,461 @@
[ ... ]
> + sdhi0_4bit_pins: sdhi0-4bit {
> + sd0_ctrl_dat03 {
> + pins = "SD0_DATA0", "SD0_DATA1", "SD0_DATA2", "SD0_DATA3",
> + "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7",
> + "SD0_CLK", "SD0_CMD";
> + power-source = <3300>;
> + };
[Severity: High]
Should SD0_DATA4 through SD0_DATA7 be included in the pins list for
sd0_ctrl_dat03?
When sdhi0_4bit_pins is applied during probe, sd0_ctrl_dat03 configures
these pins with power-source = <3300>. The sd0_dat47 subnode directly below
configures them again with bias-disable and input-enable.
Could the short window between applying these two nodes cause default pull-ups
on the 3.3V domain to backdrive the 1.8V eMMC pins?
> +
> + /*
> + * Pins 4-7 are hard-wired to eMMC with 1.8V IO voltage,
> + * with all pins sharing a single voltage domain.
> + *
> + * Configure as input without pull to avoid overvoltage,
> + * and accidental use e.g. as gpio (default pin-function).
> + */
> + sd0_dat47 {
> + bias-disable;
> + input-enable;
> + pins = "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7";
> + power-source = <3300>;
> + };
> + };
> +
> + sdhi0_4bit_uhs_pins: sdhi0-4bit-uhs {
> + sd0_ctrl_dat03 {
> + pins = "SD0_DATA0", "SD0_DATA1", "SD0_DATA2", "SD0_DATA3",
> + "SD0_DATA4", "SD0_DATA5", "SD0_DATA6", "SD0_DATA7",
> + "SD0_CLK", "SD0_CMD";
> + power-source = <1800>;
> + };
[Severity: High]
Does this pin list also incorrectly duplicate SD0_DATA4 through SD0_DATA7?
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.