All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Krzysztof Kozlowski" <krzk@kernel.org>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Heiko Stuebner" <heiko@sntech.de>
Cc: <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>,
	"Dragan Simic" <dsimic@manjaro.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 16:55:24 +0100	[thread overview]
Message-ID: <D75BKUFGD6OE.1767NEFXCRJEJ@cknow.org> (raw)
In-Reply-To: <e1097f84-e40f-45ff-8b8d-125f7159ec1e@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]

On Sat Jan 18, 2025 at 9:41 AM CET, Krzysztof Kozlowski wrote:
> On 16/01/2025 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:
> >>> 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.
>
> > 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.

> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Krzysztof Kozlowski" <krzk@kernel.org>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Heiko Stuebner" <heiko@sntech.de>
Cc: <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>,
	"Dragan Simic" <dsimic@manjaro.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 16:55:24 +0100	[thread overview]
Message-ID: <D75BKUFGD6OE.1767NEFXCRJEJ@cknow.org> (raw)
In-Reply-To: <e1097f84-e40f-45ff-8b8d-125f7159ec1e@kernel.org>


[-- Attachment #1.1: Type: text/plain, Size: 2587 bytes --]

On Sat Jan 18, 2025 at 9:41 AM CET, Krzysztof Kozlowski wrote:
> On 16/01/2025 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:
> >>> 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.
>
> > 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.

> > 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  parent reply	other threads:[~2025-01-18 15:57 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
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 [this message]
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=D75BKUFGD6OE.1767NEFXCRJEJ@cknow.org \
    --to=didi.debian@cknow.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.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=krzk@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.