Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 27 May 2023 16:20:37 +0800
From:   Shawn Guo <shawnguo@kernel.org>
To:     Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc:     "Peng Fan (OSS)" <peng.fan@oss.nxp.com>, s.hauer@pengutronix.de,
        kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH V3] soc: imx: support i.MX93 soc device
Message-ID: <20230527082037.GB528183@dragon>
References: <20230515063730.2042715-1-peng.fan@oss.nxp.com>
 <33d57180-aa13-4178-86e1-c4cf6ef29a6e@prevas.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <33d57180-aa13-4178-86e1-c4cf6ef29a6e@prevas.dk>
Precedence: bulk

On Wed, May 24, 2023 at 03:30:01PM +0200, Rasmus Villemoes wrote:
> On 15/05/2023 08.37, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> > 
> > i.MX93 Device Unique ID(UID) is in eFuse that could be read through
> > OCOTP Fuse Shadow Block. i.MX93 UID is 128 bits long, so introduce
> > soc_uid_high to indicate the higher 64bits.
> 
> So apparently, the imx8mp also has 128 bits, at least according to the
> reference manual, which mentions a "UNIQUE_ID[127:64]" at offset 0xe00 -
> 0xe10 (i.e. bank 40, words 0 and 1).
> 
> However, no further mention of these upper bits can be found anywhere in
> the RM, or in linux or u-boot, mainline or downstream NXP. Furthermore,
> quick experiments on both an imx8mp-evk and a custom imx8mp board
> reveals that those words are not locked down (they do seem to have some
> contents from the factory, but I can still set more bits in them).
> 
> Could someone from NXP please explain what exactly bank 40, words 0 and
> 1, on imx8mp are for? What do their initial value mean, why are they not
> locked down, and why does the RM indicate that they should be part of a
> unique_id?
> 
> Also, assuming that the RM is just wrong (wouldn't be the first time;
> the description of the lower 64 bits is also wonky in its own special
> way), an obvious follow-up question is: Are the currently exposed
> (lower) 64 bits unique among all imx8mp SOCs, i.e. does those 64 bits by
> themselves actually work as a uid?

Rasmus,

Are you fine with the patch itself?  Or do you expect more clarification
in the commit log?

Shawn