Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/pasemi
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Santosh Shilimkar
Signed-off-by: Viresh Kumar
---
This tries to remove code redundancy from cpufreq driver by moving some common
part of them to the core. Each driver calls cpufreq_frequency_table_target() to
get a suitable index for a target frequency and then works on it. Its better to
do this at core level before calling cpufreq driver and henc
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Guan Xuetao
Signed-off-by: Viresh Kumar
---
drive
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Stephen Warren
Signed-off-by: Viresh Kumar
---
dr
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: spear-de...@list.st.com
Signed-off-by: Viresh Kumar
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Paul Mundt
Cc: linux...@vger.kernel.org
Signed-off-
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/sc520_
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: David S. Miller
Signed-off-by: Viresh Kumar
---
d
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: David S. Miller
Cc: sparcli...@vger.kernel.org
Sign
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
driver
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Dmitry Eremin-Solenikov
Signed-off-by: Viresh Kumar
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
driver
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Tony Luck
Signed-off-by: Viresh Kumar
---
drivers
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/ppc-co
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Eric Miao
Signed-off-by: Viresh Kumar
---
drivers
On Wed, Aug 7, 2013 at 11:46 AM, Michael Ellerman
wrote:
> On powerpc we build kvmtool as a 64bit binary. We do that by setting
> -m64 in our CFLAGS. For most things we just call $(CC) and it passes
> that info onto the linker.
>
> However there is one place where we explicitly call the linker, in
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/powern
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: David S. Miller
Signed-off-by: Viresh Kumar
---
d
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/pcc-cp
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Shawn Guo
Signed-off-by: Viresh Kumar
---
drivers
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: John Crispin
Signed-off-by: Viresh Kumar
---
driv
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/ppc_cb
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
driver
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Andrew Lunn
Signed-off-by: Viresh Kumar
---
drive
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/longha
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/elanfr
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/pmac32
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Jesper Nilsson
Cc: Mikael Starvik
Cc: linux-cris-k
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Hans-Christian Egtvedt
Signed-off-by: Viresh Kumar
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Linus Walleij
Signed-off-by: Viresh Kumar
---
dri
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/acpi-c
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Steven Miao
Signed-off-by: Viresh Kumar
---
drive
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Sekhar Nori
Signed-off-by: Viresh Kumar
---
drive
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/arm_bi
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/e_powe
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines for this driver.
Cc: Shawn Guo
Signed-off-by: Viresh Kumar
---
drivers
Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if
they have called cpufreq_frequency_table_get_attr() in their init path.
This driver was missing this part and is fixed with this patch.
Cc: Steven Miao
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/blackfin-cpufr
Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if
they have called cpufreq_frequency_table_get_attr() in their init path.
This driver was missing this part and is fixed with this patch.
Cc: Eric Miao
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/pxa2xx-cpufreq.c
Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if
they have called cpufreq_frequency_table_get_attr() in their init path.
This driver was missing this part and is fixed with this patch.
Cc: David S. Miller
Cc: sparcli...@vger.kernel.org
Signed-off-by: Viresh Kumar
Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if
they have called cpufreq_frequency_table_get_attr() in their init path.
This driver was missing this part and is fixed with this patch.
Cc: Santosh Shilimkar
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/omap-cpu
Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if
they have called cpufreq_frequency_table_get_attr() in their init path.
This driver was missing this part and is fixed with this patch.
Cc: John Crispin
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/loongson2_cpu
Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if
they have called cpufreq_frequency_table_get_attr() in their init path.
This driver was missing this part and is fixed with this patch.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/exynos5440-cpuf
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch introduces generic .attr, .exit() and .verify() cpufreq drivers.
Cc: Andrew Lunn
Cc: David S. Miller
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patchset first fixes all existing drivers to do
cpufreq_frequency_table_put_attr() corresponding to
cpufreq_
In vma_adjust, the current code grabs i_mmap_mutex before calling
vma_adjust_trans_huge. This used to be fine until huge page in page
cache comes in. The problem is the underlying function
split_file_huge_page will also grab the i_mmap_mutex before splitting
the huge page in page cache. Obviously t
On Fri, 2013-08-09 at 21:42 -0700, H. Peter Anvin wrote:
> On 08/09/2013 04:04 PM, Andi Kleen wrote:
> >
> > This patch kit is an attempt to get us back to sane code,
> > mostly by doing proper inlining and doing sleep checks in the right
> > place. Unfortunately I had to add one tree sweep to a
On 08/09/2013 04:04 PM, Andi Kleen wrote:
>
> This patch kit is an attempt to get us back to sane code,
> mostly by doing proper inlining and doing sleep checks in the right
> place. Unfortunately I had to add one tree sweep to avoid an nasty
> include loop.
>
> It costs a bit of text space, but
Hi, Steven
I was considering rtmutex's lock->wait_lock is a scheduler lock,
But it is not, and it is just a spinlock of process context.
I hope you change it to a spinlock of irq context.
1) it causes rcu read site more deadlockable, example:
x is a spinlock of softirq context.
CPU1
On 10 August 2013 03:38, Stephen Warren wrote:
> Well, I don't see any issues running this, although the cpufreq sysfs
> files seem to have disappeared on Tegra, even without your changes, so
> I'm not sure how to really verify cpufreq.
>
> Did the sysfs files go away, or do I need to investigate
On 10 August 2013 05:56, Yinghai Lu wrote:
> from your pm/linux-next
>
>
> [7.918603] calling acpi_cpufreq_init+0x0/0x1df @ 1
> [7.923917] BUG: unable to handle kernel NULL pointer dereference
> at (null)
> [7.926780] IP: [] __list_del_entry+0xb7/0xe0
> [7.927799] PGD 0
On Fri, Aug 9, 2013 at 7:10 PM, Yinghai Lu wrote:
> On Fri, Aug 9, 2013 at 6:19 PM, Dave Hansen wrote:
>> On 08/09/2013 04:23 PM, Yinghai Lu wrote:
>>> On Fri, Aug 9, 2013 at 4:18 PM, Dave Hansen wrote:
I'm getting a 100% reproducible panic early in boot:
>> ...
> early console in setup
2013/8/10 Mark Brown :
> On Sat, Aug 10, 2013 at 12:25:58AM +0800, Axel Lin wrote:
>
>> -MODULE_AUTHOR("S Twiss ");
>> +MODULE_AUTHOR("Steve Twiss ");
>
> It's perfectly reasonable for someone to want to be referred to by their
> initial, or their full spelled out name, or a nickname, or...
Oh, I
On Sat, 2013-08-10 at 01:29 +0200, Rafael J. Wysocki wrote:
> On Friday, August 09, 2013 04:16:56 PM Toshi Kani wrote:
> > On Fri, 2013-08-09 at 15:28 +0800, Tang Chen wrote:
> > > On 08/07/2013 12:56 AM, Toshi Kani wrote:
> > > > On Tue, 2013-08-06 at 19:11 +0900, Yasuaki Ishimatsu wrote:
> > > >>
On Fri, Aug 9, 2013 at 6:19 PM, Dave Hansen wrote:
> On 08/09/2013 04:23 PM, Yinghai Lu wrote:
>> On Fri, Aug 9, 2013 at 4:18 PM, Dave Hansen wrote:
>>> I'm getting a 100% reproducible panic early in boot:
> ...
early console in setup code
[0.00] Initializing cgroup subsys cpuse
On Sat, Aug 10, 2013 at 9:26 AM, zhangwei(Jovi) wrote:
> On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>>
>> Sorry, I didn't read this series yet. Not that I think this needs my
>> help, but I'll try to do this a later...
>>
>> On 08/09, Masami Hiramatsu wrote:
>> >
>> > I just concern u
On Friday, August 09, 2013 05:50:45 PM Yinghai Lu wrote:
> On Fri, Aug 9, 2013 at 5:26 PM, Yinghai Lu wrote:
> > from your pm/linux-next
> >
> >
> > [7.918603] calling acpi_cpufreq_init+0x0/0x1df @ 1
> > [7.923917] BUG: unable to handle kernel NULL pointer dereference
> > at (nu
On Sat, Aug 10, 2013 at 12:20 AM, Oleg Nesterov wrote:
>
> Sorry, I didn't read this series yet. Not that I think this needs my
> help, but I'll try to do this a later...
>
> On 08/09, Masami Hiramatsu wrote:
> >
> > I just concern using kmalloc() in the event handler.
>
> GFP_KERNEL should be fin
On 08/09/2013 04:23 PM, Yinghai Lu wrote:
> On Fri, Aug 9, 2013 at 4:18 PM, Dave Hansen wrote:
>> I'm getting a 100% reproducible panic early in boot:
...
>>> early console in setup code
>>> [0.00] Initializing cgroup subsys cpuset
>>> [0.00] Initializing cgroup subsys cpu
>>> [
From: David Daney
When CONFIG_USB_SUPPORT is not selected we get things like:
scripts/kconfig/mconf Kconfig
warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects
USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT &&
USB)
It is much cleaner to make the various sy
On Sat, 10 Aug 2013, Thomas Richter wrote:
> Hi Alan,
>
> >> Will try and report back, thanks. I've bisected it down in the meantime
> >> to a change from 2.6.31.6 to 2.6.32.6. Interestingly, this is very much
> >> the same time when the udev userland changed. It works with 2.6.31.6 old
> >> udev
On Fri, 9 Aug 2013, David Daney wrote:
> From: David Daney
>
> When CONFIG_USB_SUPPORT is not selected we get things like:
>
> scripts/kconfig/mconf Kconfig
> warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects
> USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPO
On Fri, Aug 9, 2013 at 5:26 PM, Yinghai Lu wrote:
> from your pm/linux-next
>
>
> [7.918603] calling acpi_cpufreq_init+0x0/0x1df @ 1
> [7.923917] BUG: unable to handle kernel NULL pointer dereference
> at (null)
> [7.926780] IP: [] __list_del_entry+0xb7/0xe0
> [7.927799]
Update the patch according to Naoya's comment, I also run
./scripts/checkpatch.pl, and it passed ;D.
>From 96826b0fdf9ec6d6e16c2c595f371dbb841250f7 Mon Sep 17 00:00:00 2001
From: Yonghua Zheng
Date: Mon, 5 Aug 2013 12:12:24 +0800
Subject: [PATCH 1/1] pagemap: fix buffer overflow in add_to_pagemap
On 08/07/2013 09:12 AM, Srinivas Pandruvada wrote:
Overview
With the evolution of technologies, which enables power monitoring and limiting,
more and more devices are able to constrain their power consumption under
certain
limits. There are several use cases for such technologies:
- Power monito
from your pm/linux-next
[7.918603] calling acpi_cpufreq_init+0x0/0x1df @ 1
[7.923917] BUG: unable to handle kernel NULL pointer dereference
at (null)
[7.926780] IP: [] __list_del_entry+0xb7/0xe0
[7.927799] PGD 0
[7.927799] Oops: [#1] SMP
[7.927799] Modules
From: David Daney
When CONFIG_USB_SUPPORT is not selected we get things like:
scripts/kconfig/mconf Kconfig
warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects
USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT &&
USB)
It is much cleaner to make the various sy
On 08/07/2013 02:56 PM, Linus Torvalds wrote:
>
> Both of the biased cases *might* also want things like "save register
> state in the unlikely path so that the *likely* path doesn't have to".
> Think things like "it's a leaf function, and the likely path doesn't
> need any temporaries, but the un
On Thu, 2013-08-08 at 07:50 +0200, leroy christophe wrote:
> Le 26/06/2013 01:04, Scott Wood a écrit :
> > What happens if there's a race? If another CPU updates wdt_last_ping in
> > parallel, then you could see wdt_last_ping greater than the value you
> > read for jiffies. Since this is an unsig
The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095:
Linux 3.11-rc3 (2013-07-28 20:53:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
tags/staging-3.11-rc5
for you to fetch changes up to cefe8a32f2a
The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-3.11-rc5
for you to fetch changes up to 444ce9d44d00969479a
Hi Randy,
On Fri, 09 Aug 2013 09:53:36 -0700 Randy Dunlap
wrote:
>
> and if you are not using git but are using tarballs instead,
> where is the patch file?
Yeah, sorry I did not notice the error from kup. It should be there now.
--
Cheers,
Stephen Rothwells...@canb.auug.o
On Fri, Aug 09, 2013 at 04:35:16PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >Good protocols exist, look at protobufs from Google if you want to
> >define your own. Never create your own protocol these days, it doesn't
> >make sense, be it a text one or something else.
>
> OK. I was
On Fri, Aug 09, 2013 at 09:38:47PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
> > If someone wants to it should also be possible to convert the existing
> > platforms without S/PDIF support over to DT, providing you don't mind
> > changing
On Tue, Aug 06, 2013 at 01:26:34AM +0900, Minchan Kim wrote:
> On Mon, Aug 05, 2013 at 04:18:34PM +0900, Minchan Kim wrote:
> > I was preparing to promote zram and it was almost done.
> > Before sending patch, I tried to test and eyebrows went up.
> >
> > [1] introduced down_write in zram_slot_fre
Greg Kroah-Hartman wrote:
Good protocols exist, look at protobufs from Google if you want to
define your own. Never create your own protocol these days, it doesn't
make sense, be it a text one or something else.
OK. I was using the term in the broader sense in which _meaning_ is
assigned to t
On Fri, Aug 9, 2013 at 2:41 AM, Tang Chen wrote:
> On 08/09/2013 12:29 AM, Yinghai Lu wrote:
> ..
>
>>
>> Please check if you can reuse first half of my patchset, so find and copy
>> override table earlier. the copied acpi tables could be near kernel code
>> range.
>>
>
> I don't think we need
On Fri, Aug 09, 2013 at 04:21:42PM -0700, Guenter Roeck wrote:
> On 08/09/2013 12:11 PM, Greg Kroah-Hartman wrote:
> >On Thu, Aug 08, 2013 at 11:57:55PM -0700, Guenter Roeck wrote:
> >>On 08/08/2013 06:56 PM, Greg Kroah-Hartman wrote:
> >>>This is the start of the stable review cycle for the 3.10.6
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 40cd16e..1d0a079 100644
--- a/drivers/firmware/efi/ef
Rename them to be more similar, as low_free() could be used to free
memory allocated by both high_alloc() and low_alloc().
high_alloc() -> efi_high_alloc()
low_alloc() -> efi_low_alloc()
low_free() -> efi_free()
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 19 ++
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 38 +++--
drivers/firmware/efi/efi-stub-helper.c | 96 +---
2 files changed, 72 insertions(+), 62 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eb
This #define is only used the the shared code, so move
it there.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.h |1 -
drivers/firmware/efi/efi-stub-helper.c |2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.h b/arch/x
The existing code could fail to allocate depending
on allocation size, as although repeated allocation
attempts were made, none were guaranteed to be page
aligned.
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c | 14 ++
1 file changed, 14 insertions(+)
diff
The handle_cmdline_files now takes the option to handle as a string,
and returns the loaded data through parameters, rather than taking
an x86 specific setup_header structure. For ARM, this will be used
to load a device tree blob in addition to initrd images.
Signed-off-by: Roy Franz
---
arch/x
Rename variables to be not initrd specific, as now the function
loads arbitrary files.
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c | 92
1 file changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper
2 unused labels
1 "value computed is not used"
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 4bb542f..3e82cb0 10
The x86/AMD64 EFI stubs must us a call wrapper to convert between
the Linux and EFI ABIs, so void pointers are sufficient. For ARM,
the ABIs are compatible, so we can directly invoke the function
pointers. The functions that are used by the ARM stub are updated
to match the EFI definitions.
Sign
Make efi_free() safely callable with size of 0, similar to free() being
callable with NULL pointers.
Remove size checks that this makes redundant. This also avoids some
size checks in the ARM EFI stub code that will be added as well.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c
Signed-off-by: Roy Franz
---
arch/arm/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 43594d5..8607d03 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1805,6 +1805,17 @@ config UACCESS_WITH_MEMCPY
However, if
EFI calls can made directly on ARM, so the function pointers
are directly invoked. This allows types to be checked at
compile time, so here we ensure that the parameters match
the function signature.
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c | 15 +--
1 f
This patch series adds EFI stub support for the ARM architecture.
Some code that was previously only used by x86/x86_64 is now shared
and has been made more general. The stub for ARM is implemented in
a similar manner to x86 in that it is a shim layer between EFI and
the normal zImage/bzImage boo
No code changes made, just moving functions from x86 arch directory
to common location.
Code is shared using #include, similar to how decompression code
is shared among architectures.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 442 +-
arch/
This allows allocations to be made low in memory while
avoiding allocations at the base of memory.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 11 ++-
drivers/firmware/efi/efi-stub-helper.c |7 +--
2 files changed, 11 insertions(+), 7 deletions(-)
dif
The shared efi-stub-helper.c functions require a strstr
implementation.
Implementation copied from arch/x86/boot/string.c
Signed-off-by: Roy Franz
---
arch/arm/boot/compressed/string.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/compressed/string.c
This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
operations similarly to the x86 stub: it is a shim between the EFI firmware
and the normal zImage entry point, and sets up the environment that the
zImage is expecting. This includes loading the initrd (optionaly) and
device
a
> couple of config options that need to get set just right to trigger it,
> but CONFIG_DEBUG_PAGEALLOC seems to be the main one. Full config is here:
>
> http://sr71.net/~dave/intel/foo/config-bigbox-crash-20130809.txt
>
> I bisected it back to this commit (wh
On 08/09/2013 12:11 PM, Greg Kroah-Hartman wrote:
On Thu, Aug 08, 2013 at 11:57:55PM -0700, Guenter Roeck wrote:
On 08/08/2013 06:56 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.10.6 release.
There are 102 patches in this series, all will be posted as a r
On Friday, August 09, 2013 04:16:56 PM Toshi Kani wrote:
> On Fri, 2013-08-09 at 15:28 +0800, Tang Chen wrote:
> > On 08/07/2013 12:56 AM, Toshi Kani wrote:
> > > On Tue, 2013-08-06 at 19:11 +0900, Yasuaki Ishimatsu wrote:
> > >> try_offline_node() checks that all cpus related with removed node hav
to trigger it,
but CONFIG_DEBUG_PAGEALLOC seems to be the main one. Full config is here:
http://sr71.net/~dave/intel/foo/config-bigbox-crash-20130809.txt
I bisected it back to this commit (which I seem to remember causing some
other probems):
> commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
>
On Wed, 07 Aug 2013 14:26:18 +0900 Joonyoung Shim
wrote:
> In struct gen_pool_chunk, end_addr means ending address of memory chunk,
> but actually it is starting address + size of memory chunk in codes, so
> it points the address increased one instead of correct ending address.
>
> The ending a
1 - 100 of 579 matches
Mail list logo
