public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2025-01-18  9:52 UTC|newest]

Thread overview: 44+ 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 ` [RFC PATCH v1 1/6] clk: rockchip: fix wrong clk_ref_usb3otg parent " Peter Geis
2025-01-15  1:26 ` [RFC PATCH v1 2/6] dt-bindings: phy: rockchip: add rk3328 usb3 phy Peter Geis
2025-01-16 13:08   ` Krzysztof Kozlowski
2025-01-16 13:32     ` Peter Geis
2025-01-16 13:59       ` Peter Geis
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 11:24   ` Piotr Oniszczuk
2025-01-16 14:09     ` Peter Geis
2025-01-16 12:59   ` Krzysztof Kozlowski
2025-01-16 13:14     ` Peter Geis
2025-01-16 15:26   ` Diederik de Haas
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-16 13:01   ` Krzysztof Kozlowski
2025-01-16 16:53     ` Diederik de Haas
2025-01-17  4:10       ` Dragan Simic
2025-01-18  8:46         ` Krzysztof Kozlowski
2025-01-18  9:25           ` Dragan Simic
2025-01-18  9:31             ` Krzysztof Kozlowski
2025-01-18  9:43               ` Dragan Simic
2025-01-18  9:52                 ` Krzysztof Kozlowski [this message]
2025-01-18 10:10                   ` Dragan Simic
2025-01-18 10:29                     ` Krzysztof Kozlowski
2025-01-18 10:45                       ` Dragan Simic
2025-01-18 14:22                         ` Peter Geis
2025-01-18  8:41       ` Krzysztof Kozlowski
2025-01-18  9:19         ` Krzysztof Kozlowski
2025-01-18  9:34           ` Dragan Simic
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 ` [RFC PATCH v1 6/6] arm64: dts: rockchip: enable the usb3 phy on remaining rk3328 boards 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 12:25   ` Peter Geis
2025-01-15 12:35     ` Piotr Oniszczuk
2025-01-15 13:15       ` Peter Geis
2025-01-15 13:25         ` Piotr Oniszczuk
2025-01-16 14:02           ` Peter Geis
2025-01-16 14:35             ` Piotr Oniszczuk
2025-01-16 16:00               ` Peter Geis
2025-01-18  9:08 ` Krzysztof Kozlowski
2025-01-18 14:35   ` Peter Geis
2025-02-26 19:49 ` (subset) " 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox