linux-kernel - Re: [PATCH 0/5] arm64: dts: rockchip: pinmux fixes and support for 2 adapters for Theobroma boards

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f9b40055-bcb0-4245-b899-4c7890e81b20@cherry.de>
Date: Fri, 21 Feb 2025 11:01:44 +0100
From: Quentin Schulz <quentin.schulz@...rry.de>
To: "Rob Herring (Arm)" <robh@...nel.org>,
 Quentin Schulz <foss+kernel@...il.net>
Cc: Heiko Stuebner <heiko@...ech.de>,
 Farouk Bouabid <farouk.bouabid@...obroma-systems.com>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-rockchip@...ts.infradead.org, Conor Dooley <conor+dt@...nel.org>,
 Quentin Schulz <quentin.schulz@...obroma-systems.com>,
 devicetree@...r.kernel.org, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 stable@...r.kernel.org
Subject: Re: [PATCH 0/5] arm64: dts: rockchip: pinmux fixes and support for 2
 adapters for Theobroma boards

Hi Rob, Heiko,

On 2/20/25 10:29 PM, Rob Herring (Arm) wrote:
> 
> On Thu, 20 Feb 2025 13:20:09 +0100, Quentin Schulz wrote:
[...]
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
> 
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
> 
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
> 
>    pip3 install dtschema --upgrade
> 
> 
> New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/' for 20250220-ringneck-dtbos-v1-0-25c97f2385e6@...rry.de:
> 

$ make ARCH=arm64 CROSS_COMPILE="ccache aarch64-linux-gnu-" O=ringneck/ 
CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/
make[1]: Entering directory '/home/qschulz/work/upstream/linux/ringneck'
make[3]: *** No rule to make target 'for'.  Stop.
make[2]: *** [/home/qschulz/work/upstream/linux/Makefile:372: 
__build_one_by_one] Error 2
make[1]: *** [/home/qschulz/work/upstream/linux/Makefile:251: 
__sub-make] Error 2
make[1]: Leaving directory '/home/qschulz/work/upstream/linux/ringneck'
make: *** [Makefile:251: __sub-make] Error 2

Is there a way your bot can provide a command we can actually run?

I believe for me it is something like:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y $(for dtb 
in arch/arm64/boot/dts/rockchip/*.dtb; do D=$(basename $(dirname 
"$dtb")); B=$(basename "$dtb"); echo -n "$D/$B "; done)

> arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dtb: uart: uart5-rts-gpio: {'rockchip,pins': [[0, 13, 0, 147]], 'phandle': 70} is not of type 'array'
> 	from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml#
> 
> 

I believe this is a false positive due to the node suffix being -gpio? 
If I change -gpio suffix to -pin, it doesn't complain anymore.

"""
diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts 
b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts
index 08a11e4758413..249e50d64791e 100644
--- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts
@@ -196,7 +196,7 @@ sd_card_led_pin: sd-card-led-pin {
  	};

  	uart {
-		uart5_rts_gpio: uart5-rts-gpio {
+		uart5_rts_pin: uart5-rts-pin {
  			rockchip,pins =
  			  <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
  		};
@@ -234,7 +234,7 @@ &uart0 {
  };

  &uart5 {
-	pinctrl-0 = <&uart5_xfer &uart5_rts_gpio>;
+	pinctrl-0 = <&uart5_xfer &uart5_rts_pin>;
  	rts-gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
  	status = "okay";
  };
"""

@Heiko, I guess you would like a warning-less DT :) I can send a v2 with 
that change then if that works for you? I can wait a few days for other 
reviews :)

I'm specifically avoiding naming it uart5_rts because it already exists 
for the RTS function muxing of the UART5 controller and I don't think 
it's appropriate to just override it like that.

Cheers,
Quentin