U because
it would overwrite the efi_scratch.prev_mm information.
Remove task_lock() and also update the comment to reflect it.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/efi/efi_64.c | 10 --
1 file changed, 4 insertions(+), 6 del
to check the compiler's support for
-mno-single-pic-base before using it, similar to c1c386681bd7 ("ARM:
8767/1: add support for building ARM kernel with clang").
Signed-off-by: Alistair Strachan
Reviewed-by: Stefan Agner
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/l
Installing UEFI configuration tables can only be done before calling
ExitBootServices(), so if we want to use the new MEMRESRVE config table
from the kernel proper, we need to install a dummy entry from the stub.
Tested-by: Jeremy Linton
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi
From: Aaron Ma
EFI GOP uses 64-bit frame buffer address in some BIOS.
Add 64bit address support in efi earlyprintk.
Signed-off-by: Aaron Ma
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/efi/early_printk.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch
ss support
Alistair Strachan (1):
efi/libstub: arm: support building with clang
Ard Biesheuvel (3):
efi: honour memory reservations passed via a linux specific config table
efi/arm: libstub: add a root memreserve config table
efi: add API to reserve memory persistently ac
On 21 September 2018 at 10:46, Marc Zyngier wrote:
> On Fri, 21 Sep 2018 18:14:43 +0100,
> Jeffrey Hugo wrote:
>>
>> On 9/21/2018 10:32 AM, Ard Biesheuvel wrote:
>> > Add support for persistent memory reservations across kexec reboot on EFI
>> > systems
On Fri, 21 Sep 2018 at 10:14, Jeffrey Hugo wrote:
>
> On 9/21/2018 10:32 AM, Ard Biesheuvel wrote:
> > Add support for persistent memory reservations across kexec reboot on EFI
> > systems by introducing a Linux-specific UEFI configuration table that points
> > to a linked
Installing UEFI configuration tables can only be done before calling
ExitBootServices(), so if we want to use the new MEMRESRVE config table
from the kernel proper, we need to install a dummy entry from the stub.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/libstub/arm-stub.c | 27
Add kernel plumbing to reserve memory regions persistently on a EFI
system by adding entries to the MEMRESERVE linked list.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c | 32
include/linux/efi.h| 1 +
2 files changed, 33 insertions(+)
diff --git a
useful, e.g., for GICv3 based ARM systems that cannot disable
DMA access to the LPI tables, forcing them to reuse the same memory
region again after a kexec reboot.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c | 27 +++-
include/linux/efi.h| 8 ++
2
treat
as reserved.
The specific use case for this feature is GICv3 ARM systems that are not
able to disable DMA access to LPI tables, meaning we have to reserve them
and make the next kernel reuse the existing tables rather than allocating
them from scratch.
Cc: Jeremy Linton
Cc: Marc Zyngier
Ard
On 16 September 2018 at 08:22, Ben Hutchings wrote:
> We currently align the end of the compressed image to a multiple of
> 16. However the PE-COFF header included in the EFI stub says that the
> file alignment is 32 bytes, and when adding an EFI signature to the
> file it must first be padded to
("efi/libstub/arm: Add opt-in Kconfig option ...")
Signed-off-by: Scott Branden
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/Kconfig | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kco
The following changes since commit 11da3a7f84f19c26da6f86af878298694ede0804:
Linux 4.19-rc3 (2018-09-09 17:26:43 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git efi-urgent
for you to fetch changes up to d310959365942b100f79b56bcce8599
On 12 September 2018 at 20:32, Hans de Goede wrote:
> Before this commit we were only calling efi_parse_options() from
> make_boot_params(), but make_boot_params() only gets called if the
> kernel gets booted directly as an EFI executable. So when booted through
> e.g. grub we ended up not parsing
On 22 August 2018 at 11:15, Ivan Hu wrote:
> Add exporting the UEFI runtime service ResetSystem for upper application or
> test
> tools to use.
>
> Signed-off-by: Ivan Hu
Queued in efi/next - thanks.
> ---
> drivers/firmware/efi/test/efi_test.c | 27 +++
> drivers/firm
On 12 September 2018 at 20:56, Thomas Gleixner wrote:
> On Tue, 11 Sep 2018, Sai Praneeth Prakhya wrote:
>> diff --git a/drivers/firmware/efi/runtime-wrappers.c
>> b/drivers/firmware/efi/runtime-wrappers.c
>> index b18b2d864c2c..7455277a3b65 100644
>> --- a/drivers/firmware/efi/runtime-wrappers.c
On 12 September 2018 at 20:00, Aaron Ma wrote:
> EFI GOP uses 64-bit frame buffer address in some BIOS.
> Add 64bit address support in efi earlyprintk.
>
> V2:
> Fix type of address.
>
> Signed-off-by: Aaron Ma
Thanks. Queued in efi/next.
> ---
> arch/x86/platform/efi/early_printk.c | 8 ++
On 12 September 2018 at 17:28, Hans de Goede wrote:
> Hi,
>
>
> On 12-09-18 17:06, Ard Biesheuvel wrote:
>>
>> On 12 September 2018 at 15:18, Hans de Goede wrote:
>>>
>>> Before this commit we were only calling efi_parse_options() from
>>> m
On 12 September 2018 at 15:18, Hans de Goede wrote:
> Before this commit we were only calling efi_parse_options() from
> make_boot_params(), but make_boot_params() only gets called if the
> kernel gets booted directly as an EFI executable. So when booted through
> e.g. grub we ended up not parsing
On 8 September 2018 at 18:23, Aaron Ma wrote:
> EFI GOP uses 64-bit frame buffer address in some BIOS.
> Add 64bit address support in efi earlyprintk.
>
> Signed-off-by: Aaron Ma
> ---
> arch/x86/platform/efi/early_printk.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/pl
/fault.c | 9
> arch/x86/platform/efi/quirks.c | 78
> +
> drivers/firmware/efi/runtime-wrappers.c | 61 +++---
> include/linux/efi.h | 42 ++
> 5 files changed, 147 insertions(+), 44 deletions(-)
>
> Tested-by: Bhupesh Sharma
> Suggested-by: Matt Fleming
> Based-on-code-from: Ricardo Neri
> Signed-off-by: Sai Praneeth Prakhya
> Cc: Al Stone
> Cc: Borislav Petkov
> Cc: Ingo Molnar
> Cc: Andy Lutomirski
> Cc: Bhupesh Sharma
> Cc: Thomas Gleixner
> Cc: Peter Zijlstra
> Cc: Ard Biesheuvel
>
> --
> 2.7.4
>
On 11 September 2018 at 18:15, Eugene Korenevsky wrote:
> Use gpt_header.sizeof_partition_entry instead of sizeof(gpt_entry)
> for GPT entry size.
> According to UEFI 2.7 spec 5.3.1 "GPT overview":, the size of a GUID Partition
> Entry element is defined in the Size Of Partition Entry field of GPT
On 10 September 2018 at 21:03, Eugene Korenevsky wrote:
> Use gpt_header.sizeof_partition_entry instead of sizeof(gpt_entry)
> for GPT entry size.
> According to UEFI spec, GPT entry size is specified in GPT header.
>
I think this patch is probably correct, but could you please provide
more infor
| 9 +
> arch/x86/platform/efi/quirks.c | 70
> +
> drivers/firmware/efi/runtime-wrappers.c | 60
> include/linux/efi.h | 37 +++++
> 6 files changed, 159 insertions(+), 44 deletions(-)
>
> Suggested-by: Matt Fleming
> Based-on-code-from: Ricardo Neri
> Signed-off-by: Sai Praneeth Prakhya
> Cc: Al Stone
> Cc: Borislav Petkov
> Cc: Ingo Molnar
> Cc: Andy Lutomirski
> Cc: Bhupesh Sharma
> Cc: Thomas Gleixner
> Cc: Peter Zijlstra
> Cc: Ard Biesheuvel
>
> --
> 2.7.4
>
ing firmware that doesn't understand DT.
> Update the EFI stub documentation to reflect the current usage.
>
> Signed-off-by: Grant Likely
> Reviewed-by: Alexander Graf
> Acked-by: Leif Lindholm
> Acked-by: Olof Johansson
> Cc: Ard Biesheuvel
> Cc: J
On 5 September 2018 at 19:53, Prakhya, Sai Praneeth
wrote:
>> On Wed, 5 Sep 2018, Ard Biesheuvel wrote:
>> > On 5 September 2018 at 14:56, Peter Zijlstra wrote:
>> > > On Wed, Sep 05, 2018 at 02:27:49PM +0200, Ard Biesheuvel wrote:
>> > >> Would we st
On 5 September 2018 at 14:56, Peter Zijlstra wrote:
> On Wed, Sep 05, 2018 at 02:27:49PM +0200, Ard Biesheuvel wrote:
>> On 5 September 2018 at 00:12, Sai Praneeth Prakhya
>> wrote:
>> > From: Sai Praneeth
>> >
>> > The efi page fault handler th
slav Petkov
> Cc: Ingo Molnar
> Cc: Andy Lutomirski
> Cc: Bhupesh Sharma
> Cc: Thomas Gleixner
> Cc: Peter Zijlstra
> Cc: Ard Biesheuvel
> ---
> arch/x86/include/asm/efi.h | 6 ++
> arch/x86/platform/efi/efi.c| 2 ++
> arch/x86/platform/efi/quir
On 22 August 2018 at 15:18, Paul Menzel wrote:
> Dear Ard,
>
>
> On 03/25/18 17:21, Paul Menzel wrote:
>
>> On 03/25/2018 09:41 AM, Paul Menzel wrote:
>>
>>> On 03/24/2018 11:35 PM, Ard Biesheuvel wrote:
>>>
>>>> On 24 March 2018 at 22:10,
On 9 August 2018 at 11:13, Dave Young wrote:
> On 08/09/18 at 09:33am, Mike Galbraith wrote:
>> On Thu, 2018-08-09 at 12:21 +0800, Dave Young wrote:
>> > Hi Mike,
>> >
>> > Thanks for the patch!
>> > On 08/08/18 at 04:03pm, Mike Galbraith wrote:
>> > > When booting with efi=noruntime, we call efi_
RM kernel with clang").
>
> Looks good to me:
>
> Reviewed-by: Stefan Agner
>
Thanks. I will queue this after the merge window closes
>>
>> Cc: Stefan Agner
>> Cc: Ard Biesheuvel
>> Cc: Will Deacon
>> Cc: Greg Kroah-Hartman
>> Cc: Russell K
On 7 August 2018 at 20:01, Prakhya, Sai Praneeth
wrote:
> Hi All,
>
>> > >> The main problem is that we have just merged Sai's code to use a
>> > >> work queue for invoking EFI services, and killing kworker threads
>> > >> is obviously not going to make EFI any new friends.
>> > >>
>> > >> So I gu
On 5 August 2018 at 18:31, joeyli wrote:
> On Sun, Aug 05, 2018 at 09:25:56AM +0200, Ard Biesheuvel wrote:
>> Hello Chun,yi,
>>
>> On 5 August 2018 at 05:21, Lee, Chun-Yi wrote:
>> > When secure boot is enabled, only signed EFI binary can access
>>
cki"
> Cc: Pavel Machek
> Cc: Chen Yu
> Cc: Oliver Neukum
> Cc: Ryan Chen
> Cc: Ard Biesheuvel
> Cc: David Howells
> Cc: Mimi Zohar
> Signed-off-by: "Lee, Chun-Yi"
Very useful.
Acked-by: Ard Biesheuvel
> ---
> include/linux/efi.h | 26 +
. Peter Anvin"
> Cc: "Rafael J. Wysocki"
> Cc: Pavel Machek
> Cc: Chen Yu
> Cc: Oliver Neukum
> Cc: Ryan Chen
> Cc: Ard Biesheuvel
> Cc: David Howells
> Cc: Mimi Zohar
> Signed-off-by: "Lee, Chun-Yi"
Not my call to make perhaps, but i&#
b4d34470009566
>
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: "Rafael J. Wysocki"
> Cc: Pavel Machek
> Cc: Chen Yu
> Cc: Oliver Neukum
> Cc: Ryan Chen
> Cc: Ard Biesheuvel
> Cc: David Howells
&
On 1 August 2018 at 22:49, Eric Snowberg wrote:
>
>> On Aug 1, 2018, at 11:33 AM, Ard Biesheuvel
>> wrote:
>>
>> On 1 August 2018 at 19:07, Jeffrey Hugo wrote:
>>> On 8/1/2018 10:27 AM, Eric Snowberg wrote:
>>>> Once EBS is called, there isn’t e
On 1 August 2018 at 19:07, Jeffrey Hugo wrote:
> On 8/1/2018 10:27 AM, Eric Snowberg wrote:
>>
>>
>>> On Aug 1, 2018, at 9:52 AM, Jeffrey Hugo wrote:
>>>
>>> On 8/1/2018 8:56 AM, Eric Snowberg wrote:
Commit d2078d5adbe2 ("x86: EFI stub support for large memory maps")
added support
On 24 July 2018 at 21:28, Sebastian Andrzej Siewior
wrote:
> efi_switch_mm() is a wrapper around switch_mm() which saves current's
> ->active_mm, sets the requests mm as ->active_mm and invokes
> switch_mm().
> I don't think that task_lock() is required during that procedure. It
> protects ->mm wh
On 26 July 2018 at 20:51, Prakhya, Sai Praneeth
wrote:
>> > The basic idea is that, when you get an exception from a context that
>> > is busted (i.e. it wasn't user code with a signal handler or kernel
>> > code with a fixup), you can't return from the exception handler. That
>> > leaves two cho
On 26 July 2018 at 20:09, Andy Lutomirski wrote:
> [sorry for totally busted formatting -- your email client and Gmail
> don't get along]
>
> On Jul 26, 2018, at 10:23 AM, Prakhya, Sai Praneeth
> wrote:
>
>> I have added some x86/intel folks to cc.
>>
>> I am fine with these patches, and I think
On 26 July 2018 at 15:14, Sebastian Andrzej Siewior
wrote:
> On 2018-07-26 15:13:23 [+0200], To Ard Biesheuvel wrote:
>> On 2018-07-26 14:52:21 [+0200], Ard Biesheuvel wrote:
>> > We could also make it the default on -rt, but not disable it entirely, so
>> > that ef
> On 26 Jul 2018, at 14:46, Sebastian Andrzej Siewior
> wrote:
>
>> On 2018-07-26 14:26:25 [+0200], Ard Biesheuvel wrote:
>> What i mean is whatever you end up with if you pass efi=noruntime to the
>> kernel.
> ah. So I wouldn't have to patch this, just d
> On 26 Jul 2018, at 14:15, Sebastian Andrzej Siewior
> wrote:
>
>> On 2018-07-26 11:15:52 [+0200], Ard Biesheuvel wrote:
>> On 26 July 2018 at 11:04, Sebastian Andrzej Siewior
>> wrote:
>>> Based on measurements the EFI functions get_variable /
>&
On 26 July 2018 at 11:04, Sebastian Andrzej Siewior
wrote:
> Based on measurements the EFI functions get_variable /
> get_next_variable take up to 2us. The functions get_time, set_time take
> around 10ms. Those 10ms are too much. Even one ms would be too much.
You cannot extrapolate from these nu
On 25 July 2018 at 19:32, Prakhya, Sai Praneeth
wrote:
>> I have added some x86/intel folks to cc.
>>
>> I am fine with these patches, and I think it is useful to be able to detect
>> and
>> recover from buggy UEFI implementations that use boot time regions at
>> runtime.
>>
>> However, I need he
+++
> drivers/firmware/efi/efi.c | 6 +-
> drivers/firmware/efi/runtime-wrappers.c | 6 +
> include/linux/efi.h | 16 ++-
> init/main.c | 3 +-
> 13 files changed, 415 insertions(+), 22 deletions(-)
>
> Sign
On 24 July 2018 at 18:02, Sebastian Andrzej Siewior
wrote:
> On 2018-07-24 17:32:14 [+0200], Ard Biesheuvel wrote:
>> Please refer to what has been queued up in tip:efi/core. Sai has
>> implemented a work queue for EFI calls so they occur from a kernel
>> thread, and the m
On 24 July 2018 at 17:29, Sebastian Andrzej Siewior
wrote:
> On 2018-07-24 17:00:09 [+0200], Peter Zijlstra wrote:
>> On Tue, Jul 24, 2018 at 04:35:09PM +0200, Sebastian Andrzej Siewior wrote:
>> > I doubt that there any need to set ->active_mm. It is used by the
>> > scheduler to keep track of th
the non-NULL check later on in the code could produce
false positives, given that the return code of the handle_protocol() call
is ignored entirely. So add the missing initialization.
Tested-by: Hans de Goede
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 1 +
1 file
guid_parse() against guid_t type of variable
Ard Biesheuvel (6):
efi/x86: prevent reentrant firmware calls in mixed mode
efi/x86: merge setup_efi_pci32 and setup_efi_pci64 routines
efi/x86: align efi_uga_draw_protocol typedef names to convention
efi/x86: merge 32-bit and 64-bit UGA
").
To be able to dereference the device_handle attribute from the
efi_loaded_image_t table in an arch- and bitness-agnostic manner,
introduce the efi_table_attr() macro (which already exists for x86)
to arm and arm64.
No functional change intended.
Signed-off-by: Lukas Wunner
Signed-off-by:
ess building for 64-bit with mixed mode support.
Tested-by: Hans de Goede
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
in
e the only
difference is the size of a EFI_HANDLE. So let's parameterize a single
implementation for that difference only, and get rid of the two copies of
the code.
While at it, rename __setup_efi_pci() to preserve_pci_rom_image() to
better reflect its purpose.
Tested-by: Hans de Goede
Sig
From: Andy Shevchenko
uuid_le_to_bin() is deprecated API and take into consideration that variable,
to where we store parsed data, is type of guid_t we switch to guid_parse()
for sake of consistency.
While here, add error checking to it.
Signed-off-by: Andy Shevchenko
Signed-off-by: Ard
From: Andy Shevchenko
The commit
2f74f09bce4f ("efi: parse ARM processor error")
brought inconsistency in UUID types which are used across the CPER.
Fix this by moving to use guid_t API everywhere.
Cc: Tyler Baicar
Signed-off-by: Andy Shevchenko
Signed-off-by: Ard
ethod of the UGA draw protocol, which
happens to be the first member, and so truncating the 64-bit void* at
offset 0 to 32 bits happens to produce the correct value. But let's
not rely on that, and use the proper API instead.
Tested-by: Hans de Goede
Signed-off-by: Ard Biesheuvel
---
arc
de Goede
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/efi/efi_64.c | 101 -
1 file changed, 98 insertions(+), 3 deletions(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 77873ce700ae..448267f1c073 100644
--- a/arch/x86
: Hans de Goede
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 4 ++--
arch/x86/boot/compressed/eboot.h | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index c72550783c16
ntime data marked
as EFI_MEMORY_MAPPED_IO should be mapped as 'unencrypted' so that both
guest and hypervisor can access the data.
Fixes: 1379edd59673 ("x86/efi: Access EFI data as encrypted ...")
Cc: # 4.15.x
Signed-off-by: Brijesh Singh
Reviewed-by: Tom Lendacky
Signed-off-by
The following changes since commit 9d3cce1e8b8561fed5f383d22a4d6949db4eadbe:
Linux 4.18-rc5 (2018-07-15 12:49:31 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git efi-urgent
for you to fetch changes up to b0d2fc41203d3712585b71d8f14914f
On 17 July 2018 at 03:15, Brijesh Singh wrote:
> Hi Ard,
>
>
>
> On 07/11/2018 05:00 AM, Ard Biesheuvel wrote:
>>
>> On 3 July 2018 at 15:32, Brijesh Singh wrote:
>>>
>>> SEV guest fails to update the UEFI runtime variables stored in the
>>>
is not in EFI_BOOT_SERVICES_DATA memory, but we try
to reserve it nonetheless.
So make the call to efi_mem_reserve() conditional on the memory type.
Cc: Peter Jones
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/esrt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
wrote:
> Final，i found the problem patch is
> 32fcefa2bfc8961987e91d1daeb00624b4176d2e，x86/boot/compressed/64: Set up
> trampoline memory
>
Youling,
Thanks a lot for narrowing that down!
We will try to investigate in more detail.
> 2018-07-16 15:30 GMT+08:00 Ard Biesheuvel :
>&g
On 16 July 2018 at 16:55, Andy Shevchenko
wrote:
> On Mon, 2018-07-16 at 16:51 +0200, Ard Biesheuvel wrote:
>
>> Thanks, I'll queue this in efi/next
>
> Thanks!
>
> Btw, you ACKed patch against efivars, who is supposed to apply it?
>
I will take that one as we
On 13 July 2018 at 23:30, Ard Biesheuvel wrote:
> On 13 July 2018 at 15:10, Andy Shevchenko
> wrote:
>> uuid_le_to_bin() is deprecated API and take into consideration that variable,
>> to where we store parsed data, is type of guid_t we switch to guid_parse()
>>
On 16 July 2018 at 12:04, Andy Shevchenko
wrote:
> The commit
>
> 2f74f09bce4f ("efi: parse ARM processor error")
>
> brought inconsistency in UUID types which are used across the CPER.
>
> Fix this by moving to use guid_t API everywhere.
>
> Cc: Tyler Baicar
> Signed-off-by: Andy Shevchenko
>
On 14 July 2018 at 13:41, Lukas Wunner wrote:
> On Fri, Jul 13, 2018 at 03:54:29PM +0200, Ard Biesheuvel wrote:
>> Did you have any thoughts about how we could at least detect
>> situations where we are invoking protocols that are not mixed-mode
>> safe (i.e., they pass 64-bi
On 14 July 2018 at 12:06, Lukas Wunner wrote:
> On Sat, Jul 14, 2018 at 12:12:38AM +0200, Ard Biesheuvel wrote:
>> On 13 July 2018 at 23:33, Lukas Wunner wrote:
>> > On Sat, Jul 14, 2018 at 04:57:36AM +0800, kbuild test robot wrote:
>> >> vim +425 drivers/firmware
On 13 July 2018 at 23:33, Lukas Wunner wrote:
> On Sat, Jul 14, 2018 at 04:57:36AM +0800, kbuild test robot wrote:
>> vim +425 drivers/firmware/efi/libstub/efi-stub-helper.c
>>
>>415
>>416static efi_status_t efi_open_volume(efi_system_table_t
>> *sys_table_arg,
>>417
t;
> Signed-off-by: Andy Shevchenko
Acked-by: Ard Biesheuvel
> ---
> fs/efivarfs/inode.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c
> index 71ff317e..8c6ab6c95727 100644
> --- a/fs/efivarfs/inod
oblem，i
> still not solved my problem.
>
OK so if reverting that last patch did not fix your issue, why did you
bring it up in the first place?
Please, try to use git bisect methodically to narrow down the issue.
If you do that, we will be able to help.
If you don't, I am afraid there
On 13 July 2018 at 11:57, Lukas Wunner wrote:
> On Thu, Jul 12, 2018 at 02:21:48PM +0200, Ard Biesheuvel wrote:
>> Patch #2 merges the remaining 32/64-bit specific parts of the setup_efi_pci
>> routine.
>>
>> Patches #3 and #4 do the same for the UGA draw protocol disc
egin to used from 4.17 rc3，the problem make a headache for me two
>> months.
>> i can't bisect to find the reason ，problem begin with 4.17，the 4.16 work
>> well，4.16.18 also work well.
>>
>> 2018-07-13 13:38 GMT+08:00 Ard Biesheuvel :
>>>
>>> On
On 13 July 2018 at 15:29, Ingo Molnar wrote:
>
> * Lukas Wunner wrote:
>
>> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
>> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
>> @@ -413,6 +413,32 @@ static efi_status_t efi_file_close(void *handle)
>> return efi_call_proto(efi_file
On 13 July 2018 at 00:22, Geoff Levand wrote:
> Hi Ard,
>
> On 07/04/2018 08:49 AM, Ard Biesheuvel wrote:
>> efi/libstub: taken contents of LinuxExtraArgs UEFI variable into
>> account
>
> To me this seems an overly complicated interface to the kernel, and
>
runtime service in mixed
>> mode. We will also need to provide non-blocking versions of SetVariable() and
>> QueryVariableInfo(), so add those as well.
>>
>> Signed-off-by: Ard Biesheuvel
>
> FWIW, this patch looks good to me.
>
Thanks Sai. I will take this as an acked-b
On 13 July 2018 at 03:59, Prakhya, Sai Praneeth
wrote:
> Hi Ard,
>
>> This series contains some fixes and cleanups for mixed-mode UEFI on x86.
>>
>> Patch #1 adds the missing locking in the runtime service wrapper code for
>> mixed
>> mode. This was found by inspection rather than having been rep
> On 12 Jul 2018, at 19:01, Will Deacon wrote:
>
> Hi Ard,
>
>> On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
>> As noted by Ian, many DMI based quirks for x86 ACPI machines disable
>> features that can also be disabled via the kernel command
On 12 July 2018 at 16:26, Hans de Goede wrote:
> Hi,
>
> On 12-07-18 14:21, Ard Biesheuvel wrote:
>>
>> This series contains some fixes and cleanups for mixed-mode UEFI on x86.
>>
>> Patch #1 adds the missing locking in the runtime service wrapper code for
the non-NULL check later on in the code could produce
false positives, given that the return code of the handle_protocol() call
is ignored entirely. So add the missing initialization.
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 1 +
1 file changed, 1 insertion(+)
diff
: Ard Biesheuvel
---
arch/x86/platform/efi/efi_64.c | 101 +++-
1 file changed, 98 insertions(+), 3 deletions(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index e01f7ceb9e7a..24f1231a9278 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86
y and 64-bit only)
Ard Biesheuvel (6):
efi/x86: prevent reentrant firmware calls in mixed mode
efi/x86: merge setup_efi_pci32 and setup_efi_pci64 routines
efi/x86: align efi_uga_draw_protocol typedef names to convention
efi/x86: merge 32-bit and 64-bit UGA draw protocol setup routines
ef
ess building for 64-bit with mixed mode support.
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 92b573fd239c..b492fba23
ethod of the UGA draw protocol, which
happens to be the first member, and so truncating that value at
offset 0 to 32 bits happens to produce the correct value. But let's
not rely on that, and use the proper API instead.
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/ebo
e the only
difference is the size of a EFI_HANDLE. So let's parameterize a single
implementation for that difference only, and get rid of the two copies of
the code.
While at it, rename __setup_efi_pci() to preserve_pci_rom_image() to
better reflect its purpose.
Signed-off-by: Ard Biesheuvel
---
: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 4 ++--
arch/x86/boot/compressed/eboot.h | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index c72550783c16..011d5c289449 100644
--- a/arch
On 11 July 2018 at 13:14, Ingo Molnar wrote:
>
> * Ard Biesheuvel wrote:
>
>> On 11 July 2018 at 12:13, Ingo Molnar wrote:
>> >
>> > * Ard Biesheuvel wrote:
>> >
>> >> The following changes since commit
>> >> 1e4b044d22517cae
On 11 July 2018 at 12:13, Ingo Molnar wrote:
>
> * Ard Biesheuvel wrote:
>
>> The following changes since commit 1e4b044d22517cae7047c99038abb23243ca:
>>
>> Linux 4.18-rc4 (2018-07-08 16:34:02 -0700)
>>
>> are available in the Git repository at:
>
Cc: Thomas Gleixner
> Cc: Borislav Petkov
> Cc: linux-efi@vger.kernel.org
> Cc: k...@vger.kernel.org
> Cc: Ard Biesheuvel
> Cc: Matt Fleming
> Cc: Andy Lutomirski
> Cc: # 4.15.x
> Signed-off-by: Brijesh Singh
> ---
> arch/x86/platform/efi/efi_64.c | 2 +-
> 1
erate on in the first place.
While we're at it, drop the __init annotation so that drivers can use it
as well.
Cc: Peter Jones
Tested-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/efi/quirks.c | 3 ++-
drivers/firmware/efi/efi.c | 8 +---
drivers/fir
Jones
Tested-by: Laszlo Ersek
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Ard Biesheuvel
---
drivers/video/fbdev/efifb.c | 51 +
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
across boots.
This is almost certainly overkill, but seems better than just extending
the deadline from 2038 to 2106.
Signed-off-by: Arnd Bergmann
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/cper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a
Praneeth Prakhya
Signed-off-by: Ard Biesheuvel
---
include/linux/efi.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 8ba0cdd244b2..e190652f5ef9 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -988,14 +988,12 @@ extern void
b: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c | 14 ++
drivers/firmware/efi/runtime-wrappers.c | 202 ++--
include/l
lm
Reviewed-by: Alexander Graf
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/Kconfig| 12
drivers/firmware/efi/libstub/arm-stub.c | 7 ---
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/ef
ts doesn't
block.
Signed-off-by: Sai Praneeth Prakhya
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/efi/quirks.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 36c1f8b9f7e0..6af39dc403
phase out the DTB loader in the ARM version of the EFI stub. (Ard)
- Drop an unused function declaration (Sai)
Ard Biesheuvel (3):
efi/libstub/arm: add opt-in Kconfig option for the DTB loader
efi: drop type and attribute
ty
- Break multi-line function prototypes at the name where possible,
not in the middle of the parameter list
- Use a newline before return statements consistently.
- Use curly braces in a balanced fashion.
- Remove stray newlines.
No change in functionality.
Cc: Ard Biesheuvel
C
401 - 500 of 1641 matches
Mail list logo
