From: Tom Rini <trini@konsulko.com>
To: Paul Barker <paul.barker@sancloud.com>
Cc: Rob Herring <robh@kernel.org>,
u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Jagan Teki <jagan@amarulasolutions.com>
Subject: Re: [PATCH v5 3/3] arm: dts: am335x-sancloud-bbe-lite: UEFI SPI export
Date: Sat, 24 Dec 2022 11:51:26 -0500 [thread overview]
Message-ID: <20221224165126.GJ3787616@bill-the-cat> (raw)
In-Reply-To: <bb2d161b-7fbb-4e18-29fc-4fca5c3ae9a6@sancloud.com>
[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]
On Sat, Dec 24, 2022 at 12:03:52PM +0000, Paul Barker wrote:
> On 20/12/2022 15:55, Rob Herring wrote:
> > 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@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@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?
>
> For context, the UEFI Platform Initialization (PI) spec defines
> EFI_SPI_PART, EFI_SPI_PERIPHERAL and EFI_SPI_IO_PROTOCOL structures.
> I'm referencing v1.7 Errata A. See https://uefi.org/specifications for
> downloads.
>
> The EFI_SPI_PART structure has "Vendor" and "PartNumber" fields. We need
> something to put in those fields and the device tree is the best place
> to store the data. These properties are in the `-u-boot.dtsi` file so
> they won't be submitted to the Linux kernel.
Well, IMHO, this doesn't belong in U-Boot only for forever. Just like
other bindings/properties that we're working on getting merged upstream
and so that there is really Just One Device Tree, this should go
upstream I believe. This might be another case of starts in -u-boot.dtsi
while things get sorted out.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2022-12-24 16:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 17:50 [PATCH v5 0/3] Support UEFI SPI I/O protocol Paul Barker
2022-11-23 17:50 ` [PATCH v5 1/3] efi_loader: Add SPI I/O protocol support Paul Barker
2022-12-13 7:15 ` Ilias Apalodimas
2022-12-24 12:25 ` Paul Barker
2022-12-24 14:09 ` Heinrich Schuchardt
2023-01-11 13:02 ` Paul Barker
2022-12-14 4:39 ` Simon Glass
2022-12-14 9:57 ` Paul Barker
2022-12-15 14:24 ` Simon Glass
2022-11-23 17:50 ` [PATCH v5 2/3] efi_selftest: Add tests for SPI " Paul Barker
2022-12-15 14:24 ` Simon Glass
2022-11-23 17:50 ` [PATCH v5 3/3] arm: dts: am335x-sancloud-bbe-lite: UEFI SPI export Paul Barker
2022-12-20 15:55 ` Rob Herring
2022-12-24 12:03 ` Paul Barker
2022-12-24 16:51 ` Tom Rini [this message]
2023-01-03 19:27 ` Rob Herring
2023-01-11 12:19 ` Paul Barker
2022-12-12 9:29 ` [PATCH v5 0/3] Support UEFI SPI I/O protocol Paul Barker
2022-12-12 9:41 ` Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221224165126.GJ3787616@bill-the-cat \
--to=trini@konsulko.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jagan@amarulasolutions.com \
--cc=paul.barker@sancloud.com \
--cc=robh@kernel.org \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.