On Mon, 2009-12-14 at 16:34 +1100, Stephen Rothwell wrote:
Hi Grant,
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
arch/powerpc/mm/pgtable_32.c: In function 'mapin_ram':
arch/powerpc/mm/pgtable_32.c:318: error: too many arguments to function
'mmu_mapin_ram'
On 14.12.2009, at 07:35, Stephen Rothwell wrote:
Hi all,
A powerpc allmodconfig fails like this:
arch/powerpc/kvm/built-in.o:(.toc1+0x18): undefined reference to
`kvm_debugfs_dir'
This is because CONFIG_KVM_EXIT_TIMING is a bool while
CONFIG_KVM_BOOK3S_64 is tristate. This causes
On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
While executing cpu_hotplug(from autotest) tests against latest
next on a power6 box, the machine locks up. A soft reset shows
the following trace
cpu 0x0: Vector: 100 (System Reset) at [cc9333d0]
pc: c03433d8:
Peter Zijlstra wrote:
On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
While executing cpu_hotplug(from autotest) tests against latest
next on a power6 box, the machine locks up. A soft reset shows
the following trace
cpu 0x0: Vector: 100 (System Reset) at [cc9333d0]
pc:
On Mon, 2009-12-14 at 16:41 +0530, Sachin Sant wrote:
Peter Zijlstra wrote:
On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
While executing cpu_hotplug(from autotest) tests against latest
next on a power6 box, the machine locks up. A soft reset shows
the following trace
cpu
The function name of cpumask_clear_cpu was not correct.
Reported-by: Jin Qing b24...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
This also implies that the CONFIG_HOTPLUG_CPU was never tested.
We are trying to add cpu hotplug for SMP suspend, but seeing the
following error(on
as of 20091214
drivers/dma/fsldma.c | 31 ---
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 296f9e7..272097a 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -449,35 +449,6 @@ static void
The async_tx descriptors contains dangling pointers.
Hence, re-initialize them to NULL before use.
Signed-off-by: Vishnu Suresh vis...@freescale.com
---
o. Rebased to linux-next as of 20091214
drivers/dma/fsldma.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers
spinlock_irqsave to spin_lock_bh
o. Removed setting async_tx_ack
o. Removed unnecessary initialization.
o. Rebased to linux-next as of 20091214
drivers/crypto/Kconfig |1 +
drivers/crypto/talitos.c | 397 +-
drivers/crypto/talitos.h |2 +
3 files
The async_tx descriptors contains dangling pointers.
Hence, re-initialize them to NULL before use.
Signed-off-by: Vishnu Suresh vis...@freescale.com
---
o. Rebased to linux-next as of 20091214
drivers/crypto/talitos.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
This patch fixes the handling of VSX alignment faults in little-endian
mode (the current code assumes the processor is in big-endian mode).
The patch also makes the handlers clear the top 8 bytes of the register
when handling an 8 byte VSX load.
This is based on 2.6.32.
Signed-off-by: Neil
Neil Campbell wrote:
This patch fixes the handling of VSX alignment faults in little-endian
mode (the current code assumes the processor is in big-endian mode).
The patch also makes the handlers clear the top 8 bytes of the register
when handling an 8 byte VSX load.
For the interested, here
Hi all,
The patches were waiting for commit 2e9d546eda5888962a441da1e96bbf9
(powerpc/fsl: Make fsl_deep_sleep() usable w/ modules and non-83xx
builds) to hit Linus' tree.
Now that the commit is in, I'm resending the series with some
corrections as suggested[1] by Scott Wood.
It might be late
This patch fixes following warnings:
ehci-fsl.c:43:5: warning: symbol 'usb_hcd_fsl_probe' was not declared. Should
it be static?
ehci-fsl.c:150:6: warning: symbol 'usb_hcd_fsl_remove' was not declared. Should
it be static?
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
EHCI FSL controller preserve its state during sleep mode, so nothing
fancy needs to be done.
Though, during 'deep sleep' mode (as found in MPC831x CPUs) the
controller turns off and needs to be reinitialized upon resume.
This patch adds support for hibernation and resuming after deep sleep.
On Wed, Dec 9, 2009 at 18:46:51 Grant Likely wrote:
to-fleisc...@t-online.de wrote:
[...]
The following patch adds a function to get the active state of the chip
select of a SPI device by looking for the 'spi-cs-high' property in the
associated device tree node.
This function is used by
On Sun, Dec 13, 2009 at 04:56:48PM -0800, Roland McGrath wrote:
I can't see anything you've done to keep this use of MSR_SE in the
user-mode register state from interfering with user_enable_single_step().
It looks to me like you'd swallow the normal step indications.
Yes, it does unset
Yes, it does unset MSR_SE bit in single_step_dabr_instruction()
irrespective of whether it was previously enabled through
user_enable_single_step(). This could be mitigated with the use of a
separate flag which can be used to conditionally unset MSR_SE, however
given further concerns about
On Mon, 2009-12-14 at 21:01 +0800, Li Yang wrote:
The function name of cpumask_clear_cpu was not correct.
Reported-by: Jin Qing b24...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
This also implies that the CONFIG_HOTPLUG_CPU was never tested.
We are trying to add cpu
This patch fixes the handling of VSX alignment faults in little-endian
mode (the current code assumes the processor is in big-endian mode).
The patch also makes the handlers clear the top 8 bytes of the register
when handling an 8 byte VSX load.
This is based on 2.6.32.
Signed-off-by:
On Mon, 2009-12-14 at 13:19 +0100, Peter Zijlstra wrote:
cpu 0x0: Vector: 100 (System Reset) at [cc9333d0]
pc: c03433d8: .find_next_bit+0x54/0xc4
lr: c0342f10: .cpumask_next_and+0x4c/0x94
sp: cc933650
msr: 80089032
current
On machines using the Apple U4 bridge (AKA IBM CPC945) PCIe interface such
as the latest generation G5 machines x16 slot or the x16 slot of the
PowerStation, MSIs are currently broken (and will oops when enabling).
This fixes the oops and implements proper support for those. Instead of
using the
On Mon, Dec 14, 2009 at 6:33 AM, Vishnu Suresh vis...@freescale.com wrote:
The async_tx descriptors contains dangling pointers.
Hence, re-initialize them to NULL before use.
Signed-off-by: Vishnu Suresh vis...@freescale.com
---
o. Rebased to linux-next as of 20091214
drivers/crypto
23 matches
Mail list logo
