From: "Leif Lindholm" <leif.lindholm@linaro.org>
To: Michael Brown <mbrown@fensystems.co.uk>
Cc: devel@edk2.groups.io, ard.biesheuvel@linaro.org, pete@akeo.ie
Subject: Re: [edk2-platforms: PATCHv2 1/1] Platform/RPi3: Provide "ethernet[0]" aliases in device tree
Date: Wed, 24 Jul 2019 19:53:43 +0100 [thread overview]
Message-ID: <20190724185343.GX11541@bivouac.eciton.net> (raw)
In-Reply-To: <20190724143114.468304-2-mbrown@fensystems.co.uk>
Hi Michael,
Thanks for this.
One comment below.
On Wed, Jul 24, 2019 at 03:31:14PM +0100, Michael Brown wrote:
> Older device trees tend to use the alias "ethernet". Newer device
> trees tend to use "ethernet0" since older versions of U-Boot would
> skip aliases that do not include an index number. See, for example,
> Linux kernel commit 10b6c0c ("ARM: dts: bcm2835: add index to the
> ethernet alias") and U-Boot commit f8e57c6 ("fdt_support: Fixup
> 'ethernet' aliases not ending in digits").
>
> Ensure that both "ethernet" and "ethernet0" aliases are present within
> the device tree, to provide compatibility with operating systems that
> expect either alias, and with device trees that contain either (or
> both) aliases.
>
> Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
> ---
> .../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 64 +++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
> diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> index 83446e3e45..57e4bee8da 100644
> --- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> +++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> @@ -23,6 +23,69 @@ STATIC VOID *mFdtImage;
>
> STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
>
> +STATIC
> +VOID
> +FixEthernetAliases (
> + VOID
> +)
> +{
> + INTN Aliases;
> + CONST CHAR8 *Ethernet;
> + CONST CHAR8 *Ethernet0;
> + CONST CHAR8 *Alias;
> + UINTN CopySize;
> + CHAR8 *Copy;
> + INTN Retval;
> +
> + //
> + // Look up the 'ethernet[0]' aliases
> + //
> + Aliases = fdt_path_offset (mFdtImage, "/aliases");
> + if (Aliases < 0) {
> + DEBUG ((DEBUG_ERROR, "%a: failed to locate '/aliases'\n", __FUNCTION__));
The DEBUG statements are only included in DEBUG builds.
And I think that's fine for these very detailed ones, but...
> + return;
> + }
> + Ethernet = fdt_getprop (mFdtImage, Aliases, "ethernet", NULL);
> + Ethernet0 = fdt_getprop (mFdtImage, Aliases, "ethernet0", NULL);
> + Alias = Ethernet ? Ethernet : Ethernet0;
> + if (!Alias) {
> + DEBUG ((DEBUG_ERROR, "%a: failed to locate 'ethernet[0]' alias\n", __FUNCTION__));
> + return;
> + }
> +
> + //
> + // Create copy for fdt_setprop
> + //
> + CopySize = AsciiStrSize (Alias);
> + Copy = AllocateCopyPool (CopySize, Alias);
> + if (!Copy) {
> + DEBUG ((DEBUG_ERROR, "%a: failed to copy '%a'\n", __FUNCTION__, Alias));
> + return;
> + }
> +
> + //
> + // Create missing aliases
> + //
> + if (!Ethernet) {
> + Retval = fdt_setprop (mFdtImage, Aliases, "ethernet", Copy, CopySize);
> + if (Retval != 0) {
> + DEBUG ((DEBUG_ERROR, "%a: failed to create 'ethernet' alias (%d)\n",
> + __FUNCTION__, Retval));
> + }
> + DEBUG ((DEBUG_INFO, "%a: created 'ethernet' alias '%a'\n", __FUNCTION__, Copy));
> + }
> + if (!Ethernet0) {
> + Retval = fdt_setprop (mFdtImage, Aliases, "ethernet0", Copy, CopySize);
> + if (Retval != 0) {
> + DEBUG ((DEBUG_ERROR, "%a: failed to create 'ethernet0' alias (%d)\n",
> + __FUNCTION__, Retval));
> + }
> + DEBUG ((DEBUG_INFO, "%a: created 'ethernet0' alias '%a'\n", __FUNCTION__, Copy));
> + }
> +
> + FreePool (Copy);
> +}
> +
> STATIC
> VOID
> UpdateMacAddress (
> @@ -342,6 +405,7 @@ FdtDxeInitialize (
> SanitizePSCI ();
> CleanMemoryNodes ();
> CleanSimpleFramebuffer ();
> + FixEthernetAliases ();
...would it be worth having a return value here and Print()ing a
message visible regardless of build profile if this function fails?
/
Leif
> UpdateMacAddress ();
> if (Internal) {
> /*
> --
> 2.21.0
>
next prev parent reply other threads:[~2019-07-24 18:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 17:29 [edk2-platforms: PATCH 0/1] Handle RPi device trees using "ethernet0" Michael Brown
2019-07-19 17:29 ` [edk2-platforms: PATCH 1/1] Platform/RPi3: Accept "ethernet" or "ethernet0" aliases in device tree Michael Brown
2019-07-23 10:34 ` Leif Lindholm
2019-07-23 11:00 ` Michael Brown
2019-07-23 11:17 ` Leif Lindholm
2019-07-24 14:31 ` [edk2-platforms: PATCHv2 0/1] Platform/RPi3: Provide "ethernet[0]" " Michael Brown
2019-07-24 14:31 ` [edk2-platforms: PATCHv2 1/1] " Michael Brown
2019-07-24 18:53 ` Leif Lindholm [this message]
2019-07-24 20:53 ` [edk2-devel] " Michael Brown
2019-07-24 21:43 ` Leif Lindholm
2019-07-25 10:27 ` [edk2-platforms: PATCH 0/1] Report device tree modification errors using Print() Michael Brown
2019-07-25 10:27 ` [edk2-platforms: PATCH 1/1] Platform/RPi3: " Michael Brown
2019-08-06 17:07 ` Leif Lindholm
2019-08-08 23:16 ` [edk2-platforms: PATCH v2 0/1] Platform/RPi3: Report device tree Michael Brown
2019-08-09 10:07 ` Leif Lindholm
2019-08-08 23:16 ` [edk2-platforms: PATCH v2 1/1] Platform/RPi3: Report device tree modification errors using Print() Michael Brown
2019-07-25 12:51 ` [edk2-devel] [edk2-platforms: PATCHv2 1/1] Platform/RPi3: Provide "ethernet[0]" aliases in device tree Leif Lindholm
2019-07-23 11:19 ` [edk2-platforms: PATCH 1/1] Platform/RPi3: Accept "ethernet" or "ethernet0" " Pete Batard
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=20190724185343.GX11541@bivouac.eciton.net \
--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