Re: [RFC PATCH v1 4/6] arm64: dts: rockchip: add rk3328 usb3 phy node

On Sat Jan 18, 2025 at 9:41 AM CET, Krzysztof Kozlowski wrote:

On 16/01/2025 17:53, Diederik de Haas wrote:

quoted

On Thu Jan 16, 2025 at 2:01 PM CET, Krzysztof Kozlowski wrote:

quoted

On 15/01/2025 02:26, Peter Geis wrote:

quoted

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 7d992c3c01ce..181a900d41f9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi

@@ -903,6 +903,43 @@ u2phy_host: host-port {
 		};
 	};
 
+	usb3phy: usb3-phy@ff460000 {
+		compatible = "rockchip,rk3328-usb3phy";
+		reg = <0x0 0xff460000 0x0 0x10000>;
+		clocks = <&cru SCLK_REF_USB3OTG>, <&cru PCLK_USB3PHY_OTG>, <&cru PCLK_USB3PHY_PIPE>;

Please wrap code according to coding style (checkpatch is not a coding
style description, but only a tool), so at 80.

I'm confused: is it 80 or 100?

I always thought it was 80, but then I saw several patches/commits by

Coding style is clear: it is 80. It also has caveat about code
readability and several maintainers have their own preference.

quoted

Dragan Simic which deliberately changed code to make use of 100.
Being fed up with my own confusion, I submitted a PR to 
https://github.com/gregkh/kernel-coding-style/ which got accepted:
https://github.com/gregkh/kernel-coding-style/commit/5c21f99dc79883bd0efeba368193180275c9c77a

That's not kernel. That's Greg...

FWIW: what Greg and Linus think/say is relevant to me.

quoted

So now both the vim plugins code and README say 100.
But as noted in my commit message:

  Note that the current upstream 'Linux kernel coding style' does NOT
  mention the 100 char limit, but only mentions the preferred max length
  of 80.

Or is it 100 for code, but 80 for DeviceTree files and bindings?

From where did you get 100? Checkpatch, right? Kernel coding style is
clear, there is no discussion, no mentioning 100:

"The preferred limit on the length of a single line is 80 columns. "

So to be clear: all DTS, all DT bindings, all code maintained by me and
some maintainers follows above (and further - there is caveat)
instruction from coding style. Some maintainers follow other rules and
that's fine.

But indeed, before Greg or Linus (likely) see it, a patch submitter
needs to convince the (subsystem) maintainer that it is an improvement.

Thanks for the clarification :-)

Cheers,
  Diederik