On Apr 25, 2013, at 2:19 PM, "bfie...@fieldses.org"
wrote:
> On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote:
>> On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.org wrote:
>>> On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote:
On Thu, 2013-04-25 at
Rob,
Can I get your ack on this binding or do you think we need to change
something?
Thanks,
Stephen
On 04/15/13 14:33, Stephen Boyd wrote:
> On 04/15/13 14:20, Rob Herring wrote:
>> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd wrote:
>>> @@ -26,3 +30,52 @@ Example:
>>>
On Thu, Apr 25, 2013 at 09:13:32AM -0700, John Stultz wrote:
> On 04/25/2013 12:11 AM, Alexander Holler wrote:
> >Am 24.04.2013 18:07, schrieb John Stultz:
> >
> >>>And why is RTC_SYSTOHC now gone on x86?
> >>
> >>So summarizing the above, because as much as I'm aware, its always been
>
On 04/17/13 16:26, Stephen Boyd wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
>
> BUG: using smp_processor_id() in preemptible [] code: sh/111
> caller is
On Thu, 25 Apr 2013, Han Pingtian wrote:
> > A dump of the other fields in /sys/kernel/slab/kmalloc*/* would also be
> > useful.
> >
> I have dumpped all /sys/kernel/slab/kmalloc*/* in kmalloc.tar.xz and
> will attach it to this mail.
Ok that looks like a lot of objects were freed from slab
On Thu, Apr 25, 2013 at 01:34:45PM -0400, Jason Cooper wrote:
> On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> > The linux/cpu.h header is no longer implictly included in this
> > file, so we need to an #include statement to avoid this build
> > warning:
> >
> >
On Wed, Apr 24, 2013 at 08:48:13AM +0200, Ingo Molnar wrote:
> These patterns repeated in 4 places really call for a common helper
> defined as print_lockdep_off(fmt...) or so?
>
> (Can be a followup patch if that's easier for you.)
Given there was only one case which was really different,
On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote:
> On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.org wrote:
> > On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote:
> > > On Thu, 2013-04-25 at 09:29 -0400, bfie...@fieldses.org wrote:
> > >
> > > > My position
On 04/25/2013 01:04 PM, Alexandru Copot wrote:
Signed-of-by Alexandru Copot
Cc: Daniel Baluta
---
tools/testing/selftests/Makefile| 3 +-
tools/testing/selftests/lib/Makefile| 14 +++
tools/testing/selftests/lib/selftests.c | 57
On Thu, 25 Apr 2013 17:09:12 +0200
Sebastian Andrzej Siewior wrote:
> On 04/08/2013 10:25 PM, Clark Williams wrote:
> > BTW I imported -rt onto v3.8.6 with no hiccups from 'git
> > quiltimport' other than what you just fixed. Not much runtime on it
> > but it booted without complaint and ran
On 4/25/2013 7:28 PM, Arnd Bergmann wrote:
gcc-3.8 correctly found that the variables set by find_freq_tables()
are not initialized if this function is called on something other
than a pxa2xx or pxa3xx:
pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
pxa2xx-cpufreq.c:272:6: warning:
On 4/25/2013 8:01 AM, Paul Moore wrote:
> On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
>> On 4/24/2013 4:00 PM, John Johansen wrote:
>>> On 04/24/2013 02:15 PM, Paul Moore wrote:
On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
> ...
>
> An interesting
On 04/25/2013 01:11 AM, Takao Indoh wrote:
> (2013/04/25 4:59), Don Dutile wrote:
>> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>>> "pci=pcie_reset_devices" is specified, a hot reset is triggered on each
>>> PCIe root port and
On 04/18/2013 10:40 PM, Dave Hansen wrote:
> On 04/09/2013 02:45 PM, Srivatsa S. Bhat wrote:
>> 2. Performance overhead is expected to be low: Since we retain the simplicity
>>of the algorithm in the page allocation path, page allocation can
>>potentially remain as fast as it would be
On Thu, Apr 25, 2013 at 07:29:01PM +0200, Arnd Bergmann wrote:
> The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
> which is now only visible when USB_PHY is also enabled.
>
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding the
On Thu, 2013-04-25 at 13:59 +0200, richard -rw- weinberger wrote:
> On Thu, Apr 25, 2013 at 1:04 PM, Karel Zak wrote:
> > The util-linux release 2.23 is available at
> >
> >ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.23
> >
> > Feedback and bug reports, as always, are welcomed.
> >
> >
On Thu, Apr 25, 2013 at 10:13:34AM -0400, Eduardo Valentin wrote:
> diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
> b/drivers/thermal/db8500_cpufreq_cooling.c
> index 21419851..786d192 100644
> --- a/drivers/thermal/db8500_cpufreq_cooling.c
> +++ b/drivers/thermal/db8500_cpufreq_cooling.c
On Thu, Apr 25, 2013 at 09:46:16AM -0400, Eduardo Valentin wrote:
> diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
> b/drivers/staging/ti-soc-thermal/ti-bandgap.c
> index f20c1cf..5027833 100644
> --- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
> +++
On Wed, Apr 24, 2013 at 11:11:38AM +0100, Josef Ahmad wrote:
> From 8a4773d0c0df6fe2e816ad37fde30a2d90a1ad31 Mon Sep 17 00:00:00 2001
> From: Josef Ahmad
> Date: Fri, 19 Apr 2013 17:28:10 +0100
> Subject: [PATCH] i2c-designware: fix RX FIFO overrun
>
> i2c_dw_xfer_msg() pushes a number of bytes
Hi Arnd,
I already submitted a patch to fix this.
http://permalink.gmane.org/gmane.linux.kernel.iommu/2036
Regards
Varun
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, April 25, 2013 10:59 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc:
On Thu, Apr 25, 2013 at 07:18:42PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 25, 2013 at 07:00:37PM +0200, Andi Kleen wrote:
> > > Traping the read deals with the first. The second shouldn't be a problem
> > > since
> > > we generally only allow kernel info for CAP_ADMIN; if we don't already
>
On Tue, Apr 23, 2013 at 12:30 PM, Arnd Bergmann wrote:
> The tilcdc driver fails to be built as a module because of extraneous
> MODULE_DEVICE_TABLE entries:
>
> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of
> `__mod_of_device_table'
>
On 04/25, Jacob Shin wrote:
>
> On Thu, Apr 25, 2013 at 05:10:35PM +0200, Oleg Nesterov wrote:
> > On 04/25, Frederic Weisbecker wrote:
> > >
> > > Do we need len and mask to work at the same time? I can't think of a
> > > situation when len and mask mix up together in a useful way to define
> > >
On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote:
> Ben, Can I have your Ack for this? The change is straightforward and
> neither of the 2 drivers used the id parameter that is removed.
Didn't you get my mail about a compile failure caused by this patch ?
Or did you send an update that I
On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> The linux/cpu.h header is no longer implictly included in this
> file, so we need to an #include statement to avoid this build
> warning:
>
> arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function
>
A lot of code uses the functions from of_platform.h when built for
devicetree-enabled platforms but can also be built without them.
In order to avoid using #ifdef everywhere in drivers, this
makes all the function declarations visible, which means we
can use "if (IS_ENABLED(CONFIG_OF))" in driver
The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
and it can be built as a loadable module, which currently fails.
This exports the symbol from the DRM core to avoid
ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!
Signed-off-by: Arnd Bergmann
Cc:
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
Signed-off-by: Arnd Bergmann
Cc: David Airlie
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 3 ++-
1 file changed, 2 insertions(+), 1
The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.
This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding these build errors:
warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet
The s3c24xx_init_intc and s3c2412_init_irq functions are only called
at init time, and they call functions already marked __init, so they
should be marked in the same way. This was reported as
WARNING: vmlinux.o(.text+0x19e0b4): Section mismatch in reference from the
function s3c2412_init_irq()
The newly rewritten get_property() function causes a bogus warning
from gcc-3.8, which cannot figure out that "level" is always
initialized at the point where it gets evaluated:
drivers/thermal/cpu_cooling.c: In function 'get_property':
drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may
When building a kernel using 'make -s', I expect to see an empty output,
except for build warnings and errors. The build_OID_registry code
always prints one line when run, which is not helpful to most people
building the kernels, and which makes it harder to automatically
check for build warnings.
The cpu_topology symbol is required by any driver using the topology
interfaces, which leads to a couple of build errors:
ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
ERROR: "cpu_topology"
Since we now have default implementations for init_time and init_irq,
the init_machine callback is the only one that is not yet optional,
but since simple DT based platforms all have the same
of_platform_populate function call in there, we can consolidate them
as well, and then actually boot with
All other irq_domain_add_* functions are exported already, and apparently
this one got left out by mistake, which causes build errors for ARM
allmodconfig kernels:
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko]
The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
which is now only visible when USB_PHY is also enabled.
This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding the Kbuild warning:
warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
Signed-off-by: Arnd Bergmann
Cc: GOTO Masanori
Cc: YOKOTA Hiroshi
Cc: "James E.J. Bottomley"
Cc: linux-s...@vger.kernel.org
---
drivers/scsi/nsp32.c | 2 +-
1 file changed, 1 insertion(+), 1
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
Signed-off-by: Arnd Bergmann
Cc: Chas Williams
Cc: linux-atm-gene...@lists.sourceforge.net
Cc: net...@vger.kernel.org
---
drivers/atm/he.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi subsystem maintainers,
Here is another set of patches that resulted from build testing on
linux-next. Please apply directly into your trees if you agree,
or let me know if I made a mistake.
I can take whatever remains through the arm-soc tree if you prefer
that or I don't hear back.
The linux/cpu.h header is no longer implictly included in this
file, so we need to an #include statement to avoid this build
warning:
arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function
'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]
Signed-off-by: Arnd
The virt_to_bus/bus_to_virt functions have been deprecated
for as long as I can remember, and they are used in very
few remaining instances, usually in obscure ISA device
drivers. The OSS sound drivers are the only ones that are
still used on the ARM architecture, and only on some of
the earliest
Like the EHCI driver, OHCI supports a large number of different platform
glue drivers by directly including them, which causes problems with
conflicting macro definitions in some cases. As more ARM architecture
specific back-ends are required to coexist in a single build, we should
split those out
The Kconfig entry for USB_OMAP unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.
This adds an appropriate dependency and enables USB_PHY in the omap1
defconfig, avoiding these build warnings:
warning: (USB_OHCI_HCD && USB_OMAP) selects ISP1301_OMAP
The code was recently changed to work for builds with a 64 bit
dma_addr_t, but the printk unconditionally uses a format
string for an "long" variable, which is always wrong as
the dma_add_t is now either 'unsigned int' or 'unsigned long long'
depending on configuration.
The easiest solution is to
The irqchip_init function is only available when building
with CONFIG_OF enabled, which causes this build failure for
bonito_defconfig:
arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
:(.init.text+0x580): undefined reference to `irqchip_init'
This makes both the OF and the
gcc-3.8 correctly found that the variables set by find_freq_tables()
are not initialized if this function is called on something other
than a pxa2xx or pxa3xx:
pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
pxa2xx-cpufreq.c:272:6: warning: 'pxa_freqs_table' may be used uninitialized in
this
On Thu, 2013-04-25 at 21:22 +0800, Herbert Xu wrote:
> Please wrap the generic implementation as we do for crc32c.
>
Herbert,
I've updated this patch to add the generic crct10dif transform (see
below). Let me know if this address your comment. Thanks.
Tim
When CRC T10 DIF is calculated
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
Signed-off-by: Arnd Bergmann
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
---
sound/pci/ali5451/ali5451.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
This new flag SD_SHARE_POWERDOMAIN is used to reflect whether groups of CPUs
in a sched_domain level can or not reach a different power state. If groups of
cores can be power gated independently, as an example, the flag should be
cleared at CPU level. This information is used to decide if it's
Look for an idle CPU close to the pack buddy CPU whenever possible.
The goal is to prevent the wake up of a CPU which doesn't share the power
domain of the pack buddy CPU.
Signed-off-by: Vincent Guittot
Reviewed-by: Morten Rasmussen
---
kernel/sched/fair.c | 19 +++
1 file
There are 3 packing levels:
- the default one only packs the small tasks when the system is not busy
- the none level doesn't pack anything
- the full level uses as few as possible number of CPUs based on the current
activity of the system
Signed-off-by: Vincent Guittot
---
According to the packing policy, the scheduler can pack tasks at different
step:
-SCHED_PACKING_NONE level: we don't pack any task.
-SCHED_PACKING_DEFAULT: we only pack small tasks at wake up when system is not
busy.
-SCHED_PACKING_FULL: we pack tasks at wake up until a CPU becomes full. During
a
We evaluate the activity level of CPUs, groups and domains in order to define
how many CPUs are required to handle the current activity.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/kernel/sched/fair.c
This new field power_available reflects the available capacity of a CPU
unlike the cpu_power which reflects the current capacity.
Signed-off-by: Vincent Guittot
---
include/linux/sched.h |2 +-
kernel/sched/fair.c | 18 +++---
kernel/sched/sched.h |1 +
3 files changed,
The ARM platforms take advantage of packing small tasks on few cores.
This is true even when the cores of a cluster can't be power gated
independantly. So we clear SD_SHARE_POWERDOMAIN at MC and CPU level.
Signed-off-by: Vincent Guittot
Reviewed-by: Morten Rasmussen
---
If the buddy CPU is not full and currently idle, we trigger an Idle Load
Balance to give it the opportunity to pull more tasks.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 24
1 file changed, 24 insertions(+)
diff --git a/kernel/sched/fair.c
The cpu_power is updated for CPUs that don't participate to the packing
effort. We consider that their cpu_power is allocated to idleness as it could
be allocated by rt. So the cpu_power that remains available for cfs, is set to
min value (i.e. 1)
Signed-off-by: Vincent Guittot
---
Periodically updates the buddy of a CPU according to the current activity of
the system. A CPU is its own buddy if it participates to the packing effort.
Otherwise, it points to a CPU that participates to the packing effort.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 91
If a CPU that doesn't participate to the packing effort, has at least one
running task, it means that its group is imbalanced and the CPUs can pull this
task.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/fair.c
Only CPUs that participates to the packing effort can pull tasks on a busiest
group.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 28f8ea7..6f63fb9
During the creation of sched_domain, we define a pack buddy CPU for each CPU
when one is available. We want to pack at all levels where a group of CPUs can
be power gated independently from others.
On a system that can't power gate a group of CPUs independently, the flag is
set at all sched_domain
This reverts commit f4e26b120b9de84cb627bc7361ba43cfdc51341f.
Signed-off-by: Vincent Guittot
---
include/linux/sched.h |8 +---
kernel/sched/core.c |7 +--
kernel/sched/fair.c | 13 ++---
kernel/sched/sched.h |9 +
4 files changed, 5 insertions(+), 32
Hi,
This patchset takes advantage of the new per-task load tracking that is
available in the kernel for packing the tasks in as few as possible
CPU/Cluster/Core. It has got 2 packing modes:
-The 1st mode packs the small tasks when the system is not too busy. The main
goal is to reduce the power
On Wed, Apr 24, 2013 at 9:55 PM, Ram Pai wrote:
> On Wed, Apr 10, 2013 at 09:22:48AM -0600, Bjorn Helgaas wrote:
>> On Mon, Apr 8, 2013 at 10:51 PM, Ram Pai wrote:
>> > On Thu, Apr 04, 2013 at 04:18:01PM -0600, Bjorn Helgaas wrote:
>> >> On Wed, Mar 13, 2013 at 5:27 PM, Yinghai Lu wrote:
>> >>
On Thu, Apr 25, 2013 at 07:00:37PM +0200, Andi Kleen wrote:
> > Traping the read deals with the first. The second shouldn't be a problem
> > since
> > we generally only allow kernel info for CAP_ADMIN; if we don't already for
> > LBR
> > that needs to be fixed separately.
>
> Where is that
On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
>>
>> The downside is that in userland perf tool we need differing documentation
>> on what the mask syntax means for each architecture.
>
> Personally I think this is acceptable.
>
> But I am new to this code, so...
>
That would seem really, really
On Thu, 25 Apr 2013, Han Pingtian wrote:
> I have enabled "slub_debug" and here is the
> /sys/kernel/slab/kmalloc-512/alloc_calls contents:
>
> 50 .__alloc_workqueue_key+0x90/0x5d0 age=113630/116957/119419 pid=1-1730
> cpus=0,6-8,13,24,26,44,53,57,60,68 nodes=1
> 11
The config transactions "scheduler" was hopelessly broken,
repeating completed transaction instead of picking up
next pending one.
Fixed now. Also improved debug messages.
Signed-off-by: Pawel Moll
---
drivers/mfd/vexpress-config.c | 35 +--
1 file changed, 21
On 04/24, Jacob Shin wrote:
>
> And only x86
> hw_breakpoint will know what .config = 0xf means for x86 and do the right
> thing. For ARM, 0xf will mean something different.
>
> The downside is that in userland perf tool we need differing documentation
> on what the mask syntax means for each
On Thu, 2013-04-25 at 18:44 +0200, Sebastian Andrzej Siewior wrote:
> * Steven Rostedt | 2013-04-11 14:33:34 [-0400]:
>
> >Comments?
>
> So you don't mind if I take this for v3.8?
> I fixed
>
> |arch/x86/kernel/cpu/mcheck/mce.c:1392:13: warning: function declaration
> isn’t a prototype
On Thu, 25 Apr 2013, Sedat Dilek wrote:
> > That also looks normal. Did you have CONFIG_USB_DEBUG enabled during
> > this test? If you did, you could try turning it back off to see if the
> > original problem returns while still doing a usbmon trace.
> >
>
> As my system works as "expected"
> Traping the read deals with the first. The second shouldn't be a problem since
> we generally only allow kernel info for CAP_ADMIN; if we don't already for LBR
> that needs to be fixed separately.
Where is that check? I don't see it.
Also remember that precise == 2 can enable LBR implicitly.
> > > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> > >* is required to use VCPUOP_register_vcpu_info to place vcpu info
> > >* for secondary CPUs as they are brought up. */
> > > per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
> > > + for_each_online_cpu(i)
> > > +
Signed-off-by: Stefano Stabellini
---
arch/arm/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..344e299 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1892,6 +1892,7 @@ config XEN
depends on ARM
On Thu, Apr 25, 2013 at 05:10:35PM +0200, Oleg Nesterov wrote:
> On 04/25, Frederic Weisbecker wrote:
> >
> > 2013/4/23 Jacob Shin :
> > > @@ -286,7 +286,10 @@ struct perf_event_attr {
> > > __u64 config1; /* extension of config */
> > > };
> > > union {
>
Signed-off-by: Stefano Stabellini
Reviewed-by: Ian Campbell
---
arch/arm/include/asm/xen/hypercall.h |1 +
arch/arm/xen/enlighten.c |1 +
arch/arm/xen/hypercall.S |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git
xenvm is based on mach-vexpress, move it to mach-virt.
Changes in v4:
- update the dts Makefile too.
Signed-off-by: Stefano Stabellini
CC: Marc Zyngier
CC: will.dea...@arm.com
CC: a...@arndb.de
CC: rob.herr...@calxeda.com
---
arch/arm/boot/dts/Makefile |4 ++--
Signed-off-by: Stefano Stabellini
Acked-by: Marc Zyngier
CC: rob.herr...@calxeda.com
CC: will.dea...@arm.com
CC: a...@arndb.de
---
arch/arm/boot/dts/xenvm-4.2.dts | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/xenvm-4.2.dts
Signed-off-by: Stefano Stabellini
Reviewed-by: Ian Campbell
CC: sta...@vger.kernel.org
---
arch/arm/xen/enlighten.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 8dc0605..99ce189 100644
---
Map vcpu_info using VCPUOP_register_vcpu_info on all the online vcpus,
make sure the allocated struct doesn't cross a page boundary.
Call enable_percpu_irq on every cpu.
Changes in v5:
- allocate xen_vcpu_info dynamically, aligning it to the size of the
struct;
- use VCPUOP_register_vcpu_info on
Changes in v5:
- set pm_power_off and arm_pm_restart from the Xen specific
intialization code.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/enlighten.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/xen/enlighten.c
Hi all,
this patch series, based on 3.9-rc3, moves xenvm to mach-virt,
introduces SMP support in Xen on ARM and implements machine reboot and
power off via Xen sched_op hypercalls.
Each patch comes with a detailed changelog.
The merge window is approaching, this patch series only contains Xen
On Thu, Apr 25, 2013 at 06:41:00PM +0200, Andi Kleen wrote:
> > So why not do the same as we do for userspace? Copy MAX_INSN_SIZE bytes
> > and trap -EFAULT.
>
> Read the whole description, then you'll know why that is insecure.
You didn't actually explicitly mention it; you just said
On Thu, 25 Apr 2013, Ian Campbell wrote:
> On Wed, 2013-04-24 at 20:28 +0100, Stefano Stabellini wrote:
> > Map vcpu_info using VCPUOP_register_vcpu_info on secondary cpus.
> >
> > Call enable_percpu_irq on every cpu.
> >
> > Changed in v2:
> > - move the percpu variable argument fix to a
On 04/24/13 07:59, Rafael J. Wysocki wrote:
[...]
Rafael, please take this patch with my ack in your tree, sorry for noise.
Acked-by: Kukjin Kim
If any problems, please kindly let me know.
Well, I suppose I can take the original patch, but then it will conflict with
your tree during merge.
* Steven Rostedt | 2013-04-11 14:33:34 [-0400]:
>Comments?
So you don't mind if I take this for v3.8?
I fixed
|arch/x86/kernel/cpu/mcheck/mce.c:1392:13: warning: function declaration isn’t
a prototype [-Wstrict-prototypes]
>+static void mce_notify_work()
^^
> So why not do the same as we do for userspace? Copy MAX_INSN_SIZE bytes
> and trap -EFAULT.
Read the whole description, then you'll know why that is insecure.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
* Steven Rostedt | 2013-04-08 15:34:08 [-0400]:
>On Thu, 2013-04-04 at 13:58 +1100, Martin Bohun wrote:
>> The https://www.kernel.org/pub/linux/kernel/projects/rt/3.4/ contains
>> WRONG (3.2, not 3.4) files/patches,
>
>Yep, I screwed up the patch pushing as I rushed to get them released
>before I
On 25.4.2013 15:25, Andi Kleen wrote:
>> Util-linux 2.23 Release Notes
>> =
>>
>> The cryptoloop support in the commands mount(8) and losetup(8) has been
>> REMOVED. The encryption= mount option and -e,-E,--encryption losetup options
>> are no more supported.
>
>
On Tue, Apr 23, 2013 at 04:59:02PM +0200, Vincent Guittot wrote:
> On my smp platform which is made of 5 cores in 2 clusters, I have the
> nr_busy_cpu field of sched_group_power struct that is not null when the
> platform is fully idle. The root cause is:
> During the boot sequence, some CPUs
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
> Possible options:
>
> I) Disable FAR calls for ANY_CALL/RETURNS.
> This just means syscalls are not logged
> as calls. This also lowers the overhead of call logging.
> This changes semantics slightly.
> This is reasonable on Sandy
On 04/25, Oleg Nesterov wrote:
>
> On 04/25, Frederic Weisbecker wrote:
> >
> > 2013/4/23 Jacob Shin :
> > > @@ -286,7 +286,10 @@ struct perf_event_attr {
> > > __u64 config1; /* extension of config */
> > > };
> > > union {
> > > - __u64
Hi Sourav,
Sourav Poddar writes:
> Hi Kevin,
> On Thursday 25 April 2013 03:45 AM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> Remove "no_idle_on_suspend" check, since respective
>>> driver should be able to prevent idling of a
>>> device whenever required.
>>>
>>> Driver's can get
Hi,
04/25/2013 07:49 PM, Miklos Szeredi пишет:
On Thu, Apr 25, 2013 at 4:29 PM, Maxim V. Patlasov
wrote:
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 0713bfb..c47bcd4 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1235,7 +1235,8 @@ static void
On 04/24/13 15:54, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos/cpuidle.c between commit 554c06ba3ee2 ("cpuidle:
remove en_core_tk_irqen flag") from the pm tree and commit 2eb89f893e44
("ARM: EXYNOS: factor out the idle
On 04/25/2013 12:11 AM, Alexander Holler wrote:
Am 24.04.2013 18:07, schrieb John Stultz:
And why is RTC_SYSTOHC now gone on x86?
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark
it as unnecessary
The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device to reappear and reset so that it can be
handed back to the companion. This is necessary if the device uses
persist, so that the
On Thu, 25 Apr 2013, Sedat Dilek wrote:
> You want me to send a patch against usb-next to clarify a bit on the
> kernel-config options to be enabled as prereqs in case of
> usbmon-tracing. If you think it's worth or not let me know.
It's up to you. Documentation patches are always welcome.
On Thu, Apr 25, 2013 at 9:11 AM, Alexander Holler wrote:
> Hmm, I thought RTC_SYSTOHC was there to update the used RTC clock with the
> time from NTP (and liked that).
That seems to have the nice self-explaining name CONFIG_GENERIC_CMOS_UPDATE. :)
> Therefor I don't understand why it is
>
On 04/24/2013 02:36 PM, Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven
Acked-by: Antti Palosaari
Reviewed-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/anysee.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
201 - 300 of 1278 matches
Mail list logo
