From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"Leif Lindholm" <leif.lindholm@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Hongbo Zhang" <hongbo.zhang@linaro.org>
Subject: Re: [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
Date: Mon, 19 Nov 2018 12:24:02 -0800 [thread overview]
Message-ID: <CAKv+Gu9p05=jqCw1AWnbzxA2sjAFtXr5Ct7tmJb07J3z5SjKow@mail.gmail.com> (raw)
In-Reply-To: <627e4d10-b066-1173-bb47-6eba73b8fd0b@redhat.com>
On Mon, 19 Nov 2018 at 12:02, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 11/17/18 01:45, Ard Biesheuvel wrote:
> > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> > that are not based on the device tree received from QEMU.
> >
> > For ArmVirtQemu, this does not really matter, given that the NOR
> > flash banks are always the same: the PEI code is linked to execute
> > in place from flash bank #0, and the fixed varstore PCDs refer to
> > flash bank #1 directly.
> >
> > However, ArmVirtQemuKernel can execute at any offset, and flash bank
> > In this case, NorFlashQemuLib should not expose the first flash bank
> > at all.
> >
> > To prevent introducing too much internal knowledge about which flash
> > bank is accessible under which circumstances, let's switch to using
> > the DTB to decide which flash banks to expose to the NOR flash driver.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84 +++++++++++++++-----
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
> > 2 files changed, 75 insertions(+), 21 deletions(-)
> >
> > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > index e3bbae5b06c5..dc0a15e77170 100644
> > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > @@ -1,6 +1,6 @@
> > /** @file
> >
> > - Copyright (c) 2014, Linaro Ltd. All rights reserved.<BR>
> > + Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.<BR>
> >
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD License
> > @@ -12,13 +12,16 @@
> >
> > **/
> >
> > +#include <Library/BaseLib.h>
> > +#include <Library/DebugLib.h>
> > #include <Library/NorFlashPlatformLib.h>
> > +#include <Library/UefiBootServicesTableLib.h>
> > +
> > +#include <Protocol/FdtClient.h>
> >
> > #define QEMU_NOR_BLOCK_SIZE SIZE_256KB
> > -#define QEMU_NOR0_BASE 0x0
> > -#define QEMU_NOR0_SIZE SIZE_64MB
> > -#define QEMU_NOR1_BASE 0x04000000
> > -#define QEMU_NOR1_SIZE SIZE_64MB
> > +
> > +#define MAX_FLASH_BANKS 4
> >
> > EFI_STATUS
> > NorFlashPlatformInitialization (
> > @@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
> > return EFI_SUCCESS;
> > }
> >
> > -NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> > - {
> > - QEMU_NOR0_BASE,
> > - QEMU_NOR0_BASE,
> > - QEMU_NOR0_SIZE,
> > - QEMU_NOR_BLOCK_SIZE,
> > - {0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5, 0x3C, 0xB3}}
> > - }, {
> > - QEMU_NOR1_BASE,
> > - QEMU_NOR1_BASE,
> > - QEMU_NOR1_SIZE,
> > - QEMU_NOR_BLOCK_SIZE,
> > - {0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA, 0xCE, 0x8F}}
> > - }
> > -};
> > +NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
> >
> > EFI_STATUS
> > NorFlashPlatformGetDevices (
> > @@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
> > OUT UINT32 *Count
> > )
> > {
> > + FDT_CLIENT_PROTOCOL *FdtClient;
> > + INT32 Node;
> > + EFI_STATUS Status;
> > + EFI_STATUS FindNodeStatus;
> > + CONST UINT64 *Reg;
> > + UINT32 RegSize;
> > + CONST CHAR8 *NodeStatus;
> > + UINTN Num;
> > +
> > + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
> > + (VOID **)&FdtClient);
> > + ASSERT_EFI_ERROR (Status);
> > +
> > + Num = 0;
> > + for (FindNodeStatus = FdtClient->FindCompatibleNode (FdtClient,
> > + "cfi-flash", &Node);
> > + !EFI_ERROR (FindNodeStatus);
> > + FindNodeStatus = FdtClient->FindNextCompatibleNode (FdtClient,
> > + "cfi-flash", Node, &Node)) {
> > +
> > + Status = FdtClient->GetNodeProperty (FdtClient, Node, "status",
> > + (CONST VOID **)&NodeStatus, NULL);
> > + if (!EFI_ERROR (Status) && AsciiStrnCmp (NodeStatus, "ok", 2) != 0) {
> > + continue;
> > + }
>
> (1) Do you intend to silently continue if the "status" property is missing?
>
Yes. Absent implies 'ok'
> (2) Assuming the "status" property exists, I think we could improve the
> comparison against "ok". Can you allow GetNodeProperty() to output
> PropSize as well? And then,
>
> if (!EFI_ERROR (Status) &&
> AsciiStrnCmp (NodeStatus, "ok", PropSize) != 0) {
> continue;
> }
>
> Because, if the status property is guaranteed to be NUL-terminated, then
> we don't need AsciiStrnCmp(), we can use AsciiStrCmp() -- because both
> strings are NUL-terminated. Or else, if we want to be careful about the
> property (yes, we should be), then we should pass PropSize to
> AsciiStrnCmp(). (Or maybe PropSize-1, dependent on libfdt...)
>
> Either way it bothers me that in theory, the status property can be
> shorter than 2 chars, it may not be NUL-terminated, and we pass constant
> 2 to AsciiStrnCmp().
>
> I'm OK if we use an ASSERT() rather than an "if", in some of the above.
>
ard@mba13:~/linux-2.6$ git grep -E 'status = \"ok\"' *.dts |wc -l
239
ard@mba13:~/linux-2.6$ git grep -E 'status = \"okay\"' *.dts |wc -l
8776
IOW, we'll need to deal with both, and the spurious false positive on
'oktopus' didn't seem like a big deal to me, hence the truncated
comparison.
But indeed, we should not assume that the property value is guaranteed
to be at least 2 bytes in length. Let's be pedantic and permit 'ok'
and 'okay' only.
> > +
> > + Status = FdtClient->GetNodeProperty (FdtClient, Node, "reg",
> > + (CONST VOID **)&Reg, &RegSize);
> > + if (EFI_ERROR (Status)) {
> > + DEBUG ((EFI_D_ERROR, "%a: GetNodeProperty () failed (Status == %r)\n",
> > + __FUNCTION__, Status));
> > + continue;
> > + }
>
> (3) We should say DEBUG_ERROR in new code.
>
Copy/paste error, will fix.
> > +
> > + ASSERT ((RegSize % (2 * sizeof(UINT64))) == 0);
>
> (4) Please add a space after the sizeof operator.
>
> > +
> > + while (RegSize > 0) {
> > + mNorFlashDevices[Num].DeviceBaseAddress = (UINTN)SwapBytes64 (Reg[0]);
> > + mNorFlashDevices[Num].RegionBaseAddress = (UINTN)SwapBytes64 (Reg[0]);
> > + mNorFlashDevices[Num].Size = (UINTN)SwapBytes64 (Reg[1]);
> > + mNorFlashDevices[Num].BlockSize = QEMU_NOR_BLOCK_SIZE;
> > +
> > + Num++;
> > + Reg += 2;
> > + RegSize -= 2 * sizeof(UINT64);
>
> (5) Same as (4).
>
> > +
> > + if (Num >= MAX_FLASH_BANKS) {
> > + goto Finished;
> > + }
> > + }
> > + }
> > +
> > +Finished:
>
> (6) Can you replace the "goto" with an additional restriction, added to
> both loop's controlling expressions, namely (Num < MAX_FLASH_BANKS)?
>
> I understand the appeal of the "goto", but "Finished" is not an error
> handling label.
>
> If you disagree, I won't insist.
>
No, I'll change that - I wasn't entirely happy with it myself tbh.
> > *NorFlashDescriptions = mNorFlashDevices;
> > - *Count = ARRAY_SIZE (mNorFlashDevices);
> > + *Count = Num;
>
> (7) *Count has type UINT32; I suggest changing Num to UINT32 as well.
>
> If you disagree, I won't insist; I do realize ARRAY_SIZE() used to
> produce an UINTN as well. :/
>
No I'll change that.
> > return EFI_SUCCESS;
> > }
> > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > index 126d1671f544..d86ff36dbd58 100644
> > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > @@ -28,3 +28,15 @@
> > [Packages]
> > MdePkg/MdePkg.dec
> > ArmPlatformPkg/ArmPlatformPkg.dec
> > + ArmVirtPkg/ArmVirtPkg.dec
> > +
> > +[LibraryClasses]
> > + BaseLib
> > + DebugLib
> > + UefiBootServicesTableLib
> > +
> > +[Protocols]
> > + gFdtClientProtocolGuid ## CONSUMES
> > +
> > +[Depex]
> > + gFdtClientProtocolGuid
> >
>
> Thanks for writing these patches!
> Laszlo
prev parent reply other threads:[~2018-11-19 20:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-17 0:45 [PATCH 0/2] ArmPlatformPkg, ArmVirtPkg: discover NOR flash banks from DTB Ard Biesheuvel
2018-11-17 0:45 ` [PATCH 1/2] ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks Ard Biesheuvel
2018-11-19 19:05 ` Leif Lindholm
2018-11-19 19:09 ` Ard Biesheuvel
2018-11-19 19:23 ` Leif Lindholm
2018-11-19 19:16 ` Laszlo Ersek
2018-11-17 0:45 ` [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically Ard Biesheuvel
2018-11-17 1:29 ` Ard Biesheuvel
2018-11-19 19:10 ` Leif Lindholm
2018-11-19 19:16 ` Ard Biesheuvel
2018-11-19 19:24 ` Leif Lindholm
2018-11-19 19:27 ` Ard Biesheuvel
2018-11-19 19:31 ` Leif Lindholm
2018-11-19 20:02 ` Laszlo Ersek
2018-11-19 20:24 ` Ard Biesheuvel [this message]
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-list 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='CAKv+Gu9p05=jqCw1AWnbzxA2sjAFtXr5Ct7tmJb07J3z5SjKow@mail.gmail.com' \
--to=devel@edk2.groups.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox