Received-SPF: pass (google.com: domain of linux-kernel+bounces-119203-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Tue, 26 Mar 2024 15:43:55 +0100
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Landge, Sudan" <sudanl@amazon.co.uk>
Cc: Rob Herring <robh@kernel.org>, Sudan Landge <sudanl@amazon.com>,
	tytso@mit.edu, krzysztof.kozlowski+dt@linaro.org,
	conor+dt@kernel.org, sathyanarayanan.kuppuswamy@linux.intel.com,
	thomas.lendacky@amd.com, dan.j.williams@intel.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	graf@amazon.de, dwmw@amazon.co.uk, bchalios@amazon.es,
	xmarcalx@amazon.co.uk
Subject: Re: [PATCH v2 3/4] dt-bindings: rng: Add vmgenid support
Message-ID: <ZgLfKwp6cSrX7knJ@zx2c4.com>
References: <20240321025105.53210-1-sudanl@amazon.com>
 <20240321025105.53210-4-sudanl@amazon.com>
 <20240325150609.GA3477574-robh@kernel.org>
 <51403072-f5ca-450e-9206-19ca627ead11@amazon.co.uk>
 <CAL_JsqKpp+J2a_+wmcaOX8RfTEEyZBESWBX7GWGa_u_5_=4gsg@mail.gmail.com>
 <96df7e5a-52df-4171-9cd6-78d088a7a1e2@amazon.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <96df7e5a-52df-4171-9cd6-78d088a7a1e2@amazon.co.uk>

On Tue, Mar 26, 2024 at 01:06:16PM +0000, Landge, Sudan wrote:
> >>> Does the spec say anything about endianness or access size? DT assumes
> >>> native endianness by default. We have properties to deal these, but
> >>> would be better to be explicit if that's defined already.
> >>>
> >> The spec doesn't mention anything about the endianness but, I have
> >> updated the description with some more data.
> > 
> > Then what does your driver assume? Microsoft may not have thought
> > about it because they don't care, but now you want to use DT so you
> > have to because it is frequently used on BE systems. If we define
> > something, then there's some hope. Otherwise, it's pretty much a
> > guarantee folks will do the opposite.
> > 
> > Rob
> The driver does not assume any endianness. To provide more context, The 
> hypervisor stores a 128bit unique ID at the address pointed by the 
> "reg"'s 1st cell, driver memcpy's this ID to an internal context and 
> uses memcmp to compare if the ID is new or old.
> But yes, it will be good to define a fixed endianness to avoid any 
> error. I will update the description to use little endian.

It's a 16-byte blob. Why care about endianness at all here? Treat it as
a byte string, not an integer.

Jason