On Tue, Jul 30, 2019 at 05:23:48PM -0400, Qian Cai wrote:
> GCC throws out this warning on arm64.
>
> drivers/firmware/efi/libstub/arm-stub.c: In function 'efi_entry':
> drivers/firmware/efi/libstub/arm-stub.c:132:22: warning: variable 'si'
> set but not used [-Wunused-but-set-variable]
>
> Fix i
On Mon, Feb 04, 2019 at 04:01:01PM -0500, Qian Cai wrote:
> The commit e2a2e56e4082 ("arm64: dump: no need to check return value of
> debugfs_create functions") converted ptdump_debugfs_register() from
> void, but forgot to fix the efi version of ptdump_init().
>
> drivers/firmware/efi/arm-runtime
= kmalloc(sizeof(*rsv), GFP_ATOMIC);
>
> Kmemleak has a known limitation that can only track pointers in the kernel
> virtual space. Hence, it will report false positives due to "rsv" will only
> reference to other physical addresses,
>
> rsv->next = efi_memreserve_root->next;
> efi_memreserve_root->next = __pa(rsv);
>
> Signed-off-by: Qian Cai
Acked-by: Catalin Marinas
On Wed, Nov 07, 2018 at 03:16:06PM +0100, Ard Biesheuvel wrote:
> Bhupesh reports that having numerous memblock reservations at early
> boot may result in the following crash:
>
> Unable to handle kernel paging request at virtual address 80003ffe
> ...
> Call trace:
>__memcpy+0x1
TASK_SIZE on ARM, both of which
> are compile time constants. Also, change the 'headroom' variable to
> static const to force an error if this changes in the future.
>
> Cc: James Morse
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: Matt Fleming
> Cc: Ingo
Hi Ard,
On 4 April 2017 at 17:09, Ard Biesheuvel wrote:
> Update the allocation logic for the virtual mapping of the UEFI runtime
> services to start from a randomized base address if KASLR is in effect,
> and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.
>
> This makes it m
Hi Rafael,
On Tue, Mar 28, 2017 at 01:30:30PM -0600, Tyler Baicar wrote:
> Tyler Baicar (9):
> acpi: apei: read ack upon ghes record consumption
> ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
> efi: parse ARM processor error
> arm64: exception: handle Synchronous External
c.h | 2 ++
> arch/arm64/mm/fault.c| 19 +++--
> drivers/acpi/apei/ghes.c | 13 ++--
> include/acpi/ghes.h | 2 +-
> 8 files changed, 86 insertions(+), 16 deletions(-)
For arm64:
Acked-by: Catalin Marinas
Marc, Christof
ch/arm64/Kconfig| 2 ++
> arch/arm64/mm/fault.c | 13 +
> drivers/acpi/apei/Kconfig | 15 ++
> drivers/acpi/apei/ghes.c | 70
> +++
> include/acpi/ghes.h | 7 +
> 5 files changed, 101 insertio
/asm/esr.h | 1 +
> arch/arm64/mm/fault.c| 43 +++++++++--
Acked-by: Catalin Marinas
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 16, 2015 at 10:43:52AM +, Will Deacon wrote:
> On Tue, Sep 29, 2015 at 08:38:57AM +0100, Ard Biesheuvel wrote:
> > On 22 September 2015 at 02:21, Ard Biesheuvel
> > wrote:
> > > This is a followup to the "arm64: update/clarify/relax Image and FDT
> > > placement
> > > rules" seri
On Fri, Oct 30, 2015 at 01:17:24PM +0100, Ard Biesheuvel wrote:
> On 27 October 2015 at 23:44, Jeremy Linton wrote:
> > On 10/26/2015 09:20 PM, Ard Biesheuvel wrote:
> >>
> >> Thanks for the report. The following patch should fix it
> >
> >
> > Ard,
> >
> > Thanks, it does fix the build problem...
On Fri, Oct 30, 2015 at 12:57:48PM +0100, Ard Biesheuvel wrote:
> On 29 October 2015 at 19:39, Catalin Marinas wrote:
> > On Fri, Oct 23, 2015 at 04:48:14PM +0200, Ard Biesheuvel wrote:
> >> Now that we added special handling to the C files in libstub, move
> >> the o
On Fri, Oct 23, 2015 at 04:48:14PM +0200, Ard Biesheuvel wrote:
> Now that we added special handling to the C files in libstub, move
> the one remaining arm64 specific EFI stub C file to libstub as
> well, so that it gets the same treatment. This should prevent future
> changes from resulting in bi
On Sat, Oct 10, 2015 at 11:40:51PM +0100, Matt Fleming wrote:
> On Thu, 08 Oct, at 08:02:01PM, Ard Biesheuvel wrote:
> > We need to ensure that the EFI stub only uses parts of the kernel proper
> > that are safe to use when the kernel virtual mapping is not active yet.
> >
> > So move all C code d
On Tue, Oct 06, 2015 at 12:03:41PM +0100, Ard Biesheuvel wrote:
> We need to ensure that the EFI stub only uses parts of the kernel proper
> that are safe to use when the kernel virtual mapping is not active yet.
>
> So move all C code dependencies to the libstub, and do a verification pass
> to e
On Thu, Oct 08, 2015 at 02:09:26PM +0200, Ard Biesheuvel wrote:
> On 8 October 2015 at 13:23, Andrey Ryabinin wrote:
> > On 10/08/2015 02:11 PM, Mark Rutland wrote:
> >> On Thu, Oct 08, 2015 at 01:36:09PM +0300, Andrey Ryabinin wrote:
> >>> 2015-10-07 13:04 GMT+03:
On Sun, Jul 26, 2015 at 02:59:00PM +0200, Ard Biesheuvel wrote:
> At boot, the UTF-16 UEFI vendor string is copied from the system
> table into a char array with a size of 100 bytes. However, this
> size of 100 bytes is also used for memremapping() the source,
> which may not be sufficient if the v
gt; Acked-by: Mark Rutland
> Signed-off-by: Ard Biesheuvel
For the arm64 part:
Acked-by: Catalin Marinas
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 10, 2015 at 02:48:57PM +, Matt Fleming wrote:
> On Fri, 06 Mar, at 03:49:24PM, Ard Biesheuvel wrote:
> > If UEFI Runtime Services are available, they are preferred over direct
> > PSCI calls or other methods to reset the system.
> >
> > For the reset case, we need to hook into mach
On Thu, Jan 22, 2015 at 05:37:58PM +, Ard Biesheuvel wrote:
> On 22 January 2015 at 15:59, Catalin Marinas wrote:
> > On Thu, Jan 22, 2015 at 10:01:40AM +, Ard Biesheuvel wrote:
> >> Now that the create_mapping() code in mm/mmu.c is able to support
> >> setti
On Thu, Jan 22, 2015 at 10:01:40AM +, Ard Biesheuvel wrote:
> Now that the create_mapping() code in mm/mmu.c is able to support
> setting up kernel page tables at initcall time, we can move the whole
> virtmap creation to arm64_enable_runtime_services() instead of having
> a distinct stage duri
On Thu, Jan 15, 2015 at 04:40:11PM +, Mark Rutland wrote:
> On Thu, Jan 15, 2015 at 12:01:06PM +, Ard Biesheuvel wrote:
> > When remapping the UEFI memory map using ioremap_cache(), we
> > have to deal with potential failure. Note that, even if the
> > common case is for ioremap_cache() to
f FileAlignment.
>
> Signed-off-by: Ard Biesheuvel
> ---
>
> Another one from the PE/COFF rabbit hole. I will follow up next week and
> repost
> as a coherent series, once I have collected all the feedback.
If Matt is taking more patches in this series, here's
On Tue, Oct 07, 2014 at 06:28:34AM +0100, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Guenter Roeck
> ---
> arch/arm64/kernel/psci.c | 2 +-
>
On Tue, Oct 07, 2014 at 09:00:48AM +0100, Lee Jones wrote:
> On Mon, 06 Oct 2014, Guenter Roeck wrote:
> > --- a/drivers/mfd/ab8500-sysctrl.c
> > +++ b/drivers/mfd/ab8500-sysctrl.c
> > @@ -6,6 +6,7 @@
>
> [...]
>
> > +static int ab8500_power_off(struct notifier_block *this, unsigned long
> > unu
implementation is broken (providing
> > a dodgy memory map).
> >
> > So before people start doing dodgy things, let's, close that hole. If we
> > need a way of modifying the memory map we should come up with a more
> > general plan.
>
> Catalin - any
Currently, fdt_find_uefi_params() reports an error if no EFI parameters
are found in the DT. This is however a valid case for non-UEFI kernel
booting. This patch checks changes the error reporting to a
pr_info("UEFI not found") when no EFI parameters are found in the DT.
Signed-off-b
I forgot about this thread. I think we need it sorted in some way.
On Fri, May 23, 2014 at 04:03:31PM +0100, Leif Lindholm wrote:
> On Fri, May 23, 2014 at 02:47:20PM +0100, Catalin Marinas wrote:
> > Can we add another of detecting whether it's an EFI application and
> > av
On 4 Jul 2014, at 18:19, Ard Biesheuvel wrote:
> On 4 July 2014 19:01, Catalin Marinas wrote:
>> On Fri, Jul 04, 2014 at 05:52:36PM +0100, Mark Salter wrote:
>>> On Fri, 2014-07-04 at 17:25 +0200, Ard Biesheuvel wrote:
>>>> If we cannot resolve the virtual address
is patch or Matt already has other EFI patches to
push? If the latter:
Acked-by: Catalin Marinas
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote:
> On 4 July 2014 17:45, Catalin Marinas wrote:
> > On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
> >> According to the UEFI spec section 2.3.6.4, the use of FP/SIMD
> >> instructions
On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
> According to the UEFI spec section 2.3.6.4, the use of FP/SIMD instructions is
> allowed, and should adhere to the AAPCS64 calling convention, which states
> that
> 'only the bottom 64 bits of each value stored in registers v8-v15 n
On Fri, Jul 04, 2014 at 02:54:19PM +0100, Ard Biesheuvel wrote:
> On 4 July 2014 15:38, Catalin Marinas wrote:
> > On Wed, Jul 02, 2014 at 11:10:01AM +0100, Ard Biesheuvel wrote:
> >> We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL,
> >> but
>
On Wed, Jul 02, 2014 at 11:10:01AM +0100, Ard Biesheuvel wrote:
> We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but
> then go on an dereference it anyway.
>
> Signed-off-by: Ard Biesheuvel
Thanks. I applied this one (the other patch needs to go in via a
different route
On Fri, Jun 20, 2014 at 10:00:08AM +0100, Matt Fleming wrote:
> Please pull the following compiler warning fix. Sorry, I've been pretty
> slow in getting this pull request sent. Multiple people have reported
> hitting it and I've now received 4 patches for the same warning,
BTW, one of them is not
‘of_get_flat_dt_prop’ from incompatible pointer type [enabled by default]
drivers/firmware/efi/efi.c|368 col 8| warning: assignment discards ‘const’
qualifier from pointer target type [enabled by default]
Signed-off-by: Catalin Marinas
---
Matt,
Unless you have fixed these already, please consider
b/arch/arm64/kernel/efi.c
> @@ -333,6 +333,9 @@ void __init efi_init(void)
>
> void __init efi_idmap_init(void)
> {
> + if (!efi_enabled(EFI_BOOT))
> + return;
> +
That's a first (possibly temporary) step and I think it's fine:
Acked-by: Cat
Hi,
As the EFI_STUB for arm64 got into tip and soon into -next, I thought
about giving it a try (tip/arm64/efi). Using my boot-wrapper (non-EFI)
is still supposed to work but I get the trace below. It looks like
memmap.map is NULL but the code still assumes the kernel was started as
an EFI app.
H
On Mon, May 19, 2014 at 11:50:42AM +0100, Matt Fleming wrote:
> On Wed, 30 Apr, at 09:03:32PM, Matt Fleming wrote:
> > I pulled the arm64 EFI changes into the following topic branch. Catalin
> > was happy for this to go through tip, which definitely makes things
> > easier for the next merge window
On Tue, Apr 29, 2014 at 03:47:13PM +0100, Matt Fleming wrote:
> On Tue, 29 Apr, at 02:47:28PM, Catalin Marinas wrote:
> > Given that Leif's series contains both generic efi and arm64 patches,
> > what's your preference for merging them? I'm happy to add my ack and
>
On Tue, Apr 29, 2014 at 12:43:56PM +0100, Matt Fleming wrote:
> (Pulling in Peter and Stephen)
>
> On Tue, 29 Apr, at 11:28:17AM, Catalin Marinas wrote:
> >
> > The patches look fine to me, they've been through several rounds of
> > review already. How do we
On Fri, Apr 25, 2014 at 05:09:04PM +0100, Leif Lindholm wrote:
> This set adds support for UEFI to the arm64 port - a stub loader, as
> well as runtime services support for efivars.
>
> It depends on some core EFI patches currently in linux-next.
The patches look fine to me, they've been through
On Wed, Mar 19, 2014 at 03:13:18PM +, Mark Salter wrote:
> On Wed, 2014-03-19 at 10:57 +0000, Catalin Marinas wrote:
> > On Tue, Mar 18, 2014 at 09:40:31PM +, Mark Salter wrote:
> > > On Tue, 2014-03-18 at 18:28 +0000, Catalin Marinas wrote:
> > > > If UEFI
On Tue, Mar 18, 2014 at 09:40:31PM +, Mark Salter wrote:
> On Tue, 2014-03-18 at 18:28 +0000, Catalin Marinas wrote:
> > If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
> > flush by MVA. We don't need to flush the whole DRAM (and I would even
On Tue, Mar 18, 2014 at 10:21:05PM +, Jason Gunthorpe wrote:
> On Tue, Mar 18, 2014 at 02:48:30PM -0700, Roy Franz wrote:
>
> > > It isn't clear to me if UEFI does cache flushing at ExitBootServices
> > > time, but even so, at least stack use will get cached between then and
> > > the kernel e
On Tue, Mar 18, 2014 at 02:40:29PM +, Mark Salter wrote:
> On Tue, 2014-03-18 at 12:09 +0000, Catalin Marinas wrote:
> > On Thu, Mar 13, 2014 at 10:47:04PM +, Leif Lindholm wrote:
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/efi-entry.S
> > > @@ -
On Tue, Mar 18, 2014 at 02:16:49PM +, Mark Salter wrote:
> On Tue, 2014-03-18 at 12:34 +0000, Catalin Marinas wrote:
> > On Thu, Mar 13, 2014 at 10:47:06PM +, Leif Lindholm wrote:
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/efi.c
> > [...]
> >
On Thu, Mar 13, 2014 at 10:47:06PM +, Leif Lindholm wrote:
> --- /dev/null
> +++ b/arch/arm64/kernel/efi.c
[...]
> +/*
> + * Called from setup_arch with interrupts disabled.
> + */
> +void __init efi_enter_virtual_mode(void)
[...]
> --- a/init/main.c
> +++ b/init/main.c
> @@ -902,6 +902,10 @@ s
On Thu, Mar 13, 2014 at 10:47:04PM +, Leif Lindholm wrote:
> --- /dev/null
> +++ b/arch/arm64/kernel/efi-entry.S
> @@ -0,0 +1,93 @@
> +/*
> + * EFI entry point.
> + *
> + * Copyright (C) 2013 Red Hat, Inc.
> + * Author: Mark Salter
> + *
> + * This program is free software; you can redistribut
On Wed, Feb 05, 2014 at 05:04:07PM +, Leif Lindholm wrote:
> +void __init create_id_mapping(phys_addr_t addr, phys_addr_t size, int map_io)
> +{
> + pgd_t *pgd = &idmap_pg_dir[pgd_index(addr)];
> +
> + if (pgd >= &idmap_pg_dir[ARRAY_SIZE(idmap_pg_dir)]) {
> + pr_warn("BUG: n
On Fri, Jan 10, 2014 at 10:29:10PM +, Mark Salter wrote:
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> new file mode 100644
> index 000..a835b2c
> --- /dev/null
> +++ b/arch/arm64/include/asm/efi.h
> @@ -0,0 +1,12 @@
> +#ifndef _ASM_ARM64_EFI_H
> +#define _ASM
On Fri, Jan 10, 2014 at 10:29:08PM +, Mark Salter wrote:
> +ENTRY(efi_stub_entry)
> + stp x29, x30, [sp, #-32]!
> +
> + /*
> +* Call efi_entry to do the real work.
> +* x0 and x1 are already set up by firmware. Current runtime
> +* address of image is cal
On Fri, Jan 10, 2014 at 10:29:06PM +, Mark Salter wrote:
> +void __init create_id_mapping(phys_addr_t addr, phys_addr_t size)
> +{
> + pgd_t *pgd = &idmap_pg_dir[pgd_index(addr)];
> +
> + if (pgd >= &idmap_pg_dir[ARRAY_SIZE(idmap_pg_dir)]) {
> + pr_warn("BUG: not creating id
On Fri, Dec 06, 2013 at 02:55:54PM +, Mark Salter wrote:
> On Thu, 2013-12-05 at 14:18 +0000, Catalin Marinas wrote:
> > On Fri, Nov 29, 2013 at 10:05:10PM +, Mark Salter wrote:
> > > + add x2, sp, 16
> > > + str x8, [x2]
>
On Thu, Dec 05, 2013 at 03:52:41PM +, Mark Salter wrote:
> On Thu, 2013-12-05 at 15:25 +0000, Catalin Marinas wrote:
> > I lost track of the early_ioremap status for arm/arm64? Was there more
> > progress since October (I think)?
>
> See the two patch series:
>
>
On Thu, Dec 05, 2013 at 02:43:23PM +, Mark Salter wrote:
> On Thu, 2013-12-05 at 14:18 +0000, Catalin Marinas wrote:
> > On Fri, Nov 29, 2013 at 10:05:10PM +, Mark Salter wrote:
> > > This patch adds PE/COFF header fields to the start of the Image
> > > s
On Fri, Nov 29, 2013 at 10:05:12PM +, Mark Salter wrote:
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> new file mode 100644
> index 000..7384048
> --- /dev/null
> +++ b/arch/arm64/include/asm/efi.h
> @@ -0,0 +1,18 @@
> +#ifndef _ASM_ARM64_EFI_H
> +#define _ASM
Hi Mark,
On Fri, Nov 29, 2013 at 10:05:10PM +, Mark Salter wrote:
> This patch adds PE/COFF header fields to the start of the Image
> so that it appears as an EFI application to EFI firmware. An EFI
> stub is included to allow direct booting of the kernel Image. Due
> to EFI firmware limitatio
59 matches
Mail list logo
