From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] efi: libstub: move Graphics Output Protocol handling to generic code
Date: Fri, 18 Mar 2016 11:25:03 +0000 [thread overview]
Message-ID: <20160318112503.GP2619@codeblueprint.co.uk> (raw)
In-Reply-To: <1457588408-19309-3-git-send-email-ard.biesheuvel@linaro.org>
On Thu, 10 Mar, at 12:40:02PM, Ard Biesheuvel wrote:
> The Graphics Output Protocol code executes in the stub, so create a generic
> version based on the x86 version in libstub so that we can move all archs
> to it in subsequent patches. The new source file gop.c is added to the
> libstub build for all architectures, but is not actually included in any of
> the final images, since this patch does not wire it up yet.
>
> Note that the generic version uses slightly different ways of casting the
> protocol methods and some other variables to the correct types, since such
> method calls are not loosely typed on ARM and arm64 as they are on x86.
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/include/asm/efi.h | 4 +-
> arch/arm64/include/asm/efi.h | 4 +-
> arch/x86/boot/compressed/eboot.h | 74 ----
> arch/x86/include/asm/efi.h | 5 +
> drivers/firmware/efi/libstub/Makefile | 2 +-
> drivers/firmware/efi/libstub/gop.c | 354 ++++++++++++++++++++
> include/linux/efi.h | 87 ++++-
> 7 files changed, 451 insertions(+), 79 deletions(-)
I can totally appreciate why you did the gop code move in stages, but
I'd prefer to see the move (deletion from arch/x86 and addition to
drivers/firmware/efi) done as a single patch.
The reason is that git will produce a very nice diff stat that shows
the number of lines that were simply moved from one file to another
without modification.
Which makes it much easier to see which lines *did* change.
As a very quick and dirty example (but this is not what I'm suggesting
you do because it'd be too many changes in one patch) I merged this
patch with the next one, which produces the following diff stat. The
important point are the insertions,
: $ git show --shortstat --summary -C10% e63c02a98c3c
:
: 8 files changed, 133 insertions(+), 1606 deletions(-)
: copy arch/x86/boot/compressed/eboot.c => drivers/firmware/efi/libstub/gop.c (20%)
> diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
> index e0eea72deb87..daebcfe6c35a 100644
> --- a/arch/arm/include/asm/efi.h
> +++ b/arch/arm/include/asm/efi.h
> @@ -59,7 +59,9 @@ void efi_virtmap_unload(void);
>
> /* arch specific definitions used by the stub code */
>
> -#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
> +#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
> +#define __efi_call_early(f, ...) f(__VA_ARGS__)
> +#define efi_is_64bit() (0)
Is there a specific reason that these can't be boolean? I know some
people hate them, but I've always been a pretty big fan when the
circumstances are right. Plus it is bool on x86.
next prev parent reply other threads:[~2016-03-18 11:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 5:40 [PATCH 0/8] EFI framebuffer support for ARM and arm64 Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 1/8] efi: make install_configuration_table() boot service usable Ard Biesheuvel
2016-03-18 10:59 ` Matt Fleming
2016-03-18 11:02 ` Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 2/8] efi: libstub: move Graphics Output Protocol handling to generic code Ard Biesheuvel
2016-03-18 11:25 ` Matt Fleming [this message]
2016-03-10 5:40 ` [PATCH 3/8] efi/x86: libstub: move to generic GOP code Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 4/8] efi/x86: efifb: move DMI based quirks handling out of generic code Ard Biesheuvel
2016-03-18 10:50 ` Matt Fleming
2016-03-21 13:42 ` Peter Jones
2016-03-10 5:40 ` [PATCH 5/8] efi: efifb: use builtin_platform_driver and drop unused includes Ard Biesheuvel
2016-03-18 10:52 ` Matt Fleming
2016-03-21 13:43 ` Peter Jones
2016-03-10 5:40 ` [PATCH 6/8] efi/arm*: libstub: wire up GOP handling into the ARM UEFI stub Ard Biesheuvel
2016-03-10 8:25 ` Ingo Molnar
2016-03-10 8:36 ` Ard Biesheuvel
2016-03-10 9:03 ` Ingo Molnar
2016-03-10 9:14 ` Ard Biesheuvel
2016-03-10 9:25 ` Ingo Molnar
2016-03-10 10:25 ` Ard Biesheuvel
2016-03-10 14:49 ` Matt Fleming
2016-03-10 14:30 ` Matt Fleming
2016-03-18 11:37 ` Matt Fleming
2016-03-10 5:40 ` [PATCH 7/8] efi/arm*: efifb: expose efifb platform device if GOP is available Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 8/8] efi/arm: populate screen_info based on data provided by the UEFI stub Ard Biesheuvel
2016-03-18 11:53 ` Matt Fleming
2016-03-18 11:57 ` Ard Biesheuvel
2016-03-10 16:12 ` [PATCH 0/8] EFI framebuffer support for ARM and arm64 Mark Langsdorf
2016-03-10 16:23 ` Ard Biesheuvel
2016-03-11 17:52 ` Alexander Graf
2016-03-11 18:24 ` Ard Biesheuvel
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=20160318112503.GP2619@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).