is my patch for reference, but I think your original patch
> is better for backward compatible on variable name.
>
> Please consider to merge your original patch!
OK, this is what I've got queued up (note I removed the warning).
---
>From afa9ae7bf47145d661487f88f2ec67b062ca98bc
t; + *data_size = bvs->size;
> + return EFI_BUFFER_TOO_SMALL;
> + }
> + *data_size = bvs->size;
> + memcpy(data, bvs->data, bvs->size);
> +
> + return EFI_SUCCESS;
> + }
> +
uirky implementations
of GetNextVariableName() which resulted in machines hanging and
sysfs files being created with garbage names.
Matt Fleming (2):
efivars: explicitly calculate length of VariableName
efivars: H
On Tue, 2013-01-29 at 11:52 +0800, Xishi Qiu wrote:
> On ia64 platform, I set "crashkernel=1024M-:600M", and dmesg shows 128M-728M
> memory is reserved for crash kernel. Then "echo c > /proc/sysrq-trigger" to
> test kdump.
>
> When crash kernel booting, efi_init() will aligns the memory address in
On Sun, 2013-02-03 at 16:15 +0100, Ben Hutchings wrote:
> As you can see this needed quite a lot of work to backport, and I
> haven't been able to test it yet. So I would particularly appreciate
> careful review of this.
Everything looks fine to me but I haven't actually booted with these
changes
On Fri, 2013-02-08 at 18:05 +0800, Jeremy Kerr wrote:
> However, the tests expose a bug at the moment, so run_tests will fail.
> Matt will have that fixed soon though :)
In which case, would it make more sense for me to take these tests
through the efi tree? I'm fine either way, I'm just looking
On Fri, 2013-02-08 at 22:31 +, Seiji Aguchi wrote:
> Matt,
>
> Can you please take a look at this patchset which removes
> create_sysfs_entries() from efi_pstore_write()?
>
> It has been updated in accordance with Mike's comment and fixes an
> actual bug.
> http://comments.gmane.org/gmane.lin
t;
> Signed-off-by: Seiji Aguchi
> Acked-by: Mike Waychison
> ---
> drivers/firmware/efivars.c | 86 ++-
> 1 files changed, 44 insertions(+), 42 deletions(-)
Acked-by: Matt Fleming
Tony, are you picking this up?
--
Matt Fleming, Intel Open Sourc
nterrupt context with
> this patch.
>
> Signed-off-by: Seiji Aguchi
> ---
> drivers/firmware/efivars.c | 85
> +---
> include/linux/efi.h | 3 +-
> 2 files changed, 82 insertions(+), 6 deletions(-)
Acked-by: Matt Flemin
commit 9dead5bbb825 ("efi: Build EFI stub with EFI-appropriate options")
contains a typo which means that the efi_stub_$(BITS).o code is still not
compiled with -fshort-wchar and -mno-red-zone.
Fix it with s/KBUILD_CLFAGS/KBUILD_CFLAGS/
--
Matt Fleming, Intel Open Source Tec
ot via the EFI boot stub? That seems likely to upset some people.
Introducing new features via the EFI boot stub is fine, and working
around firmware bugs so that we can use some feature is also cool, but
we can't start fixing regressions from other subsystems in the EFI boot
stub.
--
Matt Fleming,
seen, there are various
schemes out there.
This looks like something that will differ between implementations, and the
fact that it's appearing in our code is a sure sign that this isn't the way to
go.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this
On 03/04/13 14:48, Matthew Garrett wrote:
> On Wed, 2013-04-03 at 14:11 +0100, Matt Fleming wrote:
>
>> This looks like something that will differ between implementations, and the
>> fact that it's appearing in our code is a sure sign that this isn't the way
>>
From: Matt Fleming
There are currently two implementations of the utf16 string functions.
Somewhat confusingly, they've got different names.
Centralise the functions in efi.h.
Cc: Tom Gundersen
Cc: Mike Waychison
Signed-off-by: Matt Fleming
---
drivers/firmware/efivars.c |
From: Matt Fleming
Some machines have an EFI variable interface that does not conform to the UEFI
specification, e.g. CONFIG_GOOGLE_SMI. Add the necessary code and Kconfig glue
so that it's only possible to select one implementation of EFI variable
operations. This allows us to keep a s
From: Matt Fleming
drivers/firmware/efivars.c has grown pretty large and is ~2K lines.
Inside efivars.c there's currently,
o code for handling EFI variables at the firmware-level
o sysfs code for exposing EFI variables
o a new EFI variable filesystem
o a persistent storage backend
From: Matt Fleming
Now that efivarfs uses the efivar API, move it out of efivars.c and into
fs/efivarfs where it belongs. This move will eventually allow us to enable the
efivarfs code without having to also enable CONFIG_EFI_VARS built, and vice
versa.
Furthermore, things like,
mount -t
From: Matt Fleming
efivars.c has grown far too large and needs to be divided up. Create a new
directory and move the persistence storage code to efi-pstore.c now that it
uses the new efivar API. This helps us to greatly reduce the size of efivars.c
and paves the way for moving other code out of
On 04/04/13 17:12, Richard Weinberger wrote:
> Fair point. I'll add such a printk() to my patch and resend.
Also take a look at FW_BUG.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
On Tue, 2013-01-29 at 17:52 +0100, Maarten Lankhorst wrote:
> It looks like the original commit that copied the rom contents from efi
> always copied
> the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
> ("x86, efi: correct precedence of operators in setup_efi_pci") broke that.
x86, efi: fix 32-bit warnings in setup_efi_pci()
Lingzhu Xiang (1):
efivarfs: Drop link count of the right inode
Maarten Lankhorst (1):
x86, efi: remove attribute check from setup_efi_pci
Matt Fleming (3):
efivarfs: Never return ENOENT from firmware
efivarfs: Delete den
On Fri, 2013-01-25 at 00:25 +, Al Viro wrote:
> 1) process A does write() on efivars file, reaches ->get_variable(),
> gets newdatasize set, drops efivars->lock and loses CPU before an attempt to
> grab ->i_mutex. process B comes and does the same thing, replacing the
> variable contents
On Fri, 2013-01-25 at 11:50 +0800, Lingzhu Xiang wrote:
> On 01/25/2013 08:25 AM, Al Viro wrote:
> > 1) process A does write() on efivars file, reaches ->get_variable(),
> > gets newdatasize set, drops efivars->lock and loses CPU before an attempt to
> > grab ->i_mutex. process B comes and doe
On Wed, 2013-01-23 at 13:17 +, Ben Hutchings wrote:
> On Wed, 2013-01-23 at 07:52 +0000, Matt Fleming wrote:
> > On Wed, 2013-01-23 at 04:16 +, Ben Hutchings wrote:
> > > On Mon, 2013-01-21 at 21:12 +, Matt Fleming wrote:
> &
On Sun, 2013-01-27 at 11:19 -0800, H. Peter Anvin wrote:
> It turns out the patch I sent out doesn't actually build. Here is an
> updated patch. Can I get your ack for this so I can do the appropriate
> hacks to your and Yinghai's patchsets?
>
> -hpa
>
Ack
On Mon, 2013-01-28 at 10:38 +0800, Lingzhu Xiang wrote:
> On 01/25/2013 09:18 PM, Matt Fleming wrote:
> >> 4. EFI_VARIABLE_APPEND_WRITE with EFI_OUT_OF_RESOURCES truncates size but
> >> you
> >> can still read its content.
> >
> > I'm not sure
From: Matt Fleming
commit 1de63d60cd5b ("efi: Clear EFI_RUNTIME_SERVICES rather than
EFI_BOOT by "noefi" boot parameter") attempted to make "noefi" true to
its documentation and disable EFI runtime services to prevent the
bricking bug described in commit e0094244e41
On Wed, 2013-02-20 at 16:16 -0800, Yinghai Lu wrote:
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 928bf83..e2cd38f 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -85,9 +85,10 @@ int efi_enabled(int facility)
> > }
>
From: Matt Fleming
commit 1de63d60cd5b ("efi: Clear EFI_RUNTIME_SERVICES rather than
EFI_BOOT by "noefi" boot parameter") attempted to make "noefi" true to
its documentation and disable EFI runtime services to prevent the
bricking bug described in commit e0094244e41
From: Matt Fleming
disable_runtime is only referenced from __init functions, so mark it
as __initdata.
Reported-by: Yinghai Lu
Cc: Satoru Takeuchi
Cc: H. Peter Anvin
Signed-off-by: Matt Fleming
---
arch/x86/platform/efi/efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Mon, 2013-03-11 at 16:17 -0500, Seth Forshee wrote:
> Here's a patch that does the command line option. I'm happy with either
> one.
I like the idea, but isn't the logic backwards? I would have expected
s/EFI_VARS_PSTORE_DEFAULT_DISABLE/EFI_VARS_PSTORE/g and then 'default y'
in the Kconfig file
On Tue, 2013-03-12 at 16:14 -0500, Seth Forshee wrote:
> From 91df4dd0d1e20f44ea16b3653cffecd507fdb500 Mon Sep 17 00:00:00 2001
> From: Seth Forshee
> Date: Wed, 6 Mar 2013 14:25:36 -0600
> Subject: [PATCH] efivars: Add module parameter to allow disabling use as a
> pstore backend
>
> We know th
On Wed, 2013-03-13 at 10:25 -0700, H. Peter Anvin wrote:
> I think there should be two compile-time options (one to compile in the
> EFI pstore code at all, and one to set its default.)
OK, sorry Seth, looks like I'm the one that misunderstood. I've picked
up your first two patches and pushed them
On Wed, 2013-03-13 at 14:14 -0500, Seth Forshee wrote:
> On Wed, Mar 13, 2013 at 06:33:37PM +0000, Matt Fleming wrote:
> > On Wed, 2013-03-13 at 10:25 -0700, H. Peter Anvin wrote:
> > > I think there should be two compile-time options (one to compile in the
> > > EFI pst
On Thu, 2012-08-30 at 14:28 -0700, Josh Triplett wrote:
> The ACPI BGRT lets the OS access the BIOS logo image and its position on the
> screen at boot time, allowing it to maintain that image on the screen until
> ready to display something else, making boot more seamless. This series fixes
> sup
On Tue, 2012-09-04 at 10:59 -0700, Josh Triplett wrote:
> On Tue, Sep 04, 2012 at 03:27:20PM +0100, Matt Fleming wrote:
> > On Thu, 2012-08-30 at 14:28 -0700, Josh Triplett wrote:
> > > The ACPI BGRT lets the OS access the BIOS logo image and its position on
> > > th
t, and reworks the existing BGRT
> driver to use that existing copy.
>
> v2: Made the new internal function efi_unmap_memmap static. Incorporated
> feedback from H. Peter Anvin and Matt Fleming: added stubs for
> x86-specific EFI functions called from init/main.c to eli
t, and reworks the existing BGRT
> driver to use that existing copy.
>
> v2: Made the new internal function efi_unmap_memmap static. Incorporated
> feedback from H. Peter Anvin and Matt Fleming: added stubs for
> x86-specific EFI functions called from init/main.c to eli
From: Matt Fleming
We're starting to need a channel through which we can funnel EFI
patches to make sure they get merged in a timely fashion. Matthew and
Peter seem happy enough for me to take that bullet.
Signed-off-by: Matt Fleming
Cc: H. Peter Anvin
Cc: Matthew Garrett
Cc: Ingo Molna
From: Matt Fleming
This series upgrades real_mode_header->trampoline_pgd to a proper
kernel pagetable instead of just mapping the kernel text and module
space. It also inserts the physical mappings for anything we
ioremap(), so I/O regions are always accessible via their physical
addres
From: Matt Fleming
There are various pieces of code in arch/x86 that require a page table
with an identity mapping. Make trampoline_pgd a proper kernel page
table, it currently only includes the kernel text and module space
mapping.
One new feature of trampoline_pgd is that it now has mappings
From: Matt Fleming
Some firmware still needs a 1:1 (virt->phys) mapping even after we've
called SetVirtualAddressMap(). So install the mapping alongside our
existing kernel mapping whenever we make EFI calls in virtual mode.
This bug was discovered on ASUS machines where the
kernel didn't zap the identity mapping page table, so tboot related
code can remove the remapping code before trapping back now.
Signed-off-by: Xiaoyan Zhang
Acked-by: Gang Wei
Signed-off-by: Matt Fleming
---
arch/x86/kernel/tboot.c | 78 -
1
On Wed, 2012-10-03 at 14:31 +0100, Jan Beulich wrote:
> >>> Matt Fleming 10/03/12 2:59 PM >>>
> >+static int insert_identity_mapping(resource_size_t paddr, unsigned long
> >vaddr,
> >+unsigned long size)
> >+{
> >+unsi
On Thu, 2012-10-04 at 10:24 +0800, Lee, Chun-Yi wrote:
> UEFI variable filesystem need a new mount point, so this patch add
> efivars kobject to efi_kobj for create a /sys/firmware/efi/efivars
> folder.
>
> Cc: Matt Fleming
> Cc: Jeremy Kerr
> Cc: Matthew Garrett
> Cc:
On Thu, 2012-10-04 at 07:32 +0100, Jan Beulich wrote:
> >>> On 03.10.12 at 16:03, Matt Fleming wrote:
> > On Wed, 2012-10-03 at 14:31 +0100, Jan Beulich wrote:
> >> >>> Matt Fleming 10/03/12 2:59 PM >>>
> >> >@@ -163,6 +258,10 @@ sta
On Fri, 2012-10-05 at 07:39 +0100, Jan Beulich wrote:
> >>> On 04.10.12 at 23:08, "H. Peter Anvin" wrote:
> > On 10/03/2012 06:31 AM, Jan Beulich wrote:
> >>>>> Matt Fleming 10/03/12 2:59 PM >>>
> >>> +static int inse
From: Matt Fleming
This series upgrades real_mode_header->trampoline_pgd to a proper
kernel pagetable instead of just mapping the kernel text and module
space. It also inserts the physical mappings for anything we
ioremap(), so I/O regions are always accessible via their physical
addres
From: Matt Fleming
There are various pieces of code in arch/x86 that require a page table
with an identity mapping. Make trampoline_pgd a proper kernel page
table, it currently only includes the kernel text and module space
mapping.
One new feature of trampoline_pgd is that it now has mappings
From: Matt Fleming
Some firmware still needs a 1:1 (virt->phys) mapping even after we've
called SetVirtualAddressMap(). So install the mapping alongside our
existing kernel mapping whenever we make EFI calls in virtual mode.
This bug was discovered on ASUS machines where the
kernel didn't zap the identity mapping page table, so tboot related
code can remove the remapping code before trapping back now.
Signed-off-by: Xiaoyan Zhang
Acked-by: Gang Wei
Signed-off-by: Matt Fleming
---
arch/x86/kernel/tboot.c | 78 -
1
Olof Johansson
> Acked-by: Maarten Lankhorst
> Cc: sta...@kernel.org # 3.4 - 3.6
> Cc: Matthew Garrett
Applied, thanks!
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
map(void)
+void __init efi_unmap_memmap(void)
{
if (memmap.map) {
early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
repository location on kernel.org.
Matt Fleming (1):
MAINTAINERS: Add EFI git repository location
Olof Johansson (1):
x86: efi: Turn off efi_enabled after setup on mixed fw/kernel
MAINTAINERS | 1 +
arch
On Fri, 2012-10-26 at 10:22 +0200, Ingo Molnar wrote:
> * Matt Fleming wrote:
>
> > Hi guys,
> >
> > The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
> >
> > Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
> >
> > are av
From: Matt Fleming
We've started getting reports of users seeing Machine Check Exceptions
when booting their Samsung laptops in UEFI mode,
https://bugzilla.kernel.org/show_bug.cgi?id=47121
This module seems to be the culprit as it's grovelling around in the
0xf region wh
loc.
>
> Cc: Jordan Justen
> Cc: Matt Fleming
> Cc: "H. Peter Anvin"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Signed-off-by: Cesar Eduardo Barros
> ---
> arch/x86/boot/header.S | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/
On Sun, 2012-11-04 at 09:47 -0800, Jonathan Nieder wrote:
> Matt Fleming wrote:
>
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -717,7 +717,7 @@ config XO15_EBOOK
> >
> > config SAMSUNG_LAPTOP
> > tristate &quo
27; variable, but it doesn't strictly mean
"this_is_a_uefi_system()", it actually means "Do we have EFI runtime
services?". The whole thing is a bit of a mess and I'm planning on
cleaning it up this week.
--
Matt Fleming, Intel Open Source Technology Center
--
To u
On Mon, 2012-11-05 at 11:37 +0100, Greg KH wrote:
> On Sun, Nov 04, 2012 at 05:35:06PM +0000, Matt Fleming wrote:
> > From: Matt Fleming
> >
> > We've started getting reports of users seeing Machine Check Exceptions
> > when booting their Samsung laptops i
mess and I'm planning on
> > cleaning it up this week.
>
>
> As far as I can understand it we should be reserving those areas on a
> UEFI booted machine and just marking them as busy so that they are not
> available to any drivers to go peering into.
Yes, that would be t
't
> grovel in places you shouldn't. Indeed its possible EFI should reserve
> those memory regions ?
The kernel would have to reserve the gaps in the memory mappings since
there is no mapping in the EFI memory map for 0xf. There is no
support for that currently AFAIK.
--
Matt
On Sun, 2012-11-04 at 17:44 +, Corentin Chary wrote:
> On Sun, Nov 4, 2012 at 5:35 PM, Matt Fleming wrote:
> > From: Matt Fleming
> >
> > We've started getting reports of users seeing Machine Check Exceptions
> > when booting their Samsung laptops
handling
> simpler.
>
> Signed-off-by: Matthew Garrett
> ---
> arch/x86/boot/compressed/Makefile |3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Matt Fleming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
boot/compressed/eboot.h |4
> 2 files changed, 20 insertions(+), 13 deletions(-)
Acked-by: Matt Fleming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Mon, 2012-06-25 at 09:12 -0400, Peter Jones wrote:
> This adds support for appending to all UEFI variables, and also for
> deleting authentication variables.
>
> Signed-off-by: Peter Jones
> ---
> drivers/firmware/efivars.c | 99
> +---
> 1 file chan
++---
> 1 file changed, 20 insertions(+), 7 deletions(-)
Looks good to me.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordo
rivers/firmware/efi/efi-stub-helper.c
> +++ b/drivers/firmware/efi/efi-stub-helper.c
> @@ -4,6 +4,7 @@
> * implementation files.
> *
> * Copyright 2011 Intel Corporation; author Matt Fleming
> + * Copyright 2013 Linaro Limited; author Roy Franz
> *
> * This file is par
On Thu, 03 Oct, at 09:43:24AM, Mark Salter wrote:
> On Thu, 2013-10-03 at 10:52 +0100, Matt Fleming wrote:
> > > +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> > > +static efi_status_t update_fdt(efi_system_table_t *sys_table, void
> > > *orig_fdt,
> >
efi-stub-fdt.c" file be satisfactory? This file would just be used
> the ARM and ARM64, so this would remove
> the need for the top-level #ifdefs.
Fair enough, move it to drivers/firmware/efi/fdt.c - there's no need to
prefix it with "efi-" (efi-pstore.c has historic baggage)
: Remove redundant memset()
arch/x86/platform/efi/efi.c| 2 +-
drivers/firmware/efi/efi-stub-helper.c | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On 10/07/13 07:36, Dave Young wrote:
> Another problem is: With this patch applied I tried noefi boot, but
> kernel paniced, looks like efivar_init depends on efi runtime. Below
> patches works for me about noefi boot though I'm not sure if it's a
> right fix, please review.
It makes more sense to
h that avoids passing EFI Boot Services
regions to SetVirtualAddressMap(). It caused boot regressions.
* Fix a crash in the efivars code by checking whether that EFI Runtime
Services are available before attempting to use them.
----------
lp. That way we'd
only need to reserve remaining regions in efi_reserve_boot_services().
This scheme would rely on nothing writing into the crash kernel area
before we've extracted the BGRT data, however.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this
t;\n");
> - early_iounmap(config_tables, efi.systab->nr_tables * sz);
> + early_iounmap(config_tables, nr_tables * sz);
> return 0;
> }
Thanks Dave, but this patch should no longer be necessary because of the
changes sitting in the 'next' branch at,
git
ivarfs_file_read() is implemented, e.g. using
efivar_entry_get(). In particular, note how it kmalloc()'s a buffer for
reading the variable data into, thereby avoiding any 1024-byte
limitation.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the
n Crosetto
> ---
> Changes in v2:
> * Free memory when error is returned from alloc_e820ext() as suggested by Matt
> Fleming
> * Set pointer to NULL and size to 0 after freeing memory in alloc_e820ext()
>
> arch/x86/boot/compressed/eboot.c | 223
> +++
fi_low_alloc(sys_table_arg, alloc_size, 0,
> + &new_addr);
This is wrong. You've dropped the hdr->kernel_alignment argument, and
the relaxed alignment of this allocation stops my machine from booting.
--
Matt Fleming, Intel Open Source Technology
gt; is based on code in the x86 stub that has been generalized
> to support other architectures.
Apart from PATCH 8/17, these all look good to me and work on my test
machines.
If you can respin PATCH 8 based on my comments I'll pull this series
into my efi tree and get it into linux-next.
Josh Boyer
Josh Boyer (1):
x86, efi: Don't map Boot Services on i386
arch/x86/platform/efi/efi.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubs
On Wed, 18 Sep, at 01:24:14PM, jerry.hoem...@hp.com wrote:
> Matt,
>
> I conducted the following experiments on a 3.11 kernel:
Jerry, could you paste your memory map from the kernel log?
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send
y complete depend
> on this one,
> so getting this merged soon would be helpful.
Just fixing the function name and comments is enough for this patch
series. Anything else should be separate.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line &
ally end up in the 'next' branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
On Fri, 20 Sep, at 11:05:44AM, Borislav Petkov wrote:
> But no, 32-bit is not addressed here. Which just dawned on me: Matt, I
> probably should keep the ioremapping code for 32-bit, doh. I completely
> went 64-bit only here :-)
Yes, please keep the ioremap code. At least for now.
/platform/efi/efi.c:867:2: error: implicit
declaration of function ‘efi_sync_low_kernel_mappings’
[-Werror=implicit-function-declaration]
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
(md->num_pages << PAGE_SHIFT
> return md->attribute;
> }
> return 0;
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 5f8f176154f7..fa47d80ab4b5 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@
%r15
+ movq%r15, efi_scratch+16(%rip)
callefi_main
movq%rax,%rsi
cmpq$0,%rax
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
; allowing for a triple fault.
Just to be clear, you haven't witnessed a triple fault, correct?
> This patch fixes this by clearing the interrupt bit before the lidt
> instruction.
I think we can go even further than this and get rid of all of the IDT
code in the EFI boot stub. The ke
RR_PTR(efi_status_to_err(status));
> + pr_err("PM: Couldn't get wake key data size: 0x%lx\n", status);
> + goto error;
> + }
Is it safe to completely bypass the efivars interface and access
efi.get_variable() directly? I wouldn't have thought so, unles
ed(EFI_BOOT) along with .secure_boot to
guard against garbage values in boot_params.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ey, it's that we can't invoke any of the variable runtime service
functions concurrently.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
as to merge 'arm/efi-stub' into my 'next' branch and ask you to
pull that into whichever branch you include in linux-next. Does that
work?
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
status = alloc_e820ext(nr_e820ext, &e820ext, &e820ext_size);
> + if (status != EFI_SUCCESS)
> + return status;
In the error path shouldn't we jump to free_mem_map to avoid leaking
memory?
--
Matt Fleming, Intel Open Source Technology
fice for now.
[ Added to changelog - Matt ]
Reported-by: Bryan O'Donoghue
Acked-by: Tom Zanussi
Acked-by: Darren Hart
Cc: Josh Triplett
Cc: Matthew Garrett
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc:
Signed-off-by: Josh Boyer
Signed-off-by: Ma
{
> + /*
> + * The entry will be deleted
> + * after scanning is completed.
> + */
> + entry->deleting = true;
> + } else
> + l
ices altogether.
The spec is pretty clear that runtime drivers shouldn't be doing this,
and so far this approach has served us well.
There are only two reasons why we keep the Boot Services regions around
(for a short period) at all,
1) To work around the aforementioned runtime firmware b
From: Matt Fleming
It's incredibly difficult to diagnose early EFI boot issues without
special hardware because earlyprintk=vga doesn't work on EFI systems.
Add support for writing to the EFI framebuffer, via earlyprintk=efi,
which will actually give users a chance of providing de
mplementations.
It's only going to be a matter of time until we *have* to disable some
our workarounds in order to boot the most recent incarantions of UEFI.
Not least because carrying these workarounds unconditionally and
indefinitely severely limits our ability to innovate.
--
Matt Flemin
. I'll reply to your emails asap.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-inf
On Thu, 08 Aug, at 06:46:02AM, Andrew Fish wrote:
>
> On Aug 8, 2013, at 3:17 AM, Matt Fleming wrote:
>
> > On Wed, 07 Aug, at 02:10:28PM, Andrew Fish wrote:
> >> Well the issue I see is I don't think OS X or Windows are doing this.
> >> So I'm guessin
1 - 100 of 2035 matches
Mail list logo
