On Mon, 2011-04-04 at 23:42 -0700, Michel Lespinasse wrote:
> On Mon, Apr 4, 2011 at 11:24 PM, Michael Ellerman
> wrote:
> > In access_process_vm() we need to check that we have found the right
> > vma, not the following vma, before we try to access it. Otherwise
> > we might call the vma's access
The calculation of the size for the exception save area of the TLB
miss handler is wrong, luckily it's too big not too small.
Rework it to make it a bit clearer, and also correct. We want 3 save
areas, each EX_TLB_SIZE _bytes_.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/paca.h
In __access_remote_vm() we need to check that we have found the right
vma, not the following vma, before we try to access it. Otherwise we
might call the vma's access routine with an address which does not
fall inside the vma.
Signed-off-by: Michael Ellerman
---
mm/memory.c |2 +-
1 files ch
We currently enable interrupts before the dispatch log for the boot
cpu is setup. If a timer interrupt comes in early enough we oops in
scan_dispatch_log:
Unable to handle kernel paging request for data at address 0x0010
...
.scan_dispatch_log+0xb0/0x170
.account_system_vtime+0xa0/0x220
.ir
The MSR bit which indicates 64-bit-ness is different between server and
booke, so add a #define which gives you the right mask regardless.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/reg.h | 10 --
arch/powerpc/include/asm/reg_booke.h |6 --
2 files chang
Use the new MSR_64BIT in a few places. Some of these are already ifdef'ed
for BOOKE vs BOOKS, but it's still clearer, MSR_SF does not immediately
parse as "MSR bit for 64bit".
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/head_64.S |2 +-
arch/powerpc/kernel/signal_64.c |4 ++
We check MSR_SF a lot in sstep.c, to decide if we need to emulate the
truncation of values when running in 32-bit mode. Factor out that code
into a helper, and convert it and the other uses to use MSR_64BIT.
This fixes a bug on BOOK3E where kprobes would end up returning to a
32-bit address, becau
Hello Prabhakar,
On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
wrote:
>> -Original Message-
>> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
>> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
>> Sent: Thursday, April 07, 2011 10:23 PM
>> To: Kushwaha Prabhakar-
Hi Leon,
> -Original Message-
> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
> Sent: Friday, April 08, 2011 1:55 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff Garzik;
> Linux PPC; Gupta Maneesh-B18878
> Subject: Re: know
> + u64 delta = 0;
...
> + if (((prev & 0x8000) && !(val & 0x8000)) || (val >
prev))
> + delta = (val - prev) & 0xul;
> +
> + return delta;
The above is incorrect modulo arithmetic.
It is probably intended to do:
s32 delta = val - prev;
return del
> In __access_remote_vm() we need to check that we have found the right
> vma, not the following vma, before we try to access it. Otherwise we
> might call the vma's access routine with an address which does not
> fall inside the vma.
>
> Signed-off-by: Michael Ellerman
> ---
> mm/memory.c |
Grant,
I'm being lazy, can you give any quick insight on the following compile warning:
drivers/dma/fsldma.c:1457:2: warning: initialization from incompatible pointer
type
drivers/dma/fsldma.c: In function 'fsldma_init':
drivers/dma/fsldma.c:1468:2: warning: passing argument 1 of
'platform_driv
Hello Prabhakar,
On Fri, Apr 8, 2011 at 10:31 AM, Kushwaha Prabhakar-B32579
wrote:
> Hi Leon,
>
>
>> -Original Message-
>> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
>> Sent: Friday, April 08, 2011 1:55 PM
>> To: Kushwaha Prabhakar-B32579
>> Cc: Moffett, Kyle D; linux-...@
On Apr 8, 2011, at 2:56 AM, Michael Ellerman wrote:
> Use the new MSR_64BIT in a few places. Some of these are already ifdef'ed
> for BOOKE vs BOOKS, but it's still clearer, MSR_SF does not immediately
> parse as "MSR bit for 64bit".
>
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/kern
Ben,
If looks like SUSPEND support requires CPU hotplug (forces CONFIG_HOTPLUG_CPU).
This is causing current 2.6.39-rc2 to break for 85xx-smp. Are you willing to
take patches that add cpu hotplug support for 85xx/e500 for 2.6.39 to fix this?
- k
___
Hello all,
I don't see this option in the .config and in the menuconfig / Advanced Setup I
don't see a [Set the boot link/load
address]:
[*] Prompt for advanced kernel configuration options
[ ] Set maximum low memory
[ ] Set custom page offset address
[ ] Set custom kernel base address
[ ]
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit. This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE & ALWAYS defines as part
of its check.
Create a unique CPU_FTRS_E5500 (as its different from CPU_FTRS_E500MC),
create
From: Scott Wood
e500mc does not support the HID0/MSR mechanism that is used by e500_idle
(and there are also issues with waking on certain types of interrupts).
Further, even if napping is never actually enabled, just having
CPU_FTR_CAN_NAP will cause machine_init() to overwrite the board's sup
Hi Leon,
interrupt-map-mask is missing for pcie@ffe0a000 node. Please see my comment
there...
pcie@ffe0a000 node deals with mini-PCIe.
one more thing, can you please tell P1020Si version. It will be there on u-boot
log.
--Prabhakar
> -Original Message-
> From: Leon Woestenberg [m
On Apr 8, 2011, at 2:22 AM, Michael Ellerman wrote:
> The calculation of the size for the exception save area of the TLB
> miss handler is wrong, luckily it's too big not too small.
>
> Rework it to make it a bit clearer, and also correct. We want 3 save
> areas, each EX_TLB_SIZE _bytes_.
>
> S
On Fri, 2011-04-08 at 11:28 +0200, Guillaume Dargaud wrote:
> Hello all,
> I don't see this option in the .config and in the menuconfig / Advanced Setup
> I don't see a [Set the boot link/load
> address]:
>
> [*] Prompt for advanced kernel configuration options
> [ ] Set maximum low memory
>
The ml and and mz commands in xmon currently only work on 32-bit values.
This leads to odd issues when trying to use them on a ppc64 machine. If
one specified 64-bit addresses to mz, it would loop on the same output
indefinitely. The ml command would fail to find any 64-bit values in a
memory ran
Creates P2020si.dtsi, containing information for P2020 SoC. Modifies dts files
for P2020 based systems to use dtsi file.
Signed-off-by: Prabhakar Kushwaha
---
Based upon
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch
master)
Please see mpc5200b.dtsi for reference
> Isn't that blackfin specific?
So how do you change the loading address of the PowerPC kernel from its default
0x40 address ?
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.o
On 4/6/2011 8:35 PM, Benjamin Herrenschmidt wrote:
On Wed, 2011-04-06 at 15:50 -0700, Richard A Lary wrote:
From: Richard A. Lary
Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.
Care to tell us a bit about the difference ? :-) There's nothing obvious
in the code Als
On Wed, Apr 6, 2011 at 2:40 PM, Chuck Ketcham wrote:
> Three of the channels were not used because they were already publicly
> allocated. One channel was
> not used because it didn't have DMA_MEMCPY capability.
That's strange, because all four DMA channels are identical.
> 2. If dmaengine is
Remove offload changing ethtool ops which drivers don't really support:
- fs_enet
- ucc_geth
Signed-off-by: Michał Mirosław
---
drivers/net/fs_enet/fs_enet-main.c |2 --
drivers/net/ucc_geth_ethtool.c |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net
On Fri, Apr 08, 2011 at 04:12:13AM -0500, Kumar Gala wrote:
> Grant,
>
> I'm being lazy, can you give any quick insight on the following compile
> warning:
>
> drivers/dma/fsldma.c:1457:2: warning: initialization from incompatible
> pointer type
> drivers/dma/fsldma.c: In function 'fsldma_init'
On Fri, Apr 8, 2011 at 8:32 AM, Ira W. Snyder wrote:
> On Fri, Apr 08, 2011 at 04:12:13AM -0500, Kumar Gala wrote:
>> Grant,
>>
>> I'm being lazy, can you give any quick insight on the following compile
>> warning:
>>
>> drivers/dma/fsldma.c:1457:2: warning: initialization from incompatible
>> p
From: Ayman El-Khashab
The 460SX uses a different register set than previous 44x PCIe CPUs,
so some of the checks were not valid. Added an enable for the TX
and RX. For the 460SX only: Bypassed VCO check and added PLL check.
Bypassed the link check. Changed to advertise gen 2 speeds.
Signed-o
From: Ayman El-Khashab
This patch is to fix the PCIe on the 460SX CPU. As far as I can tell,
the 460SX must be using a different core than the previous 4xx SOCs.
The registers aren't the same and it appears DCRs that existed on
previous parts don't exist on this one. Perhaps somebody from AMCC
On Fri, 2011-04-08 at 13:22 -0500, Ayman El-Khashab wrote:
> From: Ayman El-Khashab
>
> This patch is to fix the PCIe on the 460SX CPU. As far as I can tell,
> the 460SX must be using a different core than the previous 4xx SOCs.
> The registers aren't the same and it appears DCRs that existed on
This code was cribbed from niu, so gfar_set_hash_opts() begins by
converting the ethtool flow class code into a class code for Sun
Neptune hardware, then does the same thing again for the hardware it's
really dealing with. It may also return -1 (-EPERM) for some
unhandled ethtool flow class codes.
33 matches
Mail list logo