* linux-next: build failure after merge of the final tree
From: Stephen Rothwell @ 2012-02-27 6:37 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-next, linux-kernel, Bjorn Helgaas, Benjamin Herrenschmidt,
ppc-dev
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
arch/powerpc/kernel/pci-common.c: In function 'pcibios_setup_phb_resources':
arch/powerpc/kernel/pci-common.c:1520:4: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
Caused by commit 6c5705fec63d ("powerpc/PCI: get rid of device resource
fixups") from the pci tree. In this build, resource_size_t is 64 bits
while pointers are only 32.
I applied the following fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Feb 2012 17:33:48 +1100
Subject: [PATCH] powerpc/PCI: fix up for mismatch between resource_size_t and
pointer size
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci-common.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 910b9de..808ecbb 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1517,7 +1517,7 @@ static void __devinit pcibios_setup_phb_resources(struct pci_controller *hose, s
(unsigned long long)res->end,
(unsigned long)res->flags);
pci_add_resource_offset(resources, res,
- (resource_size_t) hose->io_base_virt - _IO_BASE);
+ (resource_size_t)(unsigned long)hose->io_base_virt - _IO_BASE);
/* Hookup PHB Memory resources */
for (i = 0; i < 3; ++i) {
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: build failure after merge of the akpm tree
From: H. Peter Anvin @ 2012-02-27 6:31 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Alex Shi,
Thomas Gleixner, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20120227172139.726ddae85c910cee7b7e3a37@canb.auug.org.au>
On 02/26/2012 10:21 PM, Stephen Rothwell wrote:
>
> I applied the following fix up patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 27 Feb
> 2012 17:12:00 +1100 Subject: [PATCH] percpu: fix for removal of
> percpu_xxx function
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> ---
> arch/x86/include/asm/compat.h | 2 +- 1 files changed, 1
> insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/include/asm/compat.h
> b/arch/x86/include/asm/compat.h index e7f68b4..b6a2a1c 100644 ---
> a/arch/x86/include/asm/compat.h +++
> b/arch/x86/include/asm/compat.h @@ -229,7 +229,7 @@ static inline
> void __user *arch_compat_alloc_user_space(long len) sp =
> task_pt_regs(current)->sp; } else { /* -128 for the x32 ABI redzone
> */ - sp = percpu_read(old_rsp) - 128; + sp =
> __this_cpu_read(old_rsp) - 128; }
>
> return (void __user *)round_down(sp - len, 16);
Acked-by: H. Peter Anvin <hpa@zytor.com>
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* linux-next: build failure after merge of the akpm tree
From: Stephen Rothwell @ 2012-02-27 6:21 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Alex Shi, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/compat.h:18:0,
from arch/x86/include/asm/ia32.h:7,
from arch/x86/include/asm/sigframe.h:17,
from arch/x86/kernel/asm-offsets.c:16:
arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space':
arch/x86/include/asm/compat.h:232:3: error: implicit declaration of function 'percpu_read' [-Werror=implicit-function-declaration]
Caused by commit d1a797f388d6 ("x32: Handle process creation") from the
tip tree interacting with commit 30999a95d190 ("percpu: remove percpu_xxx()
functions") from the akpm tree.
I applied the following fix up patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Feb 2012 17:12:00 +1100
Subject: [PATCH] percpu: fix for removal of percpu_xxx function
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/x86/include/asm/compat.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index e7f68b4..b6a2a1c 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -229,7 +229,7 @@ static inline void __user *arch_compat_alloc_user_space(long len)
sp = task_pt_regs(current)->sp;
} else {
/* -128 for the x32 ABI redzone */
- sp = percpu_read(old_rsp) - 128;
+ sp = __this_cpu_read(old_rsp) - 128;
}
return (void __user *)round_down(sp - len, 16);
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: manual merge of the akpm tree with the tip tree
From: Stephen Rothwell @ 2012-02-27 6:19 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, Peter Zijlstra, Cyrill Gorcunov
In-Reply-To: <4F4B1C31.7070808@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
Hi Peter,
On Sun, 26 Feb 2012 22:01:21 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> It should be "common" (otherwise there would need to be an x32 variant
> which would point to the compat version of the call, but in this case
> even the i386 entry point goes straight to sys_kcmp.)
Thanks, I will fix up the merge resolution tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the akpm tree with the tip tree
From: Cyrill Gorcunov @ 2012-02-27 6:05 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel,
Thomas Gleixner, Ingo Molnar, Peter Zijlstra
In-Reply-To: <4F4B1C63.8050108@zytor.com>
On Sun, Feb 26, 2012 at 10:02:11PM -0800, H. Peter Anvin wrote:
> On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> > On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> >> Hi Andrew,
> >>
> >> Today's linux-next merge of the akpm tree got a conflict in
> >> arch/x86/syscalls/syscall_64.tbl between commit
> >> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> >> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> >> __NR_kcmp syscall" from the akpm tree.
> >>
> >> I fixed it up (see below) but did not know if this call should be marked
> >> "common".
> >
> > Hi Stephen, letme fetch both trees to figure out what this new column means.
> > Will ping back shortly. Thanks!
> >
>
> Hi Cyrill,
>
> "common" means the same entry point is used for x86-64 and x32.
>
Ah, I see. Thanks for explanation, Peter! So it should be a "common" then.
Cyrill
^ permalink raw reply
* Re: linux-next: manual merge of the akpm tree with the tip tree
From: H. Peter Anvin @ 2012-02-27 6:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, Peter Zijlstra, Cyrill Gorcunov
In-Reply-To: <20120227165356.6119ac92eabd7052fc56c741@canb.auug.org.au>
On 02/26/2012 09:53 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/syscalls/syscall_64.tbl between commit
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls,
> x86: add __NR_kcmp syscall" from the akpm tree.
>
> I fixed it up (see below) but did not know if this call should be
> marked "common".
It should be "common" (otherwise there would need to be an x32 variant
which would point to the compat version of the call, but in this case
even the i386 entry point goes straight to sys_kcmp.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: linux-next: manual merge of the akpm tree with the tip tree
From: H. Peter Anvin @ 2012-02-27 6:02 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel,
Thomas Gleixner, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20120227055725.GC1904@moon>
On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm tree got a conflict in
>> arch/x86/syscalls/syscall_64.tbl between commit
>> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
>> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
>> __NR_kcmp syscall" from the akpm tree.
>>
>> I fixed it up (see below) but did not know if this call should be marked
>> "common".
>
> Hi Stephen, letme fetch both trees to figure out what this new column means.
> Will ping back shortly. Thanks!
>
> Cyrill
Hi Cyrill,
"common" means the same entry point is used for x86-64 and x32.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: linux-next: manual merge of the akpm tree with the tip tree
From: Cyrill Gorcunov @ 2012-02-27 5:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20120227165356.6119ac92eabd7052fc56c741@canb.auug.org.au>
On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/syscalls/syscall_64.tbl between commit
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> __NR_kcmp syscall" from the akpm tree.
>
> I fixed it up (see below) but did not know if this call should be marked
> "common".
Hi Stephen, letme fetch both trees to figure out what this new column means.
Will ping back shortly. Thanks!
Cyrill
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the tip tree
From: Stephen Rothwell @ 2012-02-27 5:53 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Cyrill Gorcunov
[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/syscalls/syscall_64.tbl between commit
arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
__NR_kcmp syscall" from the akpm tree.
I fixed it up (see below) but did not know if this call should be marked
"common".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/syscalls/syscall_64.tbl
index 4aecc7e,ac3066f..0000000
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -304,50 -304,18 +304,51 @@@
295 64 preadv sys_preadv
296 64 pwritev sys_pwritev
297 64 rt_tgsigqueueinfo sys_rt_tgsigqueueinfo
-298 64 perf_event_open sys_perf_event_open
+298 common perf_event_open sys_perf_event_open
299 64 recvmmsg sys_recvmmsg
-300 64 fanotify_init sys_fanotify_init
-301 64 fanotify_mark sys_fanotify_mark
-302 64 prlimit64 sys_prlimit64
-303 64 name_to_handle_at sys_name_to_handle_at
-304 64 open_by_handle_at sys_open_by_handle_at
-305 64 clock_adjtime sys_clock_adjtime
-306 64 syncfs sys_syncfs
+300 common fanotify_init sys_fanotify_init
+301 common fanotify_mark sys_fanotify_mark
+302 common prlimit64 sys_prlimit64
+303 common name_to_handle_at sys_name_to_handle_at
+304 common open_by_handle_at sys_open_by_handle_at
+305 common clock_adjtime sys_clock_adjtime
+306 common syncfs sys_syncfs
307 64 sendmmsg sys_sendmmsg
-308 64 setns sys_setns
-309 64 getcpu sys_getcpu
+308 common setns sys_setns
+309 common getcpu sys_getcpu
310 64 process_vm_readv sys_process_vm_readv
311 64 process_vm_writev sys_process_vm_writev
+ 312 64 kcmp sys_kcmp
+#
+# x32-specific system call numbers start at 512 to avoid cache impact
+# for native 64-bit operation.
+#
+512 x32 rt_sigaction sys32_rt_sigaction
+513 x32 rt_sigreturn stub_x32_rt_sigreturn
+514 x32 ioctl compat_sys_ioctl
+515 x32 readv compat_sys_readv
+516 x32 writev compat_sys_writev
+517 x32 recvfrom compat_sys_recvfrom
+518 x32 sendmsg compat_sys_sendmsg
+519 x32 recvmsg compat_sys_recvmsg
+520 x32 execve stub_x32_execve
+521 x32 times compat_sys_times
+522 x32 rt_sigpending sys32_rt_sigpending
+523 x32 rt_sigtimedwait compat_sys_rt_sigtimedwait
+524 x32 rt_sigqueueinfo sys32_rt_sigqueueinfo
+525 x32 sigaltstack stub_x32_sigaltstack
+526 x32 timer_create compat_sys_timer_create
+527 x32 mq_notify compat_sys_mq_notify
+528 x32 kexec_load compat_sys_kexec_load
+529 x32 waitid compat_sys_waitid
+530 x32 set_robust_list compat_sys_set_robust_list
+531 x32 get_robust_list compat_sys_get_robust_list
+532 x32 vmsplice compat_sys_vmsplice
+533 x32 move_pages compat_sys_move_pages
+534 x32 preadv compat_sys_preadv64
+535 x32 pwritev compat_sys_pwritev64
+536 x32 rt_tgsigqueueinfo compat_sys_rt_tgsigqueueinfo
+537 x32 recvmmsg compat_sys_recvmmsg
+538 x32 sendmmsg compat_sys_sendmmsg
+539 x32 process_vm_readv compat_sys_process_vm_readv
+540 x32 process_vm_writev compat_sys_process_vm_writev
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the tip tree
From: Stephen Rothwell @ 2012-02-27 5:44 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Chris Metcalf, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, H. J. Lu
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/Kconfig between commit 5fd92e65a68b ("x32: Allow x32 to be
configured") from the tip tree and commit "ipc: provide generic compat
versions of IPC syscalls" from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/Kconfig
index 14b78d7,6f6807d..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2206,22 -2206,10 +2206,23 @@@ config IA32_AOU
---help---
Support old a.out binaries in the 32bit emulation.
+config X86_X32_ABI
+ bool "x32 ABI for 64-bit mode (EXPERIMENTAL)"
+ depends on X86_64 && IA32_EMULATION && EXPERIMENTAL && BROKEN
+ ---help---
+ Include code to run binaries for the x32 native 32-bit ABI
+ for 64-bit processors. An x32 process gets access to the
+ full 64-bit register file and wide data path while leaving
+ pointers at 32 bits for smaller memory footprint.
+
+ You will need a recent binutils (2.22 or later) with
+ elf32_x86_64 support enabled to compile a kernel with this
+ option set.
+
config COMPAT
def_bool y
- depends on IA32_EMULATION
+ depends on IA32_EMULATION || X86_X32_ABI
+ select ARCH_WANT_OLD_COMPAT_IPC
config COMPAT_FOR_U64_ALIGNMENT
def_bool COMPAT
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the tip tree
From: Stephen Rothwell @ 2012-02-27 5:33 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Alex Shi, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Linus
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/i387.h between commits 8546c008924d ("i387: Uninline
the generic FP helpers that we expose to kernel modules") and
1361b83a13d4 ("i387: Split up <asm/i387.h> into exported and internal
interfaces") from the tip tree and commit
"percpu-remove-percpu_xxx-functions-fix" from the akpm tree.
I applied the appropriate part of the latter patch to
arch/x86/include/asm/fpu-internal.h and arch/x86/kernel/i387.c (see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h
index 5caaf43..e9801b4 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -290,14 +290,14 @@ static inline int __thread_has_fpu(struct task_struct *tsk)
static inline void __thread_clear_has_fpu(struct task_struct *tsk)
{
tsk->thread.fpu.has_fpu = 0;
- percpu_write(fpu_owner_task, NULL);
+ __this_cpu_write(fpu_owner_task, NULL);
}
/* Must be paired with a 'clts' before! */
static inline void __thread_set_has_fpu(struct task_struct *tsk)
{
tsk->thread.fpu.has_fpu = 1;
- percpu_write(fpu_owner_task, tsk);
+ __this_cpu_write(fpu_owner_task, tsk);
}
/*
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 7734bcb..32c3972 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -88,7 +88,7 @@ void kernel_fpu_begin(void)
__thread_clear_has_fpu(me);
/* We do 'stts()' in kernel_fpu_end() */
} else {
- percpu_write(fpu_owner_task, NULL);
+ __this_cpu_write(fpu_owner_task, NULL);
clts();
}
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* linux-next: manual merge of the akpm tree with the tip tree
From: Stephen Rothwell @ 2012-02-27 5:23 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Russell King - ARM Linux
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/irq/manage.c between commit b4bc724e82e8 ("genirq: Handle pending
irqs in irq_startup()") from the tip tree and commit "irqs: fix handling
of pending IRQs at request time" from the akpm tree.
It looks like the former is a superset of the latter, so I dropped the
latter.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the tip tree
From: Stephen Rothwell @ 2012-02-27 5:16 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Linus Torvalds, Alex Shi
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/i387.h between commit 1361b83a13d4 ("i387: Split up
<asm/i387.h> into exported and internal interfaces") from the tip tree
and commit "x86-change-percpu_read_stable-to-this_cpu_read_stable-fix"
from the akpm tree.
The former commit moved the code to arch/x86/include/asm/fpu-internal.h,
so I applied the patch there (see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h
index 4fa8815..5caaf43 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -344,7 +344,7 @@ typedef struct { int preload; } fpu_switch_t;
*/
static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
{
- return new == percpu_read_stable(fpu_owner_task) &&
+ return new == this_cpu_read_stable(fpu_owner_task) &&
cpu == new->thread.fpu.last_cpu;
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with Linus' tree
From: David Miller @ 2012-02-27 4:05 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, bhutchings
In-Reply-To: <20120227121125.007c32f9aa7be2470d9e3356@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Feb 2012 12:11:25 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/sfc/rx.c between commit ff3bc1e75275 ("sfc: Fix
> assignment of ip_summed for pre-allocated skbs") from Linus' tree and
> commit db3395697cad ("sfc: Replace efx_rx_buffer::is_page and other
> booleans with a flags field") from the net-next tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
I just merged net into net-next and resolved this conflict.
Thanks!
^ permalink raw reply
* linux-next: build failure after merge of the regmap tree
From: Stephen Rothwell @ 2012-02-27 4:05 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
Hi Mark,
After merging the regmap tree, today's linux-next build
(x86_64_allmodconfig) failed like this:
drivers/base/regmap/regcache-lzo.c: In function 'regcache_lzo_sync':
drivers/base/regmap/regcache-lzo.c:344:2: error: implicit declaration of function 'for_each_set_bit_from' [-Werror=implicit-function-declaration]
drivers/base/regmap/regcache-lzo.c:345:41: error: expected ';' before '{' token
drivers/base/regmap/regcache-lzo.c:340:6: warning: unused variable 'ret' [-Wunused-variable]
drivers/base/regmap/regcache-lzo.c:338:15: warning: unused variable 'val' [-Wunused-variable]
drivers/base/regmap/regcache-lzo.c:368:1: warning: no return statement in function returning non-void [-Wreturn-type]
Caused by commit ac8d91c80190 ("regmap: Supply ranges to the sync operations").
I have used the regmap tree form next-20120224 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the uprobes tree with the tip tree
From: Stephen Rothwell @ 2012-02-27 2:58 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
Hi Srikar,
Today's linux-next merge of the uprobes tree got a conflicts in various
files between commits from the tip tree and commits from the uprobes tree.
It looks like a later (and different) version of the uprobes patch set has
been merged into the tip tree. So I have dropped the uprobes tree
changes for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] rapidio: temporarily exclude FSL_RIO from 64 bit builds
From: Benjamin Herrenschmidt @ 2012-02-27 1:49 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, Gang.Liu, linux-next
In-Reply-To: <CAP=VYLroaEKncpy7VBobJdXijnDS5UdTV7qPG2A--SicnGvFSg@mail.gmail.com>
On Sun, 2012-02-26 at 20:26 -0500, Paul Gortmaker wrote:
> Hi Ben,
>
> Given a week has passed with the absence of any feedback
> with respect to SRIO on 64 bit, are you OK with applying the
> below patch[1] pretty much as-is?
It can't hurt, I'll put it in. That's normally Kumar's side of things
but then with him leaving FSL things are a bit in flux right now.
Cheers,
Ben.
> Thanks,
> Paul.
>
> [1] http://patchwork.ozlabs.org/patch/142383/
>
> ---
>
> On Tue, Feb 21, 2012 at 6:10 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
> > The following are seen while using the corenet64_smp_defconfig:
> >
> > arch/powerpc/sysdev/fsl_rmu.c:315: error: cast from pointer to integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:320: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:320: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:320: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:330: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:332: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:339: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:340: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:341: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:348: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:348: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:348: error: cast to pointer from integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:659: error: cast from pointer to integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int', but argument 5 has type 'size_t'
> > arch/powerpc/sysdev/fsl_rmu.c:985: error: cast from pointer to integer of different size
> > arch/powerpc/sysdev/fsl_rmu.c:997: error: cast to pointer from integer of different size
> >
> > A quick inspection of the code leaves one with the impression
> > that it was not explicitly written with 64 bit support in mind,
> > so just block that as a possible config selection for now.
> >
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> >
> > ---
> >
> > [This is seen in linux-next -- not sure if this is the right way to go
> > but at least it will give the issue some visibility to the right ppl.]
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 75f061e..5ad8013 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -773,7 +773,7 @@ config RAPIDIO
> >
> > config FSL_RIO
> > bool "Freescale Embedded SRIO Controller support"
> > - depends on RAPIDIO && HAS_RAPIDIO
> > + depends on RAPIDIO && HAS_RAPIDIO && (BROKEN || !PPC64)
> > default "n"
> > ---help---
> > Include support for RapidIO controller on Freescale embedded
> > --
> > 1.7.9.1
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH/RFC] rapidio: temporarily exclude FSL_RIO from 64 bit builds
From: Paul Gortmaker @ 2012-02-27 1:26 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gang.Liu, linux-next
In-Reply-To: <1329865853-17277-1-git-send-email-paul.gortmaker@windriver.com>
Hi Ben,
Given a week has passed with the absence of any feedback
with respect to SRIO on 64 bit, are you OK with applying the
below patch[1] pretty much as-is?
Thanks,
Paul.
[1] http://patchwork.ozlabs.org/patch/142383/
---
On Tue, Feb 21, 2012 at 6:10 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> The following are seen while using the corenet64_smp_defconfig:
>
> arch/powerpc/sysdev/fsl_rmu.c:315: error: cast from pointer to integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:320: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:320: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:320: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:330: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:332: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:339: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:340: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:341: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:348: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:348: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:348: error: cast to pointer from integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:659: error: cast from pointer to integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int', but argument 5 has type 'size_t'
> arch/powerpc/sysdev/fsl_rmu.c:985: error: cast from pointer to integer of different size
> arch/powerpc/sysdev/fsl_rmu.c:997: error: cast to pointer from integer of different size
>
> A quick inspection of the code leaves one with the impression
> that it was not explicitly written with 64 bit support in mind,
> so just block that as a possible config selection for now.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> ---
>
> [This is seen in linux-next -- not sure if this is the right way to go
> but at least it will give the issue some visibility to the right ppl.]
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 75f061e..5ad8013 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -773,7 +773,7 @@ config RAPIDIO
>
> config FSL_RIO
> bool "Freescale Embedded SRIO Controller support"
> - depends on RAPIDIO && HAS_RAPIDIO
> + depends on RAPIDIO && HAS_RAPIDIO && (BROKEN || !PPC64)
> default "n"
> ---help---
> Include support for RapidIO controller on Freescale embedded
> --
> 1.7.9.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell @ 2012-02-27 1:11 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Ben Hutchings
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/sfc/rx.c between commit ff3bc1e75275 ("sfc: Fix
assignment of ip_summed for pre-allocated skbs") from Linus' tree and
commit db3395697cad ("sfc: Replace efx_rx_buffer::is_page and other
booleans with a flags field") from the net-next tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/sfc/rx.c
index fc52fca,506d246..0000000
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@@ -156,10 -155,11 +155,10 @@@ static int efx_init_rx_buffers_skb(stru
if (unlikely(!skb))
return -ENOMEM;
- /* Adjust the SKB for padding and checksum */
+ /* Adjust the SKB for padding */
skb_reserve(skb, NET_IP_ALIGN);
rx_buf->len = skb_len - NET_IP_ALIGN;
- rx_buf->is_page = false;
+ rx_buf->flags = 0;
- skb->ip_summed = CHECKSUM_UNNECESSARY;
rx_buf->dma_addr = pci_map_single(efx->pci_dev,
skb->data, rx_buf->len,
@@@ -493,9 -494,8 +493,9 @@@ static void efx_rx_packet_gro(struct ef
} else {
struct sk_buff *skb = rx_buf->u.skb;
- EFX_BUG_ON_PARANOID(!checksummed);
+ EFX_BUG_ON_PARANOID(!(rx_buf->flags & EFX_RX_PKT_CSUMMED));
rx_buf->u.skb = NULL;
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
gro_result = napi_gro_receive(napi, skb);
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the pci tree with the mips tree
From: Stephen Rothwell @ 2012-02-27 0:31 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-next, linux-kernel, Bjorn Helgaas, Ralf Baechle
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/mips/pci/pci.c between commit f79eaeb10849 ("MIPS: PCI: use
list_for_each_entry() for bus->devices traversal") from the mips tree and
commit 96a6b9ad05a2 ("mips/PCI: get rid of device resource fixups") from
the pci tree.
The latter appears to supersede the former, so I used that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] parisc: dont unconditionally override CROSS_COMPILE for 64 bit.
From: Paul Gortmaker @ 2012-02-27 0:30 UTC (permalink / raw)
To: Mike Frysinger
Cc: JBottomley, jejb, kyle, deller, linux-parisc, linux-kernel,
linux-next
In-Reply-To: <201202261923.15167.vapier@gentoo.org>
[Re: [PATCH] parisc: dont unconditionally override CROSS_COMPILE for 64 bit.] On 26/02/2012 (Sun 19:23) Mike Frysinger wrote:
> On Sunday 26 February 2012 18:26:53 Paul Gortmaker wrote:
> > --- a/arch/parisc/Makefile
> > +++ b/arch/parisc/Makefile
> >
> > -CROSS_COMPILE := hppa64-linux-gnu-
> > +ifndef CROSS_COMPILE
> > + CROSS_COMPILE := hppa64-linux-gnu-
> > +endif
>
> this should accomplish the same thing in practice:
> CROSS_COMPILE ?= hppa64-linux-gnu-
Good point, I'll wait for a bit in case I was missing something else
obvious, and then resend.
THanks,
P.
> -mike
^ permalink raw reply
* Re: [PATCH] parisc: dont unconditionally override CROSS_COMPILE for 64 bit.
From: Mike Frysinger @ 2012-02-27 0:23 UTC (permalink / raw)
To: Paul Gortmaker
Cc: JBottomley, jejb, kyle, deller, linux-parisc, linux-kernel,
linux-next
In-Reply-To: <1330298813-17262-1-git-send-email-paul.gortmaker@windriver.com>
[-- Attachment #1: Type: Text/Plain, Size: 322 bytes --]
On Sunday 26 February 2012 18:26:53 Paul Gortmaker wrote:
> --- a/arch/parisc/Makefile
> +++ b/arch/parisc/Makefile
>
> -CROSS_COMPILE := hppa64-linux-gnu-
> +ifndef CROSS_COMPILE
> + CROSS_COMPILE := hppa64-linux-gnu-
> +endif
this should accomplish the same thing in practice:
CROSS_COMPILE ?= hppa64-linux-gnu-
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the tegra tree with the arm tree
From: Stephen Rothwell @ 2012-02-26 23:40 UTC (permalink / raw)
To: Stephen Warren, Colin Cross, Olof Johansson
Cc: linux-next, linux-kernel, Nicolas Pitre, Peter De Schrijver,
Russell King
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
Hi all,
Today's linux-next merge of the tegra tree got a conflict in
arch/arm/mach-tegra/common.c between commit daa14d5e60e0 ("ARM:
mach-tegra: properly disable CPU idle call") from the arm tree and commit
65fe31da5ced ("ARM: tegra: support for Tegra30 CPU powerdomains") from
the tegra tree.
Just context changes. I fixed it up (see below) and can carry the fax as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-tegra/common.c
index 2db20da,09dc37fc..0000000
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@@ -27,6 -27,8 +27,7 @@@
#include <asm/hardware/gic.h>
#include <mach/iomap.h>
-#include <mach/system.h>
+ #include <mach/powergate.h>
#include "board.h"
#include "clock.h"
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] parisc: dont unconditionally override CROSS_COMPILE for 64 bit.
From: Paul Gortmaker @ 2012-02-26 23:26 UTC (permalink / raw)
To: JBottomley, jejb, kyle, deller
Cc: linux-parisc, linux-kernel, linux-next, Paul Gortmaker
Using the 64 bit toolchains from kernel.org[1], one finds that
you can't build the a500_defconfig, because the Makefile will
stomp whatever value you have in your env. for CROSS_COMPILE.
This shows up since the kernel.org toolchains for parisc-64
do not have the "-gnu" prefix, and so you run into it always
saying hppa64-linux-gnu-gcc not found, regardless of the fact
you've not got "-gnu" put anywhere into CROSS_COMPILE.
[1] ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.2/
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 55cca1d..cefff6d 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -31,7 +31,9 @@ ifdef CONFIG_64BIT
UTS_MACHINE := parisc64
CHECKFLAGS += -D__LP64__=1 -m64
WIDTH := 64
-CROSS_COMPILE := hppa64-linux-gnu-
+ifndef CROSS_COMPILE
+ CROSS_COMPILE := hppa64-linux-gnu-
+endif
else # 32-bit
WIDTH :=
endif
--
1.7.9.1
^ permalink raw reply related
* [PATCH] parisc: fix longstanding build failures for !CONFIG_PCI
From: Paul Gortmaker @ 2012-02-26 23:24 UTC (permalink / raw)
To: JBottomley, jejb, kyle, deller
Cc: linux-parisc, mst, linux-kernel, linux-next, Paul Gortmaker,
Randy Dunlap
Upstream commit fea80311a939a746533a6d7e7c3183729d6a3faf
"iomap: make IOPORT/PCI mapping functions conditional"
introduced an arch independent stub for pci_iounmap() but the
parisc had its own that was unconditionally built. So builds
since v3.0-3553-gfea8031 have been failing with:
arch/parisc/lib/iomap.c:439:6: error: redefinition of 'pci_iounmap'
include/asm-generic/iomap.h:75:20: note: previous definition of 'pci_iounmap' was here
Making the parisc one specific to CONFIG_PCI fixes the problem.
CC: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[This fixes the linux-next builds that have been consistently failing
since last July -- http://kisskb.ellerman.id.au/kisskb/target/2069/ ]
diff --git a/arch/parisc/lib/iomap.c b/arch/parisc/lib/iomap.c
index fb8e10a..dc0a2c3 100644
--- a/arch/parisc/lib/iomap.c
+++ b/arch/parisc/lib/iomap.c
@@ -436,12 +436,15 @@ void ioport_unmap(void __iomem *addr)
}
}
+#ifdef CONFIG_PCI
void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
{
if (!INDIRECT_ADDR(addr)) {
iounmap(addr);
}
}
+EXPORT_SYMBOL(pci_iounmap);
+#endif
EXPORT_SYMBOL(ioread8);
EXPORT_SYMBOL(ioread16);
@@ -461,4 +464,3 @@ EXPORT_SYMBOL(iowrite16_rep);
EXPORT_SYMBOL(iowrite32_rep);
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-EXPORT_SYMBOL(pci_iounmap);
--
1.7.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox