On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote:
>
> So maybe something along the lines of an enum that would have entries
> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could
> be added later as needed.
Sure, that works for me, though maybe BOOT_DATA would be more
applica
On Tue, 07 Jun, at 01:23:05PM, Peter Jones wrote:
>
> Looks right to me.
>
> Acked-By: Peter Jones
Tomi, are you OK to take this one or would you like me to take it
through the EFI tree?
On Mon, 06 Jun, at 03:32:11PM, Colin Ian King wrote:
> From: Colin Ian King
>
> Remove unused variable efi, it is never used. Fixes clang build
> warning:
>
> arch/x86/boot/compressed/eboot.c:803:2: warning: Value stored to
> 'efi' is never read
>
> Signed-off-by: Colin Ian King
> ---
> arc
option to anything that kstringtobool
> will determine to be false.
>
> Signed-off-by: Joseph Thelen
> Cc: Alex Thorlton
> Cc: Matt Fleming
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: linux-...@vger.kernel
On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote:
> The EFI tables are not encrypted and need to be accessed as such. Be sure
> to memmap them without the encryption attribute set. For EFI support that
> lives outside of the arch/x86 tree, create a routine that uses the __weak
> attribute so that
(Sorry for the delay)
On Thu, 26 May, at 08:45:58AM, Tom Lendacky wrote:
>
> The patch in question is patch 6/18 where PAGE_KERNEL is changed to
> include the _PAGE_ENC attribute (the encryption mask). This now
> makes FIXMAP_PAGE_NORMAL contain the encryption mask while
> FIXMAP_PAGE_IO does not
On Mon, 06 Jun, at 03:40:18PM, Vincent Guittot wrote:
>
> The load average stuff is only enable for SMP system but it's not used
> for UP system.
Duh, right. My bad.
On Mon, 06 Jun, at 08:20:39AM, Yuyang Du wrote:
> Newly forked task has not been enqueued, so should not be removed from
> cfs_rq in task_move_group_fair(). To do so, we need to pass the fork
> information all the way from sched_move_task() to task_move_group_fair().
>
> Signed-off-by: Yuyang Du
On Mon, 06 Jun, at 08:20:37AM, Yuyang Du wrote:
> attach_entity_load_avg() is called (indirectly) from:
>
> - switched_to_fair(): switch between classes to fair
> - task_move_group_fair(): move between task groups
> - enqueue_entity_load_avg(): enqueue entity
>
> Only in switched_to_fair() is
On Tue, 31 May, at 11:23:42AM, Matt Fleming wrote:
> Folks, please pull the following urgent patches which fix a boot crash
> when using the "noefi" parameter and the debug output on arm.
>
> The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
>
On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote:
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index f310f0b..6643f9b 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -68,6 +68,52 @@ struct efi_scratch {
> u64 phys_stack;
> }
cd2
> ("x86/efi: Fix 7-parameter efi_call()s").
>
> Now that all of those issues are out of the way, we're able to make this
> simple change to use the new efi_call_virt_generic in uv_bios_call which
> gets our machines booting, running properly, and able to execute
gt; efi_call_virt_generic macro - this was mainly to keep the code from
> looking too cluttered by adding a bunch of extra references to
> efi.systab->runtime everywhere.
>
> Note that I also broke up the code in the efi_call_virt_generic macro a
> bit in the process of moving it.
>
n a driver is loaded for the wireless
> card, which may be never if the driver is not installed or blacklisted.
[... Snip a very thorough changelog ...]
This patch looks fine to me from an EFI perspective.
Acked-by: Matt Fleming
c: Mark Salter
Cc: "K. Y. Srinivasan"
Signed-off-by: Matt Fleming
---
include/linux/efi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index c2db3ca22217..f196dd0b0f2f 100644
--- a/include/linux/efi.
ned-off-by: Dennis Chen
Acked-by: Mark Rutland
Cc: Catalin Marinas
Cc: Steve Capper
Cc: Will Deacon
Cc: Ard Biesheuvel
Cc: linux-...@vger.kernel.org
Cc: Steve McIntyre
Cc: Steven Rostedt
Cc: Dan Williams
Cc: Mark Salter
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/arm-i
Folks, please pull the following urgent patches which fix a boot crash
when using the "noefi" parameter and the debug output on arm.
The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
are available in the git repository at:
(Cc'ing Mark, the original author)
On Wed, 25 May, at 04:36:55PM, Vitaly Kuznetsov wrote:
> Commit 78ce248faa3c ("efi: Iterate over efi.memmap in
> for_each_efi_memory_desc()") introduced a regression for systems booted
> with 'noefi' kernel option. In particular, I observe early kernel hang in
>
On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote:
>
> I looked into this and this would be a large change also to parse tables
> and build lists. It occurred to me that this could all be taken care of
> if the early_memremap calls were changed to early_ioremap calls. Looking
> in the git log I s
On Mon, 16 May, at 01:05:45PM, Linus Torvalds wrote:
>
> I think the right fix is to just get rid of that silly conditional
> frame pointer thing, and always use frame pointers in this stub
> function. And then we don't need that (odd) load to get the old stack
> pointer into %rax - we can just us
> the indirect call in the case we do a local wakeup.
>
> Cc: Pavan Kondeti
> Cc: Ben Segall
> Cc: Matt Fleming
> Cc: Morten Rasmussen
> Cc: Paul Turner
> Cc: Thomas Gleixner
> Cc: byungchul.p...@lge.com
> Cc: Andrew Hunter
> Fixes: 3a47d5124a95 ("sched/fai
On Wed, 18 May, at 12:46:38PM, Ingo Molnar wrote:
>
> I have no particular objections, since this seems to be Xen-next merged to
> the EFI
> tree that is already upstream, plus this single commit on top of t:
>
> 11ee5491e5ff Xen: EFI: Parse DT parameters for Xen specific UEFI
>
> Which, if
On Wed, 18 May, at 03:01:27AM, Yuyang Du wrote:
> On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote:
> > So, if the code looks like the following, either now or in the future,
> >
> > static void __schedule(bool preempt)
> > {
> > ...
> >
On Tue, 17 May, at 04:11:09AM, Yuyang Du wrote:
> On Mon, May 16, 2016 at 10:46:38AM +0100, Matt Fleming wrote:
> >
> > No because if someone calls rq_clock() immediately after __schedule(),
> > or even immediately after we clear RQCF_ACT_SKIP in __schedule(), we
> &g
On Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote:
>
> I was simply re-using the efi_call implementation. Boris suggested that
> I re-write this using the efi_call_virt macro, so I just went with that.
> It all seems to work just fine, so I don't see much reason to stray away
> from that impleme
On Tue, 17 May, at 10:04:34AM, Matt Fleming wrote:
>
> Now I'm wondering whether other users of FRAME_BEGIN/FRAME_END make
> this same mistake. Coccinelle might be able to detect it perhaps.
A quick bit of sed turned up the code in arch/x86/entry/entry_64.S,
which looks to suffer
On Mon, 16 May, at 01:05:45PM, Linus Torvalds wrote:
>
> So that whole 8-vs-16 offset confusion depends on the frame pointer!
> If frame pointers were enabled, it will be 16. If they weren't, it
> will be 8. That patch that changes it from 8 to 16 will just move the
> bug around. Before, it was co
rnel/mcount_64.S
> +++ b/arch/x86/kernel/mcount_64.S
> @@ -182,7 +182,8 @@ GLOBAL(ftrace_graph_call)
> jmp ftrace_stub
> #endif
>
> -GLOBAL(ftrace_stub)
> +/* This is weak to keep gas from relaxing the jumps */
> +WEAK(ftrace_stub)
> retq
> END(ftrace_caller)
Works for me.
Tested-by: Matt Fleming
atch series doesn't address
is that some callers of update_rq_clock() do not pin rq->lock, which
makes the diagnostic checks useless in that case.
I plan on handling that next, but I wanted to get this series out as
soon as possible for review.
> On Thu, May 12, 2016 at 08:49:53PM +010
On Fri, 13 May, at 10:06:10AM, Steven Rostedt wrote:
> Matt,
>
> This bug looks very similar to what you were hitting with the function
> profiler. Can you apply this patch and see if it fixes the issue for
> you.
Yep, this patch fixes it for me.
For the record, this is what objdump tells me (wi
On Wed, 11 May, at 05:16:24PM, Jeremy Compostella wrote:
> From 3a54e6872e220e1ac4db0eae126a20b5383dae3e Mon Sep 17 00:00:00 2001
> From: Jeremy Compostella
> Date: Tue, 10 May 2016 10:34:21 +0200
> Subject: [PATCH] efibc: report more information in the error messages
>
> Report the name of the E
(1):
xen/gntdev: reduce copy batch size to 16
Matt Fleming (1):
Merge branch 'xen/linux-next' into efi/arm-xen
Shannon Zhao (16):
Xen: ACPI: Hide UART used by Xen
xen/grant-table: Move xlated_setup_gnttab_pages to common place
Xen: xlate: Use page_to
s enabled. So it
> sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and
> bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES
> flag is set already.
>
> CC: Matt Fleming
> Signed-off-by: Shannon Zhao
> ---
> v2: rebase it on top of EFI and
r Anvin"
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
Cc:
[ Updated changelog. ]
Signed-off-by: Matt Fleming
---
arch/x86/platform/efi/efi_stub_64.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi_stub_64.S
b/arch/x86/platform/efi/efi_stub_64.
The following changes since commit c10fcb14c7afd6688c7b197a814358fecf244222:
x86/sysfb_efi: Fix valid BAR address range check (2016-05-05 16:01:00 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent
for you to fetch c
On Fri, 13 May, at 08:23:47AM, Joe Perches wrote:
> On Fri, 2016-05-13 at 17:11 +0200, Xose Vazquez Perez wrote:
> > Matt Fleming wrote:
> >
> > >
> > > Mark reported that having asterisks on the end of directory names
> > > confuses get_maintainer
I've marked this entire series as RFC.
All the diagnostic code is guarded by CONFIG_SCHED_DEBUG, but there
are minimal changes to __schedule() in patch 5 for the !SCHED_DEBUG
case.
Matt Fleming (5):
sched/fair: Update the rq clock before detaching tasks
sched: Add wrappers for lockdep
s
for 'struct rq_flags *'.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Mike Galbraith
Cc: Mel Gorman
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Wanpeng Li
Cc: Luca Abeni
Cc: Yuyang Du
Cc: Byungchul Park
Cc: Rik van Riel
Cc: "Rafael J. Wysocki"
Signed-off-by: Matt
: Frederic Weisbecker
Signed-off-by: Matt Fleming
---
kernel/sched/fair.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 218f8e83db73..02856647339d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8378,6 +8378,8 @@ static void
->clock_skip_update immediately before unpinning the rq
lock.
This will avoid the new warnings which check if update_rq_clock() is
being actively skipped.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Mike Galbraith
Cc: Mel Gorman
Cc: Thomas Gleixner
Signed-off-by: Matt Fleming
---
kernel/sched/core.c
Du
Cc: Byungchul Park
Cc: Rik van Riel
Cc: Frederic Weisbecker
Signed-off-by: Matt Fleming
---
kernel/sched/fair.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7f776a99bde0..217e3a9d78db 100644
u
Cc: "Rafael J. Wysocki"
Signed-off-by: Matt Fleming
---
kernel/sched/core.c | 13 +++---
kernel/sched/sched.h | 70 +++-
2 files changed, 73 insertions(+), 10 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
inde
.
Could you provide some more details in the changelog on why your
machine doesn't boot without this change?
> Signed-off-by: Alex Thorlton
> Cc: Dimitri Sivanich
> Cc: Russ Anderson
> Cc: Mike Travis
> Cc: Matt Fleming
> Cc: Borislav Petkov
> Cc: Thomas Glei
On Thu, 12 May, at 08:48:35AM, Ingo Molnar wrote:
>
> * Alex Thorlton wrote:
>
> > The efi_call assembly code has a slight error that prevents us from
> > using arguments 7 and higher, which will be passed in on the stack.
> >
> > mov (%rsp), %rax
> > mov 8(%rax), %rax
> > .
he 6th argument
> to the EFI runtime function that we're about to call. This change gets
> our EFI runtime calls that need to pass more than 6 arguments working
> again.
>
> Signed-off-by: Alex Thorlton
> Cc: Dimitri Sivanich
> Cc: Russ Anderson
> Cc: Mike Travis
On Tue, 10 May, at 07:43:14PM, Peter Zijlstra wrote:
> A recent commit caused an interactivity/starvation issue because we wrecked rq
> local wakeup preemption.
>
> These patches rectify this while also (hopefully) keeping the problem that led
> to the fault patch fixed.
>
> Mike, Pavan, could yo
On Tue, 10 May, at 07:43:15PM, Peter Zijlstra wrote:
> Since I want to make ->task_woken() conditional on the task getting
> migrated, we cannot use it to call record_wakee().
You mean ->task_waking(), right?
On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote:
>
> As said above, I will rebase this patch on top of the EFI next branch.
OK thanks.
Note that it is not possible to escape merge conflicts, since there
are changes in the xen tip tree that are not in the EFI next branch
and vice versa.
For ex
On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote:
> >
> > Also, why do you need to setup efi.runtime_version here? Isn't that
> > done inside uefi_init()?
> >
> I don't see any codes which setup efi.runtime_version in uefi_init().
Look in the EFI tree,
https://git.kernel.org/cgit/linux/ker
On Wed, 11 May, at 07:37:52PM, Peter Zijlstra wrote:
> On Wed, May 11, 2016 at 12:55:56PM +0100, Matt Fleming wrote:
>
> > This breaks my POWER7 box which presumably doesn't have
> > SD_SHARE_PKG_RESOURCES,
>
> > index 978b3ef2d87e..d27153adee4d 100644
> &g
On Tue, 10 May, at 10:40:22AM, Jeremy Compostella wrote:
> Why not. See patch as attachment.
>
> Thanks,
>
> Jérémy
>
> From 8a9b07e2d7242fa8a36157f1025202a96c3c7c9a Mon Sep 17 00:00:00 2001
> From: Jeremy Compostella
> Date: Tue, 10 May 2016 10:34:21 +0200
> Subject: [PATCH] efibc: report th
On Fri, 06 May, at 09:52:42AM, Mathieu Poirier wrote:
> > +static int __init efi_remap_init(void)
> > +{
> > + u64 mapsize;
> > +
> > + pr_info("Remapping and enabling EFI services.\n");
> > +
> > + mapsize = memmap.map_end - memmap.map;
> > + memmap.map = (__force void *)io
OK to force enable EFI runtime services for Xen?
I think it would also be good to explicitly state that we do not
expect to find both Xen EFI DT parameters and bare metal EFI DT
parameters when performing the search; the two should be mutually
exclusive.
> CC: Matt Fleming
> Signed-off-b
On Mon, 09 May, at 12:48:11PM, Peter Zijlstra wrote:
> Move the nr_busy_cpus thing from its hacky sd->parent->groups->sgc
> location into the much more natural sched_domain_shared location.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> include/linux/sched.h|1 +
> kernel/sched/core.c
On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote:
> The EFI tables are not encrypted and need to be accessed as such. Be sure
> to memmap them without the encryption attribute set. For EFI support that
> lives outside of the arch/x86 tree, create a routine that uses the __weak
> attribute so that
On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote:
>
> If you think we're violating EFI rules by accessing these registers from
> both sides of the fence, please let me know. I'd like to make sure that
> we get everything behaving the way it should be!
Oh no, I don't think this is violating the
Commit-ID: fb7a84cac03541f4da18dfa25b3f4767d4efc6fc
Gitweb: http://git.kernel.org/tip/fb7a84cac03541f4da18dfa25b3f4767d4efc6fc
Author: Matt Fleming
AuthorDate: Fri, 6 May 2016 22:39:29 +0100
Committer: Ingo Molnar
CommitDate: Sat, 7 May 2016 07:06:13 +0200
efi/capsule: Move 'ca
Commit-ID: 62075e581802ea1842d5d3c490a7e46330bdb9e1
Gitweb: http://git.kernel.org/tip/62075e581802ea1842d5d3c490a7e46330bdb9e1
Author: Matt Fleming
AuthorDate: Fri, 6 May 2016 22:39:27 +0100
Committer: Ingo Molnar
CommitDate: Sat, 7 May 2016 07:06:13 +0200
efi/capsule: Make
From: Peter Jones
There are no callers except through the file_operations struct below
this, so it should be static like everything else here.
Signed-off-by: Peter Jones
Signed-off-by: Matt Fleming
---
fs/efivarfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs
duplicating the lock code.
Signed-off-by: Julia Lawall
Cc: Ard Biesheuvel
Cc: Matthew Garrett
Cc: Jeremy Kerr
Cc: Vaishali Thakkar
Cc: Saurabh Sengar
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/efivars.c | 5 ++---
drivers/firmware/efi/vars.c| 23 ++-
fs/efivarfs
to call kmalloc() since the object
we allocate isn't very big and doesn't need to persist after the
function returns.
Place 'capsule' on the stack instead.
Suggested-by: Ard Biesheuvel
Acked-by: Ard Biesheuvel
Reported-by: Dan Carpenter
Cc: Borislav Petkov
Cc: Kweh
efi_capsule_pending() was grabbing a mutex in the emergency
reboot path - Matt Fleming
* Fix a compiler warning about excessive stack usage in the new efibc
driver by kmalloc'ing the efivar_entry object - Jeremy Compostella
* Dan Carpenter reported that it's potentially unsafe to pass the
ad
kov
Cc: Kweh Hock Leong
Cc: Ard Biesheuvel
Cc: Bryan O'Donoghue
Cc: joeyli
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/capsule.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware
ngo Molnar
Reported-by: Arnd Bergmann
Signed-off-by: Jeremy Compostella
Cc: Ard Biesheuvel
[ Updated changelog to include gcc error ]
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/efibc.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git
On Wed, 04 May, at 12:37:01PM, Peter Zijlstra wrote:
>
> tbench wants select_idle_siblings() to just not exist; it goes happy
> when you just return target.
I've been playing with this patch a little bit by hitting it with
tbench on a Xeon, 12 cores with HT enabled, 2 sockets (48 cpus).
I see a
On Thu, 05 May, at 02:27:16PM, Kweh, Hock Leong wrote:
>
> If not mistaken, the EFI firmware will not update a partially uploaded binary
> due to checksum error.
> User is required to re-update the efi capsule again on the next boot up.
Ah, so the capsule is only processed by the firmware after
frame buffer address range without testing later BARs.
Signed-off-by: Wang YanQing
Reviewed-by: Peter Jones
Cc: David Herrmann
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Tomi Valkeinen
Cc:
[ Rewrote changelog. ]
Signed-off-by: Matt Fleming
---
arch/x86/kernel/s
Folks, please pull the following with from Wang which includes a
rewritten changelog as compared with the previous pull request.
The following changes since commit 04974df8049fc4240d22759a91e035082ccd18b4:
Linux 4.6-rc6 (2016-05-01 15:52:31 -0700)
are available in the git repository at:
git
Commit-ID: b52fad2db5d792d89975cebf2fe1646a7af28ed0
Gitweb: http://git.kernel.org/tip/b52fad2db5d792d89975cebf2fe1646a7af28ed0
Author: Matt Fleming
AuthorDate: Tue, 3 May 2016 20:46:54 +0100
Committer: Ingo Molnar
CommitDate: Thu, 5 May 2016 09:41:09 +0200
sched/fair: Update rq clock
On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
>
> Blergh.
Wilson, Bryan, what kind of rollback support does the Intel Quark have
if its firmware update is interrupted?
The interruption could be for a number of reasons including power
loss, or the example in this case, rebooting due to pa
On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
> On Wed, May 04, 2016 at 12:46:05PM +0100, Matt Fleming wrote:
> > But emergency_restart() is called after bust_spinlocks(0) which can
> > reset oops_in_progress, so can't even use that to solve the panic
> > case.
&g
On Wed, 04 May, at 11:30:31AM, Borislav Petkov wrote:
>
> Hmmm, so panic() does bust_spinlocks() and efi_capsule_pending() could
> look at oops_in_progress which is set by bust_spinlocks() and that would
> probably solve the panic case but maybe the normal reboot case would
> still hang...
But e
On Tue, 03 May, at 09:45:22AM, Shannon Zhao wrote:
> > +static int __init fdt_find_uefi_params(unsigned long node, const char
> > *uname,
> > + int depth, void *data)
> > +{
> > + struct param_info *info = data;
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_
arger-than=]
2048 bytes of the stack are consumed by the node ID array 'nasids[]'.
But we don't actually need to put the ID array on the stack and can
use nodemask operations.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Bjorn Helgaas
Signed-off-by: Matt Fleming
---
arch/ia64/sn/
ized in this function [-Wmaybe-uninitialized]
res->end = addr + size;
^
'addr' is indeed uninitialised and the correct value to use is
res->start.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Bjorn Helgaas
Signed-off-by: Matt Fleming
---
arch/ia64/sn/kernel/io
arch/ia64/kernel/unaligned.c: In function 'ia64_handle_unaligned':
arch/ia64/kernel/unaligned.c:1385:16: warning: 'u.l' may be used
uninitialized in this function [-Wmaybe-uninitialized]
opcode = (u.l >> IA64_OPCODE_SHIFT) & IA64_OPCODE_MASK;
arch/ia64/kernel/traps.c: In function 'ia64_fault':
arch/ia64/kernel/traps.c:433:17: warning: 'siginfo.si_code' may be used
uninitialized in this function [-Wmaybe-uninitialized]
struct siginfo siginfo;
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Bjorn Helgaas
Signed-
I routinely build ia64 kernels when merging EFI patches and for a
while now I've seen a bunch of warnings from GCC.
These patches silence those warnings, with the first patch fixing an
actual bug but the rest just making GCC happier.
NOTE: None of these patches have been runtime tested.
n/kernel/io_acpi_init.c:429:16: warning: unused variable 'addr'
[-Wunused-variable]
void __iomem *addr;
^
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Bjorn Helgaas
Signed-off-by: Matt Fleming
---
arch/ia64/sn/kernel/io_acpi_init.c | 1 -
1 file changed, 1 deletion(-)
diff --
On Wed, 04 May, at 12:23:40PM, Ingo Molnar wrote:
>
> * Matt Fleming wrote:
>
> > On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote:
> > >
> > > * Matt Fleming wrote:
> > >
> > > > From: Wang YanQing
> > > >
> > >
On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote:
>
> * Matt Fleming wrote:
>
> > From: Wang YanQing
> >
> > We can't just break out when meet start is equal to zero,
>
> Hm, wot?
The existing code treats address 0x0 as invalid for a PCI BAR range
start
Commit-ID: e8dfe6d8f6762d515fcd4f30577f7bfcf7659887
Gitweb: http://git.kernel.org/tip/e8dfe6d8f6762d515fcd4f30577f7bfcf7659887
Author: Matt Fleming
AuthorDate: Tue, 3 May 2016 20:29:39 +0100
Committer: Ingo Molnar
CommitDate: Wed, 4 May 2016 08:36:44 +0200
MAINTAINERS: Remove asterisk
n
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Rik van Riel
Signed-off-by: Matt Fleming
---
kernel/sched/fair.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b8a33abce650..aa9ba82f0d7c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/f
ange is valid without test
later BARs.
Signed-off-by: Wang YanQing
Reviewed-by: Peter Jones
Cc: David Herrmann
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Tomi Valkeinen
Cc:
[ Updated changelog ]
Signed-off-by: Matt Fleming
---
arch/x86/kernel/sysfb_efi.c | 1
b not work on some the ThinkPad E550 - Wang YanQing
* Update the MAINTAINERS entry for EFI by removing the trailing
asterisk characters which was intended to denote "all
subdirectories" but which breaks get_maintainer.pl - Matt Fleming
* Convert ACPI BGRT driver messages from p
roken when the 'quiet' kernel
parameter is specified. Ironic, considering BGRT is supposed to
make boot pretty to begin with.
Signed-off-by: Josh Boyer
Reviewed-by: Josh Triplett
Cc: Môshe van der Sterre
Signed-off-by: Matt Fleming
---
arch/x86/platform/efi/efi-bgrt.c | 18 ++
Mark reported that having asterisks on the end of directory names
confuses get_maintainer.pl when it encounters subdirectories, and that
my name does not appear when run on drivers/firmware/efi/libstub.
Reported-by: Mark Rutland
Cc: Ard Biesheuvel
Cc: Catalin Marinas
Cc:
Signed-off-by: Matt
On Tue, 03 May, at 01:47:04PM, Josh Boyer wrote:
> The promise of pretty boot splashes from firmware via BGRT was at
> best only that; a promise. The kernel diligently checks to make
> sure the BGRT data firmware gives it is valid, and dutifully warns
> the user when it isn't. However, it does so
On Thu, 21 Apr, at 03:24:29PM, Julia Lawall wrote:
> The parameters atomic and duplicates of efivar_init always have opposite
> values. Drop the parameter atomic, replace the uses of !atomic with
> duplicates, and update the call sites accordingly.
>
> The code using duplicates is slightly reorga
gt;
> > Signed-off-by: Wang YanQing
>
> This looks correct to me:
>
> Reviewed-By: Peter Jones
>
> Cc'ing Matt Fleming, since this should probably go through the EFI tree.
Applied, thanks.
On Mon, 02 May, at 09:56:09AM, Jeremy Compostella wrote:
>
> Please find the updated patch in attachment.
Thanks Jeremy. Applied.
On Tue, 03 May, at 11:02:29AM, Borislav Petkov wrote:
> On Sat, Apr 30, 2016 at 11:13:27PM +0100, Matt Fleming wrote:
> > Taking a mutex in the reboot path is bogus because we cannot sleep
> > with interrupts disabled, such as when rebooting due to panic(),
> >
> > [
On Sun, 01 May, at 10:36:51PM, Shannon Zhao wrote:
> So is there any other way you suggest?
Would this work (compile tested but not runtime tested)?
---
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3a69ed5ecfcb..13d8be16447a 100644
--- a/drivers/firmware/efi/efi.c
+
On Sun, 01 May, at 11:24:18AM, Shannon Zhao wrote:
> Because the UEFI params for Dom0 are located under /hypervisor/uefi node
> instead of /chosen. So it needs to check whether it's a Dom0 then search
> and parse different node with different params arrays.
Why can't you search both nodes? Would
On Sun, 01 May, at 10:03:55AM, Ard Biesheuvel wrote:
>
> Apologies for only mentioning this now, but I wonder why we need this
> in the kernel in the first place? The UEFI spec defines 'BootNext' as
> the way to set the boot entry for the next boot only, and this could
> also be set from userland.
On Sun, 01 May, at 01:25:12AM, Arnd Bergmann wrote:
> On Saturday 30 April 2016 23:46:41 Matt Fleming wrote:
> >
> > > It's not something we'd have to worry about in practice, but it does
> > > make my patch incorrect. Should we come up with a differen
On Sun, 01 May, at 12:34:29AM, Arnd Bergmann wrote:
>
> The sys_restart() system call takes a mutex before calling kernel_restart()
> or kernel_poweroff().
>
> I've had a closer look now and found that there are a few other
> callers of kernel_restart, so I guess if you restart using sysctl
> at
(Adding Colin and Ricardo)
On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote:
>
> How is an end user supposed to see such a message and report it to the
> people that can fix it? They can't. So they report it in their
> distributions bug tracker and it either gets closed as "yeah, firmware
> suck
avoiding a race where system_state is updated
while we're in the middle of efi_capsule_update_locked() (since CPUs
won't have been stopped at that point).
Cc: Borislav Petkov
Cc: Kweh Hock Leong
Cc: Ard Biesheuvel
Cc: Bryan O'Donoghue
Cc: joeyli
Signed-of
On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote:
>
> You can see here that we've made it past the MMR read in uv_system_init,
> but we die inside of our first EFI callback. In this example, it looks
> like we're using the kernel page table at the time of the failure, and I
> believe that the f
401 - 500 of 2035 matches
Mail list logo
