From: "André Draszik" <andre.draszik@linaro.org>
To: Krzysztof Kozlowski <krzk@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Peter Griffin <peter.griffin@linaro.org>,
Tudor Ambarus <tudor.ambarus@linaro.org>,
Alim Akhtar <alim.akhtar@samsung.com>
Cc: Will McVicker <willmcvicker@google.com>,
kernel-team@android.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel
Date: Mon, 23 Dec 2024 15:31:59 +0000 [thread overview]
Message-ID: <9507951f9ce4ee9d8c553d8964f00ef217f8ed1d.camel@linaro.org> (raw)
In-Reply-To: <d960e22e-01ad-406d-9616-d45edbef0232@kernel.org>
On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote:
> On 23/12/2024 08:45, André Draszik wrote:
> > Hi Krzysztof,
> >
> > On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote:
> > > On 20/12/2024 12:27, André Draszik wrote:
> > > > Raven is Google's code name for Pixel 6 Pro. Since there are
> > > > differences compared to Pixel 6 (Oriole), we need to add a separate
> > > > compatible for it.
> > > >
> > > > We also want to support a generic DT, which can work on any type of
> > >
> > > There are no such generic DT devices upstream, so we cannot add bindings
> > > for them.
> >
> > Do you have a better suggestion for the wording?
> > How about 'gs101-based Pixel base board'?
>
> It's not exactly about the wording but the concept. We don't have
> generic devices, thus no generic DT (DTS). Period. Thus you cannot have
> such schema.
There is a Pixel base board, with different additions to it, e.g.
different displays. The boot loader can pick the right one.
Let's discuss that in the other thread to have things in one place :-)
>
> > > > gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as
> > > > a future addition). Such a DT will have certain nodes disabled / not
> > > > added. To facilitate such a generic gs101-based Pixel device, also add
> > > > a more generic gs101-pixel compatible. We can not just use the existing
> > > > google,gs101 for that, as it refers to the SoC, not a board.
> > > >
> > > > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> > > > ---
> > > > Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++----
> > > > 1 file changed, 14 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> > > > index e20b5c9b16bc..a8faf2256242 100644
> > > > --- a/Documentation/devicetree/bindings/arm/google.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/google.yaml
> > > > @@ -34,11 +34,21 @@ properties:
> > > > const: '/'
> > > > compatible:
> > > > oneOf:
> > > > - - description: Google Pixel 6 / Oriole
> > > > + - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6
> > > > + (Oriole), or 6 Pro (Raven)
> > > > + minItems: 2
> > > > + maxItems: 3
> > > > items:
> > > > - - enum:
> > > > - - google,gs101-oriole
> > > > - - const: google,gs101
> > > > + enum:
> > > > + - google,gs101-oriole
> > > > + - google,gs101-raven
> > > > + - google,gs101-pixel
> > > > + - google,gs101
> > >
> > > SoC cannot be a board in the same time.
> >
> > Can you please expand? google,gs101 is the SoC, the other ones are boards.
> > Is the commit message unclear?
>
> You now say that these are valid boards:
>
> compatible = "google,gs101", "google,gs101";
Sorry, I don't see how (apart from the fact that dtbs_check flags
non-unique elements anyway). The result of the patch is:
minItems: 2
maxItems: 3
items:
enum:
- google,gs101-oriole
- google,gs101-raven
- google,gs101-pixel
- google,gs101
allOf:
- contains:
const: google,gs101-pixel
- contains:
const: google,gs101
So one can not have 'google,gs101' twice. And if I only add
compatible = "google,gs101", "google,gs101";
to the .dts, then dtbs_check complains indeed.
> (although compatibles
>
> compatible = "google,gs101", "google,gs101-pixel";
OK, the schema doesn't flag incorrect ordering indeed.
> Both are wrong. SoC should not be before the board and SoC cannot be
> used alone. Your schema allows that and that's not good.
>
> I did not get what you want to achieve here, so tricky to advice.
The intention is to enforce either of the following three:
compatible = "google,gs101-raven", "google,gs101-pixel", "google,gs101";
compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101";
compatible = "google,gs101-pixel", "google,gs101";
I think this works (but I was aiming for something shorter,
possibly involving minItems):
compatible:
oneOf:
- description: Google GS101 Pixel base board
items:
- const: google,gs101-pixel
- const: google,gs101
- description: Google GS101 Pixel 6 (Oriole), or 6 Pro (Raven)
items:
- enum:
- google,gs101-oriole
- google,gs101-raven
- const: google,gs101-pixel
- const: google,gs101
Cheers,
Andre'
next prev parent reply other threads:[~2024-12-23 15:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 11:27 [PATCH v2 0/3] Google Pixel 6 Pro support André Draszik
2024-12-20 11:27 ` [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel André Draszik
2024-12-22 11:38 ` Krzysztof Kozlowski
2024-12-23 7:45 ` André Draszik
2024-12-23 14:14 ` Krzysztof Kozlowski
2024-12-23 15:31 ` André Draszik [this message]
2024-12-23 15:39 ` Krzysztof Kozlowski
2024-12-23 15:54 ` André Draszik
2024-12-23 15:58 ` Krzysztof Kozlowski
2024-12-20 11:27 ` [PATCH v2 2/3] arm64: dts: exynos: gs101-pixel: add generic gs101-based Pixel support André Draszik
2024-12-22 11:42 ` Krzysztof Kozlowski
2024-12-23 7:59 ` André Draszik
2024-12-23 14:18 ` Krzysztof Kozlowski
2024-12-20 11:27 ` [PATCH v2 3/3] arm64: dts: exynos: gs101-raven: add new board file André Draszik
2024-12-22 11:43 ` Krzysztof Kozlowski
2024-12-23 10:42 ` André Draszik
2024-12-20 14:42 ` [PATCH v2 0/3] Google Pixel 6 Pro support André Draszik
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=9507951f9ce4ee9d8c553d8964f00ef217f8ed1d.camel@linaro.org \
--to=andre.draszik@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel-team@android.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-samsung-soc@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=robh@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=willmcvicker@google.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;
as well as URLs for NNTP newsgroup(s).