On 17/01/2025 05:10, Dragan Simic wrote:
> Hello Diederik,
>
> 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@xxxxxxxxx>
>>>> ---
>>>>
>>>> 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@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
>> 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.
> 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.
Best regards,
Krzysztof
