From: Thierry Reding <thierry.reding@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Jon Hunter <jonathanh@nvidia.com>,
devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] dt-bindings: Document additional Jetson Orin NX SKUs
Date: Mon, 15 May 2023 17:06:44 +0200 [thread overview]
Message-ID: <ZGJKhGm-UAN88LN5@orome> (raw)
In-Reply-To: <4129f3d5-1df8-a767-6783-1d7123b2e9d4@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 2184 bytes --]
On Fri, Apr 07, 2023 at 10:52:58AM +0200, Krzysztof Kozlowski wrote:
> On 04/04/2023 12:49, Thierry Reding wrote:
> > On Fri, Mar 31, 2023 at 10:19:00PM +0200, Krzysztof Kozlowski wrote:
> >> On 31/03/2023 18:31, Thierry Reding wrote:
> >>> From: Thierry Reding <treding@nvidia.com>
> >>>
> >>> Beyond the original 16 GiB SKU (0), additional SKUs exist, such as the 8
> >>> GiB SKU (1) and an internal-only SKU (2) that comes with an equipeed SD
> >>
> >> typo: equipped
> >>
> >>> card slot.
> >>
> >> Is there a point in documenting all of them if there is no DTS? Also,
> >> size of storage (eMMC?) pretty often is runtime-detectable, so you do no
> >> need a new DTS and new compatible.
> >
> > This is for the sake of completeness since these compatible strings
> > correspond to the part numbers that will show up on stickers on these
> > modules. In practice, yes, most of the differences will be runtime-
> > detected and the DT updated to reflect the SKU differences by UEFI.
>
> Just because there is some sticker, it does not mean we need a
> compatible. We actually omit dozen of versions per device - all PMICs,
> I2C IIO and others have some packaging bins and revision numbers.
>
> Although here if I understand correctly, UEFI firmware will add these
> compatibles?
That's the idea. UEFI does some probing of the hardware and currently
writes information about the detected SKUs into the /chosen node. I
think we could achieve the same effect in a more standard way by writing
out the compatible strings instead.
So while we likely won't have these compatible strings in the DTS files,
we may very well end up having these in the DTB that is passed to the
kernel. So we don't need these to be documented for validation within
the kernel repository, but I'm concerned it could lead to confusion if
people end up with undocumented compatible strings in the DTB.
Perhaps that's not as big a deal as I think it is, so I'll drop this for
now. We'll go with the "standard" SKU compatible strings for now and can
revisit if this becomes an actual problem.
Sorry for the delay, I hadn't seen your replies before.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2023-05-15 16:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 16:31 [PATCH 1/4] dt-bindings: Document additional Jetson Orin NX SKUs Thierry Reding
2023-03-31 16:31 ` [PATCH 2/4] dt-bindings: tegra: Document Jetson Orin Nano Thierry Reding
2023-03-31 20:20 ` Krzysztof Kozlowski
2023-04-04 10:59 ` Thierry Reding
2023-04-07 8:59 ` Krzysztof Kozlowski
2023-04-04 11:03 ` Thierry Reding
2023-03-31 16:31 ` [PATCH 3/4] dt-bindings: tegra: Document Jetson Orin Nano Developer Kit Thierry Reding
2023-03-31 16:31 ` [PATCH 4/4] arm64: tegra: Support " Thierry Reding
2023-03-31 20:19 ` [PATCH 1/4] dt-bindings: Document additional Jetson Orin NX SKUs Krzysztof Kozlowski
2023-04-04 10:49 ` Thierry Reding
2023-04-07 8:52 ` Krzysztof Kozlowski
2023-05-15 15:06 ` Thierry Reding [this message]
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=ZGJKhGm-UAN88LN5@orome \
--to=thierry.reding@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh+dt@kernel.org \
/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).