[PATCH 1/4] dt-bindings: Document additional Jetson Orin NX SKUs

[Thierry Reding]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230515/05514d15/attachment.sig>