From: Krzysztof Kozlowski <krzk@kernel.org>
To: Dragan Simic <dsimic@manjaro.org>
Cc: Diederik de Haas <didi.debian@cknow.org>,
Peter Geis <pgwipeout@gmail.com>,
Heiko Stuebner <heiko@sntech.de>,
zyw@rock-chips.com, kever.yang@rock-chips.com,
frank.wang@rock-chips.com, william.wu@rock-chips.com,
wulf@rock-chips.com, linux-rockchip@lists.infradead.org,
Alex Bee <knaerzche@gmail.com>,
Conor Dooley <conor+dt@kernel.org>,
Johan Jonker <jbx6244@gmail.com>, Jonas Karlman <jonas@kwiboo.se>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Rob Herring <robh@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 4/6] arm64: dts: rockchip: add rk3328 usb3 phy node
Date: Sat, 18 Jan 2025 10:52:42 +0100 [thread overview]
Message-ID: <735d89df-9954-44bd-aca6-4bb165737626@kernel.org> (raw)
In-Reply-To: <3d9ce9fd9b6309553b5669e111bc4200@manjaro.org>
On 18/01/2025 10:43, Dragan Simic wrote:
>>>
>>> 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_.
>>
>> I brought that commit, but nice that you also found it.
>>
>> Still: read the coding style, not checkpatch tool.
>>
>>>>> 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
>>
>> "Lifted" on *CHECKPATCH*, not on coding style. Do you see the
Repeating myself about because you are not addressing the actual difference.
>> difference? One is a helper tool which people were using blindly and
>> wrapping lines without thinking, claiming that checkpatch told them to
>> do so. Other is the actual coding style.
>>
>> You claim that coding style was changed. This never happened.
>
> It was obviously changed in the commit bdc48fa11e46, by making the
> 80-column width preferred, instead of if being mandatory. The way
> I read the changes to the coding style introduced in that commit,
> it's now possible to go over 80 columns, up to 100 columns, _if_
> that actually improves the readability of the source code.
The commit is for checkpatch. Point to the change in coding style. You
are bringing argument for checkpatch, so only a tool, as argument for
coding style. Again, coding style did not change since years.
Best regards,
Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Dragan Simic <dsimic@manjaro.org>
Cc: Diederik de Haas <didi.debian@cknow.org>,
Peter Geis <pgwipeout@gmail.com>,
Heiko Stuebner <heiko@sntech.de>,
zyw@rock-chips.com, kever.yang@rock-chips.com,
frank.wang@rock-chips.com, william.wu@rock-chips.com,
wulf@rock-chips.com, linux-rockchip@lists.infradead.org,
Alex Bee <knaerzche@gmail.com>,
Conor Dooley <conor+dt@kernel.org>,
Johan Jonker <jbx6244@gmail.com>, Jonas Karlman <jonas@kwiboo.se>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Rob Herring <robh@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 4/6] arm64: dts: rockchip: add rk3328 usb3 phy node
Date: Sat, 18 Jan 2025 10:52:42 +0100 [thread overview]
Message-ID: <735d89df-9954-44bd-aca6-4bb165737626@kernel.org> (raw)
In-Reply-To: <3d9ce9fd9b6309553b5669e111bc4200@manjaro.org>
On 18/01/2025 10:43, Dragan Simic wrote:
>>>
>>> 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_.
>>
>> I brought that commit, but nice that you also found it.
>>
>> Still: read the coding style, not checkpatch tool.
>>
>>>>> 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
>>
>> "Lifted" on *CHECKPATCH*, not on coding style. Do you see the
Repeating myself about because you are not addressing the actual difference.
>> difference? One is a helper tool which people were using blindly and
>> wrapping lines without thinking, claiming that checkpatch told them to
>> do so. Other is the actual coding style.
>>
>> You claim that coding style was changed. This never happened.
>
> It was obviously changed in the commit bdc48fa11e46, by making the
> 80-column width preferred, instead of if being mandatory. The way
> I read the changes to the coding style introduced in that commit,
> it's now possible to go over 80 columns, up to 100 columns, _if_
> that actually improves the readability of the source code.
The commit is for checkpatch. Point to the change in coding style. You
are bringing argument for checkpatch, so only a tool, as argument for
coding style. Again, coding style did not change since years.
Best regards,
Krzysztof
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-01-18 9:54 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 1:26 [RFC PATCH v1 0/6] rockchip: add a functional usb3 phy driver for rk3328 Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 1/6] clk: rockchip: fix wrong clk_ref_usb3otg parent " Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 2/6] dt-bindings: phy: rockchip: add rk3328 usb3 phy Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-16 13:08 ` Krzysztof Kozlowski
2025-01-16 13:08 ` Krzysztof Kozlowski
2025-01-16 13:08 ` Krzysztof Kozlowski
2025-01-16 13:32 ` Peter Geis
2025-01-16 13:32 ` Peter Geis
2025-01-16 13:32 ` Peter Geis
2025-01-16 13:59 ` Peter Geis
2025-01-16 13:59 ` Peter Geis
2025-01-16 13:59 ` Peter Geis
2025-01-18 9:06 ` Krzysztof Kozlowski
2025-01-18 9:06 ` Krzysztof Kozlowski
2025-01-18 9:06 ` Krzysztof Kozlowski
2025-01-15 1:26 ` [RFC PATCH v1 3/6] phy: rockchip: add driver for " Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 11:24 ` Piotr Oniszczuk
2025-01-15 11:24 ` Piotr Oniszczuk
2025-01-15 11:24 ` Piotr Oniszczuk
2025-01-16 14:09 ` Peter Geis
2025-01-16 14:09 ` Peter Geis
2025-01-16 14:09 ` Peter Geis
2025-01-16 12:59 ` Krzysztof Kozlowski
2025-01-16 12:59 ` Krzysztof Kozlowski
2025-01-16 12:59 ` Krzysztof Kozlowski
2025-01-16 13:14 ` Peter Geis
2025-01-16 13:14 ` Peter Geis
2025-01-16 13:14 ` Peter Geis
2025-01-16 15:26 ` Diederik de Haas
2025-01-16 15:26 ` Diederik de Haas
2025-01-16 15:26 ` Diederik de Haas
2025-01-16 15:57 ` Peter Geis
2025-01-16 15:57 ` Peter Geis
2025-01-16 15:57 ` Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 4/6] arm64: dts: rockchip: add rk3328 usb3 phy node Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-16 13:01 ` Krzysztof Kozlowski
2025-01-16 13:01 ` Krzysztof Kozlowski
2025-01-16 16:53 ` Diederik de Haas
2025-01-16 16:53 ` Diederik de Haas
2025-01-17 4:10 ` Dragan Simic
2025-01-17 4:10 ` Dragan Simic
2025-01-18 8:46 ` Krzysztof Kozlowski
2025-01-18 8:46 ` Krzysztof Kozlowski
2025-01-18 9:25 ` Dragan Simic
2025-01-18 9:25 ` Dragan Simic
2025-01-18 9:31 ` Krzysztof Kozlowski
2025-01-18 9:31 ` Krzysztof Kozlowski
2025-01-18 9:43 ` Dragan Simic
2025-01-18 9:43 ` Dragan Simic
2025-01-18 9:52 ` Krzysztof Kozlowski [this message]
2025-01-18 9:52 ` Krzysztof Kozlowski
2025-01-18 10:10 ` Dragan Simic
2025-01-18 10:10 ` Dragan Simic
2025-01-18 10:29 ` Krzysztof Kozlowski
2025-01-18 10:29 ` Krzysztof Kozlowski
2025-01-18 10:45 ` Dragan Simic
2025-01-18 10:45 ` Dragan Simic
2025-01-18 14:22 ` Peter Geis
2025-01-18 14:22 ` Peter Geis
2025-01-18 8:41 ` Krzysztof Kozlowski
2025-01-18 8:41 ` Krzysztof Kozlowski
2025-01-18 9:19 ` Krzysztof Kozlowski
2025-01-18 9:19 ` Krzysztof Kozlowski
2025-01-18 9:34 ` Dragan Simic
2025-01-18 9:34 ` Dragan Simic
2025-01-18 15:55 ` Diederik de Haas
2025-01-18 15:55 ` Diederik de Haas
2025-01-15 1:26 ` [RFC PATCH v1 5/6] arm64: dts: rockchip: enable the usb3 phy on rk3328-roc boards Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 6/6] arm64: dts: rockchip: enable the usb3 phy on remaining rk3328 boards Peter Geis
2025-01-15 1:26 ` Peter Geis
2025-01-15 11:22 ` [RFC PATCH v1 0/6] rockchip: add a functional usb3 phy driver for rk3328 Piotr Oniszczuk
2025-01-15 11:22 ` Piotr Oniszczuk
2025-01-15 11:22 ` Piotr Oniszczuk
2025-01-15 12:25 ` Peter Geis
2025-01-15 12:25 ` Peter Geis
2025-01-15 12:25 ` Peter Geis
2025-01-15 12:35 ` Piotr Oniszczuk
2025-01-15 12:35 ` Piotr Oniszczuk
2025-01-15 12:35 ` Piotr Oniszczuk
2025-01-15 13:15 ` Peter Geis
2025-01-15 13:15 ` Peter Geis
2025-01-15 13:15 ` Peter Geis
2025-01-15 13:25 ` Piotr Oniszczuk
2025-01-15 13:25 ` Piotr Oniszczuk
2025-01-15 13:25 ` Piotr Oniszczuk
2025-01-16 14:02 ` Peter Geis
2025-01-16 14:02 ` Peter Geis
2025-01-16 14:02 ` Peter Geis
2025-01-16 14:35 ` Piotr Oniszczuk
2025-01-16 14:35 ` Piotr Oniszczuk
2025-01-16 14:35 ` Piotr Oniszczuk
2025-01-16 16:00 ` Peter Geis
2025-01-16 16:00 ` Peter Geis
2025-01-16 16:00 ` Peter Geis
2025-01-18 9:08 ` Krzysztof Kozlowski
2025-01-18 9:08 ` Krzysztof Kozlowski
2025-01-18 9:08 ` Krzysztof Kozlowski
2025-01-18 14:35 ` Peter Geis
2025-01-18 14:35 ` Peter Geis
2025-01-18 14:35 ` Peter Geis
2025-02-26 19:49 ` (subset) " Heiko Stuebner
2025-02-26 19:49 ` Heiko Stuebner
2025-02-26 19:49 ` Heiko Stuebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=735d89df-9954-44bd-aca6-4bb165737626@kernel.org \
--to=krzk@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=dsimic@manjaro.org \
--cc=frank.wang@rock-chips.com \
--cc=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kever.yang@rock-chips.com \
--cc=knaerzche@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=pgwipeout@gmail.com \
--cc=robh@kernel.org \
--cc=william.wu@rock-chips.com \
--cc=wulf@rock-chips.com \
--cc=zyw@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.