devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Artur Weber <aweber.kernel@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Lee Jones <lee@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	Broadcom internal kernel review list
	<bcm-kernel-feedback-list@broadcom.com>,
	Stanislav Jakubek <stano.jakubek@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH v3 2/7] dt-bindings: mfd: brcm,bcm59056: Add compatible for BCM59054
Date: Wed, 5 Feb 2025 18:58:25 +0100	[thread overview]
Message-ID: <ab853605-859d-44c6-8cbd-44391cd677e6@gmail.com> (raw)
In-Reply-To: <20250202-noisy-impala-of-triumph-c9aa8b@krzk-bin>

On 2.02.2025 14:24, Krzysztof Kozlowski wrote:
> On Fri, Jan 31, 2025 at 07:13:50PM +0100, Artur Weber wrote:
>> ...
>> @@ -22,7 +24,6 @@ properties:
>>     regulators:
>>       type: object
>>       description: Container node for regulators.
>> -    $ref: ../regulator/brcm,bcm59056.yaml
> 
> Refs should rather stay here, so I don't think keeping these devices in
> one binding makes it simpler.
> 
> Simpler - drop ref and add properties compatible with enum for your
> regulator compatibles.
> 

The only problem with that is that the regulator nodes have no
compatibles. I see two ways out of it: either we add a compatible then
use the compatible enum (might break existing users who don't have the
compatible, unless we make the driver ignore it), or if we just want to
simplify but not add compatibles, list all the refs under an oneOf
condition (like it's done in
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml[1]).

Personally I'm in favor of keeping this as-is, though, for the benefit
of the DT linter preventing accidental mixing of bindings for different
device types (e.g. BCM59056 MFD node with BCM59054 regulators). There's
at least some precedent for this method[2]. But if making it simple is
what's considered better, I'll go with one of the aforementioned
options.

Best regards
Artur

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml#n147
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml#n69

  reply	other threads:[~2025-02-05 17:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-31 18:13 [PATCH v3 0/7] mfd: bcm590xx: Add support for BCM59054 Artur Weber
2025-01-31 18:13 ` [PATCH v3 1/7] dt-bindings: mfd: brcm,bcm59056: Convert to YAML Artur Weber
2025-02-02  9:56   ` Stanislav Jakubek
2025-02-02 13:27   ` Krzysztof Kozlowski
2025-02-04 18:33     ` Artur Weber
2025-01-31 18:13 ` [PATCH v3 2/7] dt-bindings: mfd: brcm,bcm59056: Add compatible for BCM59054 Artur Weber
2025-01-31 19:41   ` Rob Herring (Arm)
2025-02-02 10:08   ` Stanislav Jakubek
2025-02-02 13:24   ` Krzysztof Kozlowski
2025-02-05 17:58     ` Artur Weber [this message]
2025-01-31 18:13 ` [PATCH v3 3/7] ARM: dts: Drop DTS for BCM59056 PMIC Artur Weber
2025-01-31 18:13 ` [PATCH v3 4/7] mfd: bcm590xx: Add compatible for BCM59054 Artur Weber
2025-02-07  8:48   ` Lee Jones
2025-02-07 13:06     ` Artur Weber
2025-02-10 16:33       ` Lee Jones
2025-01-31 18:13 ` [PATCH v3 5/7] regulator: bcm590xx: Store regulator descriptions in table Artur Weber
2025-01-31 18:13 ` [PATCH v3 6/7] regulator: bcm590xx: Rename BCM59056-specific data as such Artur Weber
2025-01-31 18:13 ` [PATCH v3 7/7] regulator: bcm590xx: Add support for BCM59054 regulators Artur Weber
2025-02-05 19:12   ` Stanislav Jakubek

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=ab853605-859d-44c6-8cbd-44391cd677e6@gmail.com \
    --to=aweber.kernel@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=florian.fainelli@broadcom.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjui@broadcom.com \
    --cc=robh@kernel.org \
    --cc=sbranden@broadcom.com \
    --cc=stano.jakubek@gmail.com \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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;
as well as URLs for NNTP newsgroup(s).