52xx build error

I get that with my current stuff: cc1: warnings being treated as errors In file included from /home/benh/linux-powerpc-test/arch/powerpc/platforms/52xx/mpc52xx_common.c:19: /home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: ‘struct gpio_chip’ declared inside parameter list

Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls

On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote: On Friday 20 August 2010, Andreas Schwab wrote: See arch/powerpc/platforms/cell/spu_callbacks.c. * 4. They are optional and we can't rely on them being *linked into the kernel. Unfortunately, the cond_syscall *helper

[git pull] Please pull powerpc.git merge branch

Hi Linus ! Here's a few powerpc bits fixes for 2.6.36, some of them for some of the new stuff that went in, along with the powerpc rwsem update to atomic_long_t (not yet moved to asm-generic) and wiring up of some new syscalls. Cheers, Ben. The following changes since commit

Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls

On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote: On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote: On Friday 20 August 2010, Andreas Schwab wrote: See arch/powerpc/platforms/cell/spu_callbacks.c. * 4. They are optional and we can't rely on them being *linked

[PATCH] gpiolib: Add 'struct gpio_chip' forward declaration for !GPIOLIB case

With CONFIG_GPIOLIB=n, the 'struct gpio_chip' is not declared, so the following pops up on PowerPC: cc1: warnings being treated as errors In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:19: include/linux/of_gpio.h:74: warning: 'struct gpio_chip' declared

Re: 64-bit ppc rwsem

On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote: On Mon, 2010-08-23 at 15:18 -0700, David Miller wrote: I've seen drivers in the past do trylocks at interrupt time ... tho I agree it sucks. Recently there was a thread where this was declared absolutely illegal. Maybe

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

Hello! I'm curious if its possible to do the PTP hardware offset/adjustment calculation in a module internally to the kernel? That would allow the PPS interface to still be used to sync the system time, and not expose additional interfaces. Just my 2 cents on this issue. PTP is very often used

Re: [PATCH 1/1] powerpc: Clear cpu_sibling_map in cpu_die

On 08/24/2010 12:24 AM, Benjamin Herrenschmidt wrote: On Wed, 2010-08-11 at 15:34 -0500, Brian King wrote: While testing CPU DLPAR, the following problem was discovered. We were DLPAR removing the first CPU, which in this case was logical CPUs 0-3. CPUs 0-2 were already marked offline and we

[PATCH] powerpc: Check end of stack canary at oops time

Add a check for the stack canary when we oops, similar to x86. This should make it clear that we overran our stack: Unable to handle kernel paging request for data at address 0x24652f63700ac689 Faulting instruction address: 0xc0063d24 Thread overran stack, or stack corrupted

[PATCH 2/2] powerpc: kdump: Override crash_free_reserved_phys_range to avoid freeing RTAS

The crashkernel region will almost always overlap RTAS. If we free the crashkernel region via echo 0 /sys/kernel/kexec_crash_size then we will free RTAS and the machine will crash in confusing and exciting ways. Override crash_free_reserved_phys_range and check for overlap with RTAS.

[PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden

On ppc64 the crashkernel region almost always overlaps an area of firmware. This works fine except when using the sysfs interface to reduce the kdump region. If we free the firmware area we are guaranteed to crash. Rename free_reserved_phys_range to crash_free_reserved_phys_range and make it a

Re: [PATCH] powerpc: Check end of stack canary at oops time

On Wed, 2010-08-25 at 09:15 +1000, Anton Blanchard wrote: Add a check for the stack canary when we oops, similar to x86. This should make it clear that we overran our stack: Unable to handle kernel paging request for data at address 0x24652f63700ac689 Faulting instruction address:

Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}

On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote: Do some 32 bit processors need this? In 32 bit before the merge, we use to have code that did: #if defined(CONFIG_4xx) || defined(CONFIG_E500) #define cvt_fd without save/restore fpscr #else #define

Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}

In message 1282699836.22370.566.ca...@pasglop you wrote: On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote: Do some 32 bit processors need this? In 32 bit before the merge, we use to have code that did: #if defined(CONFIG_4xx) || defined(CONFIG_E500) #define

Re: [PATCH] powerpc: Check end of stack canary at oops time

Hi, The check for init is just because we haven't set the magic value for init's stack right? But we could. Yeah, it's similar to what x86 are doing now: commit 0e7810be30f66e9f430c4ce2cd3b14634211690f Author: Jan Beulich jbeul...@novell.com Date: Fri Nov 20 14:00:14 2009 + x86:

Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden

Anton Blanchard an...@samba.org writes: On ppc64 the crashkernel region almost always overlaps an area of firmware. This works fine except when using the sysfs interface to reduce the kdump region. If we free the firmware area we are guaranteed to crash. That is ppc64 bug. firmware should