All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Peter Geis <pgwipeout@gmail.com>, Krzysztof Kozlowski <krzk@kernel.org>
Cc: Dongjin Kim <tobetter@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: Add Hardkernel ODROID-M1 board
Date: Sun, 17 Apr 2022 22:55:25 +0200	[thread overview]
Message-ID: <12089439.O9o76ZdvQC@phil> (raw)
In-Reply-To: <ff0135dc-da30-18b5-f5f4-cefdb0455c6b@kernel.org>

Am Sonntag, 17. April 2022, 19:45:52 CEST schrieb Krzysztof Kozlowski:
> On 16/04/2022 14:07, Peter Geis wrote:
> 
> >>> +     dc_12v: dc-12v {
> >>
> >> Generic node name, so "regulator" or "regulator-0"
> > 
> > Unfortunately, this advice breaks the regulator-fixed driver, which it
> > seems cannot cope with a bunch of nodes all named "regulator".
> 
> What exactly cannot cope? You cannot have different device nodes with
> the same name but this is not a limitation of regulator but devicetree spec.
> 
> > Setting the regulators as regulator-0 -1 -2 leads to fun issues where
> > the regulator numbering in the kernel doesn't match the node numbers.
> 
> There are no "node numbers"... maybe you mean unit addresses? But there
> are none here.
> 
> > It also makes it more fun when additional regulators need to be added
> > and everything gets shuffled around.
> 
> Usually adding - in subsequent DTS files - means increasing the numbers
> so if you have regulator-[012] then just use regulator-[345] in other
> files. I see potential mess when you combine several DTSI files, each
> defining regulators, so in such case "some-name-regulator" (or reversed)
> is also popular approach.

so going with

	dc_12v: dc-12v-regulator {
	};

i.e. doing a some-name-regulator would be an in-spec way to go?

In this case I would definitely prefer this over doing a numbered thing.

I.e. regulator-0 can create really hard to debug issues, when you have
another accidential regulator-0 for a different regulator in there, which
then would create some sort of merged node.


Heiko

> 
> > If naming these uniquely to avoid confusion and collisions is such an
> > issue, why is it not caught by make W=1 dtbs_check?
> 
> Patches are welcome. :)
> 
> Best regards,
> Krzysztof
> 





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

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Peter Geis <pgwipeout@gmail.com>, Krzysztof Kozlowski <krzk@kernel.org>
Cc: Dongjin Kim <tobetter@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: Add Hardkernel ODROID-M1 board
Date: Sun, 17 Apr 2022 22:55:25 +0200	[thread overview]
Message-ID: <12089439.O9o76ZdvQC@phil> (raw)
In-Reply-To: <ff0135dc-da30-18b5-f5f4-cefdb0455c6b@kernel.org>

Am Sonntag, 17. April 2022, 19:45:52 CEST schrieb Krzysztof Kozlowski:
> On 16/04/2022 14:07, Peter Geis wrote:
> 
> >>> +     dc_12v: dc-12v {
> >>
> >> Generic node name, so "regulator" or "regulator-0"
> > 
> > Unfortunately, this advice breaks the regulator-fixed driver, which it
> > seems cannot cope with a bunch of nodes all named "regulator".
> 
> What exactly cannot cope? You cannot have different device nodes with
> the same name but this is not a limitation of regulator but devicetree spec.
> 
> > Setting the regulators as regulator-0 -1 -2 leads to fun issues where
> > the regulator numbering in the kernel doesn't match the node numbers.
> 
> There are no "node numbers"... maybe you mean unit addresses? But there
> are none here.
> 
> > It also makes it more fun when additional regulators need to be added
> > and everything gets shuffled around.
> 
> Usually adding - in subsequent DTS files - means increasing the numbers
> so if you have regulator-[012] then just use regulator-[345] in other
> files. I see potential mess when you combine several DTSI files, each
> defining regulators, so in such case "some-name-regulator" (or reversed)
> is also popular approach.

so going with

	dc_12v: dc-12v-regulator {
	};

i.e. doing a some-name-regulator would be an in-spec way to go?

In this case I would definitely prefer this over doing a numbered thing.

I.e. regulator-0 can create really hard to debug issues, when you have
another accidential regulator-0 for a different regulator in there, which
then would create some sort of merged node.


Heiko

> 
> > If naming these uniquely to avoid confusion and collisions is such an
> > issue, why is it not caught by make W=1 dtbs_check?
> 
> Patches are welcome. :)
> 
> Best regards,
> Krzysztof
> 





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Peter Geis <pgwipeout@gmail.com>, Krzysztof Kozlowski <krzk@kernel.org>
Cc: Dongjin Kim <tobetter@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: Add Hardkernel ODROID-M1 board
Date: Sun, 17 Apr 2022 22:55:25 +0200	[thread overview]
Message-ID: <12089439.O9o76ZdvQC@phil> (raw)
In-Reply-To: <ff0135dc-da30-18b5-f5f4-cefdb0455c6b@kernel.org>

Am Sonntag, 17. April 2022, 19:45:52 CEST schrieb Krzysztof Kozlowski:
> On 16/04/2022 14:07, Peter Geis wrote:
> 
> >>> +     dc_12v: dc-12v {
> >>
> >> Generic node name, so "regulator" or "regulator-0"
> > 
> > Unfortunately, this advice breaks the regulator-fixed driver, which it
> > seems cannot cope with a bunch of nodes all named "regulator".
> 
> What exactly cannot cope? You cannot have different device nodes with
> the same name but this is not a limitation of regulator but devicetree spec.
> 
> > Setting the regulators as regulator-0 -1 -2 leads to fun issues where
> > the regulator numbering in the kernel doesn't match the node numbers.
> 
> There are no "node numbers"... maybe you mean unit addresses? But there
> are none here.
> 
> > It also makes it more fun when additional regulators need to be added
> > and everything gets shuffled around.
> 
> Usually adding - in subsequent DTS files - means increasing the numbers
> so if you have regulator-[012] then just use regulator-[345] in other
> files. I see potential mess when you combine several DTSI files, each
> defining regulators, so in such case "some-name-regulator" (or reversed)
> is also popular approach.

so going with

	dc_12v: dc-12v-regulator {
	};

i.e. doing a some-name-regulator would be an in-spec way to go?

In this case I would definitely prefer this over doing a numbered thing.

I.e. regulator-0 can create really hard to debug issues, when you have
another accidential regulator-0 for a different regulator in there, which
then would create some sort of merged node.


Heiko

> 
> > If naming these uniquely to avoid confusion and collisions is such an
> > issue, why is it not caught by make W=1 dtbs_check?
> 
> Patches are welcome. :)
> 
> Best regards,
> Krzysztof
> 





  reply	other threads:[~2022-04-17 20:55 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29  9:44 [PATCH 1/2] dt-bindings: rockchip: Add Hardkernel ODROID-M1 board Dongjin Kim
2022-03-29  9:44 ` Dongjin Kim
2022-03-29  9:44 ` Dongjin Kim
2022-03-29  9:44 ` [PATCH 2/2] arm64: dts: " Dongjin Kim
2022-03-29  9:44   ` Dongjin Kim
2022-03-29  9:44   ` Dongjin Kim
2022-03-29 17:12   ` Krzysztof Kozlowski
2022-03-29 17:12     ` Krzysztof Kozlowski
2022-03-29 17:12     ` Krzysztof Kozlowski
2022-04-05  2:32     ` Dongjin Kim
2022-04-05  2:32       ` Dongjin Kim
2022-04-05  2:32       ` Dongjin Kim
2022-04-05  6:13       ` Krzysztof Kozlowski
2022-04-05  6:13         ` Krzysztof Kozlowski
2022-04-05  6:13         ` Krzysztof Kozlowski
2022-04-16 12:07     ` Peter Geis
2022-04-16 12:07       ` Peter Geis
2022-04-16 12:07       ` Peter Geis
2022-04-17 17:45       ` Krzysztof Kozlowski
2022-04-17 17:45         ` Krzysztof Kozlowski
2022-04-17 17:45         ` Krzysztof Kozlowski
2022-04-17 20:55         ` Heiko Stuebner [this message]
2022-04-17 20:55           ` Heiko Stuebner
2022-04-17 20:55           ` Heiko Stuebner
2022-04-18 11:21           ` Krzysztof Kozlowski
2022-04-18 11:21             ` Krzysztof Kozlowski
2022-04-18 11:21             ` Krzysztof Kozlowski
2022-04-18 11:46             ` Peter Geis
2022-04-18 11:46               ` Peter Geis
2022-04-18 11:46               ` Peter Geis
2022-04-04 18:10 ` [PATCH 1/2] dt-bindings: " Rob Herring
2022-04-04 18:10   ` Rob Herring
2022-04-04 18:10   ` Rob Herring

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=12089439.O9o76ZdvQC@phil \
    --to=heiko@sntech.de \
    --cc=devicetree@vger.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=tobetter@gmail.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.