[PATCH v5 3/3] arm: dts: am335x-sancloud-bbe-lite: UEFI SPI export

[Rob Herring]

On Wed, Nov 23, 2022 at 05:50:06PM +0000, Paul Barker wrote:
> Add properties to the Authenta SPI flash device node to enable access by
> a UEFI application using a fixed GUID.
> 
> Signed-off-by: Paul Barker <paul.barker at sancloud.com>
> ---
>  arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi | 13 ++++++++++---
>  arch/arm/dts/am335x-sancloud-bbe-lite.dts         |  2 +-
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi b/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi
> index 01c105ebb383..6c4ff67f9a4b 100644
> --- a/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi
> +++ b/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi
> @@ -38,7 +38,14 @@
>  
>  &spi0 {
>  	u-boot,dm-pre-reloc;
> -	channel at 0 {
> -		u-boot,dm-pre-reloc;
> -	};
> +};
> +
> +&authenta_flash {
> +	u-boot,dm-pre-reloc;
> +
> +	u-boot,uefi-spi-vendor = "micron";
> +	u-boot,uefi-spi-part-number = "mt25ql128abb";

Looks like a compatible string. Yet, the flash node compatible string, 
micron,spi-authenta, is not documented (though in use for spidev). So 
use a compatible string for the flash that is specific to the flash 
model. I assume there is some reason the specific model is needed?

> +	/* GUID in UEFI format: 77126730-a4ca-4386-b341-881fe18e7f7d */
> +	u-boot,uefi-spi-io-guid = [30 67 12 77 ca a4 86 43
> +				   b3 41 88 1f e1 8e 7f 7d];

We need to define first in the DT spec the format for GUIDs. I don't 
think there are any existing cases though some have been proposed. IMO, 
I would make this a string instead. The byte array is not that 
readable with its little endian order. A GUID as a string is readily 
identifiable as a GUID.

Why is this u-boot specific? Another UEFI implementation doesn't need 
the GUID?

Rob