Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards

On 11.03.21 14:17, Nishanth Menon wrote:

On 10:37-20210310, Jan Kiszka wrote:

quoted

From: Jan Kiszka <jan.kiszka@siemens.com>
+	spidev@0 {
+		compatible = "rohm,dh2228fv";
+		spi-max-frequency = <20000000>;
+		reg = <0>;

Jan,

As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning

WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
#629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
		compatible = "rohm,dh2228fv";

I cannot pick up nodes that are'nt documented as yaml in
	Documentation/devicetree

I know this is irritating to find such nodes that already have previous
users and the person coming last gets to deal with "new rules".. but
sorry for catching this so late.

Here are the options that come to mind:

option 1) - drop the node and resubmit.

option 2) - get the documentation into linux master tree and then submit
the patches.

As you said, I'm not setting a precedence here:

arch/arm/boot/dts/imx28-cfa10049.dts:                   compatible = "rohm,dh2228fv";
arch/arm/boot/dts/rv1108-elgin-r1.dts:          compatible = "rohm,dh2228fv";
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts:           compatible = "rohm,dh2228fv";
drivers/spi/spidev.c:   { .compatible = "rohm,dh2228fv" },

Was just just never documented as binding? Or why is no one allowed to 
use this anymore? What is to be used instead for spidev?

I think we should just drop the node and resubmit - since this is a more
intrusive change and I don't have your platform handy, I am going to
suggest you make a call :(

This breaks userspace here, and we would need to carry that node on top.

BTW, I already brought up the topic internally to get you some boards 
for testing.

Additionally please install yamlint and dtbs_schema -> run dtbs_check. I
see more than a few warnings there which may need some closer look.

I've done that and addressed all that I could (former patch 4). We 
import those from k3, and I don't feel confident how to resolve them.
See also v1 of this patch.

Jan

A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/


PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv

I have been using my script to verify with kpv -C -V -n num_patches and
then digging through the logs.

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel