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

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: <60ced7df829e7c10e264627cc0947762@manjaro.org>
Date: Sat, 18 Jan 2025 10:25:00 +0100
From: Dragan Simic <dsimic@...jaro.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Diederik de Haas <didi.debian@...ow.org>, Peter Geis
 <pgwipeout@...il.com>, Heiko Stuebner <heiko@...ech.de>, zyw@...k-chips.com,
 kever.yang@...k-chips.com, frank.wang@...k-chips.com,
 william.wu@...k-chips.com, wulf@...k-chips.com,
 linux-rockchip@...ts.infradead.org, Alex Bee <knaerzche@...il.com>, Conor
 Dooley <conor+dt@...nel.org>, Johan Jonker <jbx6244@...il.com>, Jonas
 Karlman <jonas@...boo.se>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob
 Herring <robh@...nel.org>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 4/6] arm64: dts: rockchip: add rk3328 usb3 phy node

Hello Krzysztof,

On 2025-01-18 09:46, Krzysztof Kozlowski wrote:
> On 17/01/2025 05:10, Dragan Simic wrote:
>> On 2025-01-16 17:53, Diederik de Haas wrote:
>>> On Thu Jan 16, 2025 at 2:01 PM CET, Krzysztof Kozlowski wrote:
>>>> On 15/01/2025 02:26, Peter Geis wrote:
>>>>> Add the node for the rk3328 usb3 phy. This node provides a combined 
>>>>> usb2
>>>>> and usb3 phy which are permenantly tied to the dwc3 usb3 
>>>>> controller.
>>>>> 
>>>>> Signed-off-by: Peter Geis <pgwipeout@...il.com>
>>>>> ---
>>>>> 
>>>>>  arch/arm64/boot/dts/rockchip/rk3328.dtsi | 39 
>>>>> ++++++++++++++++++++++++
>>>>>  1 file changed, 39 insertions(+)
>>>>> 
>>>>> 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@...60000 {
>>>>> +		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
>>> 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
>>> 
>>> 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?
>> 
>> I don't know about the DT files and bindings, but the 100-column limit
>> for the kernel code has been in effect for years.  In this day and 
>> age,
> 
> That's just false. It was never in effect for years. Read kernel coding
> style document.

Perhaps it's about the semantics.

Please see the commit bdc48fa11e46 (checkpatch/coding-style: deprecate
80-column warning, 2020-05-29), which clearly shows that the 80-column
rule is still _preferred_, but no longer _mandatory_.

>> 80 columns is really not much (for the record, I've been around when
>> using 80x25 _physical_ CRT screens was the norm).
> 
> You mistake agreement on dropping strong restriction in 2020 in
> checkpatch, which is "not for years" and even read that commit: "Yes,
> staying withing 80 columns is certainly still _preferred_."
> 
> Checkpatch is not coding style. Since when it would be? It's just a 
> tool.
> 
> And there were more talks and the 80-preference got relaxed yet still
> "not for years" (last talk was 2022?) and sill kernel coding style is
> here specific.

It's perhaps again about the semantics, this time about the meaning
of "for years".  I don't think there's some strict definition of that
term, so perhaps different people see it differently.

To get back to the above-mentioned commit bdc48fa11e46, the 80-column
limit has obviously been lifted, putting the new 100-column limit as
an option for those who prefer having fewer "artificial" line breaks
over adhering strictly to the rules.

Thus, as a maintainer, you're obviously free to enforce the 80-column
limit of you want so.

If my opinion counts, I'd agree with the 80-column limit when it comes
to the device trees and bindings.  Keeping those files at the lower
width usually makes them more readable to me.  However, enforcing the
80-column limit in C and header files very often leads to having line
breaks that do nothing but make the code look a bit silly.