[PATCH V4 1/2] soc: imx: Correct i.MX8MP soc device

[Rasmus Villemoes]

On 29/05/2023 05.37, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> i.MX8MP UID is actually 128bits and partitioned into two parts, with 1st
> 64bits at 0x410 and 0x420, with 2nd 64bits at 0xE00 and 0xE10.
> 
> So introduce soc_uid_h for the higher 64bits

Interestingly, reaching out to our NXP sales rep asking for
clarification resulted in:

  On i.MX 8MP Unique ID is 64 bits. Please see here:


https://github.com/nxp-imx/uboot-imx/blob/lf_v2022.04/arch/arm/mach-imx/imx8m/soc.c#L752

So could you guys (and here I'm referring to everybody with an @nxp.com
email) internally _please_ talk to each other and figure out what's what.

And, again assuming that the UID is really 128 bits, nobody has yet
answered why the upper 64 bits are not locked down, nor what would/could
happen if the end user/customer modifies those bits.

> Fixes: 18f662a73862 ("soc: imx: Add i.MX8MP SoC driver support")
> Reported-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>

That's true.

> Closes: https://lore.kernel.org/all/fe5e2b36-6a8e-656c-a4a6-13a47f4871af@prevas.dk/

Not at all. We (anybody outside nxp.com, and from what I can tell,
probably quite a few people inside) still lack a complete explanation
for this whole mess - why does the RM say one thing, which gets repeated
by NXP TechSupport in a community forum, while a sales representative
asserts that the current code (in both mainline and downstream linux and
u-boot) is correct, and now you claim that in fact the current code is
not correct.

Rasmus