On Thu, Oct 24, 2013 at 05:37:49PM +0100, Grant Likely wrote:
On Wed, 16 Oct 2013 00:24:36 +0100, Grant Likely grant.lik...@linaro.org
wrote:
On Wed, 18 Sep 2013 15:24:50 +0200, Thierry Reding
thierry.red...@gmail.com wrote:
Interrupt references are currently resolved very early (when a
Sorry for the formatting. I'm not at my usual mailer.
From: Kumar Gala:
On Oct 24, 2013, at 4:05 PM, James Yang wrote:
On Thu, 24 Oct 2013, Kumar Gala wrote:
Than, I'd ask this be under a Kconfig option that is disabled by
default. Users should have to explicitly enable this so they know
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function platform_get_resource() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function platform_device_register_simple() returns
RR_PTR() and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
This is not a distro issue. It's a libstdc++ portability issue. libstdc++
hardcodes lwsync unless __NO_LWSYNC__ is explicitly defined,
which you only get with -mcpu=8540/-mcpu=8548. When compiled
for any powerpc target other than -mcpu=8540/-mcpu=8548, including
the default -mcpu=common,
On Thu, 2013-10-24 at 04:55 -0500, Kumar Gala wrote:
On Oct 24, 2013, at 4:45 AM, Benjamin Herrenschmidt wrote:
On Wed, 2013-10-23 at 23:06 -0500, Kumar Gala wrote:
On Oct 23, 2013, at 5:15 AM, Scott Wood wrote:
On Wed, 2013-10-23 at 00:07 -0500, Kumar Gala wrote:
On Oct 18, 2013, at
On Fri, 2013-10-25 at 10:58 +0100, David Laight wrote:
This is not a distro issue. It's a libstdc++ portability issue. libstdc++
hardcodes lwsync unless __NO_LWSYNC__ is explicitly defined,
which you only get with -mcpu=8540/-mcpu=8548. When compiled
for any powerpc target other than
Hi Peter,
On 10/23/2013 03:53 AM, Peter Zijlstra wrote:
On Mon, Oct 21, 2013 at 05:15:02PM +0530, Vaidyanathan Srinivasan wrote:
kernel/sched/fair.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 828ed97..bbcd96b
On Fri, 25 Oct 2013, David Laight wrote:
This is not a distro issue. It's a libstdc++ portability issue. libstdc++
hardcodes lwsync unless __NO_LWSYNC__ is explicitly defined,
which you only get with -mcpu=8540/-mcpu=8548. When compiled
for any powerpc target other than
On Fri, 25 Oct 2013, Scott Wood wrote:
Has anyone measured how much this slows things down with a typical
userspace?
Not a measurement of the patch in question but an older similar patch
on 3.0.51 (8572 running Debian 5.0.3):
$ ./test-lwsync
cycles per emulated lwsync = 371
cycles per sync
On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
On Wed, Oct 23, 2013 at 10:54:54AM +1100, Michael Neuling wrote:
Frederic,
The comment says atomic_dec_and_test() but the code is
local_dec_and_test().
On powerpc, local_dec_and_test() doesn't have a memory barrier
Cleaning out some stashed fixes for sparse warnings found while
working on 3be7db6: (powerpc: VPHN topology change updates all siblings)
I don't see a reason why the declarations in arch/powerpc/kernel/setup.h
can't live in arch/powerpc/include/asm/setup.h and .../mm/numa.c
should include these
Move the few declarations from arch/powerpc/kernel/setup.h
into arch/powerpc/include/asm/setup.h. This resolves a
sparse warning for arch/powerpc/mm/numa.c which defines
do_init_bootmem() but can't include the setup.h header
in the prior path.
Resolves:
arch/powerpc/mm/numa.c:998:13:
Simple fixes for sparse warnings in this file.
Resolves:
arch/powerpc/mm/numa.c:198:24:
warning: Using plain integer as NULL pointer
arch/powerpc/mm/numa.c:1157:5:
warning: symbol 'hot_add_node_scn_to_nid' was not declared.
Should it be static?
I would argue for:
READ -data_tailREAD -data_head
smp_rmb() (A) smp_rmb() (C)
WRITE $data READ $data
smp_wmb() (B) smp_mb()(D)
STORE -data_head WRITE -data_tail
On 10/17/2013 10:57 AM, Robert Knight wrote:
Well, it's four months later and I'm trying to get Fedora 20 Alpha to
install on that same machine. It appears to still have the same
problem. Did that patch ever make it into the mainline?
Strangely, the kernel from the installer (using DVD
On Wed, 9 Oct 2013 14:38:24 +0800, yuantian.t...@freescale.com wrote:
From: Tang Yuantian yuantian.t...@freescale.com
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang
17 matches
Mail list logo
