From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] arm64: efistub: drop __init annotation from handle_kernel_image()
Date: Thu, 28 Jan 2016 22:58:10 +0000 [thread overview]
Message-ID: <20160128225809.GF2571@codeblueprint.co.uk> (raw)
In-Reply-To: <1453979254-25374-2-git-send-email-ard.biesheuvel@linaro.org>
On Thu, 28 Jan, at 12:07:32PM, Ard Biesheuvel wrote:
> After moving arm64-stub.c to libstub/, all of its sections are emitted
> as .init.xxx sections automatically, and the __init annotation of
> handle_kernel_image() causes it to end up in .init.init.text, which is
> not recognized as an __init section by the linker scripts. So drop the
> annotation.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/firmware/efi/libstub/arm64-stub.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
> index 78dfbd34b6bf..9e0342745e4f 100644
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@ -13,13 +13,13 @@
> #include <asm/efi.h>
> #include <asm/sections.h>
>
> -efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
> - unsigned long *image_addr,
> - unsigned long *image_size,
> - unsigned long *reserve_addr,
> - unsigned long *reserve_size,
> - unsigned long dram_base,
> - efi_loaded_image_t *image)
> +efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
> + unsigned long *image_addr,
> + unsigned long *image_size,
> + unsigned long *reserve_addr,
> + unsigned long *reserve_size,
> + unsigned long dram_base,
> + efi_loaded_image_t *image)
> {
> efi_status_t status;
> unsigned long kernel_size, kernel_memsize = 0;
> --
> 2.5.0
>
Would it make more sense to #undef __init in one of the arm64 efistub
header files? I'm thinking of the case where some poor unsuspecting
developer writes a new function and marks it as __init, and we miss it
during review.
At least if we do the #undef we can document why __init makes no sense
in the EFI stub, and at the same time automatically fix things up.
An alternative would be to write some Kbuild magic that complains if
it sees __init, but that seems like more work than is reasonable.
next prev parent reply other threads:[~2016-01-28 22:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 11:07 [PATCH 0/3] arm efi minor fixes Ard Biesheuvel
2016-01-28 11:07 ` [PATCH 1/3] arm64: efistub: drop __init annotation from handle_kernel_image() Ard Biesheuvel
2016-01-28 15:56 ` Will Deacon
2016-01-28 22:58 ` Matt Fleming [this message]
2016-01-29 9:36 ` Ard Biesheuvel
2016-01-29 16:00 ` Matt Fleming
2016-01-29 16:03 ` Ard Biesheuvel
2016-02-02 11:08 ` Matt Fleming
2016-02-02 11:09 ` Ard Biesheuvel
2016-02-03 15:19 ` Matt Fleming
2016-02-03 15:21 ` Ard Biesheuvel
2016-01-28 11:07 ` [PATCH 2/3] arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections Ard Biesheuvel
2016-01-28 15:57 ` Will Deacon
2016-01-28 22:59 ` Matt Fleming
2016-01-28 11:07 ` [PATCH 3/3] efi: arm-init: use read-only early mappings Ard Biesheuvel
2016-01-28 15:53 ` [PATCH 0/3] arm efi minor fixes Mark Rutland
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=20160128225809.GF2571@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).