The buffer passed to the ibm,get-system-parameter RTAS call must be
in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
for the actual RTAS call and then copy the result to value. We can't
just make it static because this can be compiled in as a module.
Also add the WDRTAS_SP_SPI
Fix the calculation for offsetting into the FPRs when ptracing a 32 bit
app on 64 bit kernels.
Signed-off-by: Michael Neuling
cc: sta...@kernel.org
---
benh: it'd be nice if this went back in to 27,28 & 29
Also, I vote we kill ptracing 64 bit apps from 32 apps as it's
completely broken and no on
Michael,
> Wouldn't this still be a problem on a UP kernel?
I don't believe so - stores should be ordered with respect to the
current CPU, and in the UP case we still get a barrier().
However, perhaps there are other considerations with the HV that I'm not
aware of. Anyone?
Cheers,
Jeremy
_
On Tue, 2009-03-24 at 13:55 +1100, Jeremy Kerr wrote:
> Currently, we don't enforce any ordering for updates to the lppaca
> when enabling dtl logging, so we may end up enabling logging before the
> index fields have been established.
>
> This change adds a smp_wmb() before doing the actual enable
> > Weird, there's no lockdep support?
>
> *ashamed*: apparently no such support currently exist for PPC32. ;-)
Actually there is a patch that's been floating around (from Dale
Farnsworth) for adding irqtrace/lockdep to ppc32 but it seems to be
buggy :-) IE, it causes crashes and I haven't had a
The solution is in Documentation/spi/spidev:
-in the slave device spi_board_info struct, specify 'spidev' for the
'modalias' of *every* SPI slave.
I wonder what magic was involved to set this up!!?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
h
Hi
>
> All these errors indicate that you didn't apply all the patches.
> You'll need all 11 patches from this series, not only the last
> one.
>
I applyed all the patches,then Compile was succeeded.
Thank you for your advice.
regards,
-- Seiji Yamazaki
On Mon, 23 Mar 2009 19:16:55 +0300
A
On Mon, 2009-03-16 at 13:35 +0100, Adrian Reber wrote:
> Using the RTAS watchdog driver to read out the temperature crashes
> on a PXCAB:
>
> Unable to handle kernel paging request for data at address 0xfe347b50
> Faulting instruction address: 0xc001af64
> Oops: Kernel access of bad area,
Currently, we don't enforce any ordering for updates to the lppaca
when enabling dtl logging, so we may end up enabling logging before the
index fields have been established.
This change adds a smp_wmb() before doing the actual enable.
Signed-off-by: Jeremy Kerr
---
arch/powerpc/platforms/pser
pseries SPLPAR machines are able to retrieve a log of dispatch and
preempt events from the hypervisor. With this information, we can
see when and why each dispatch & preempt is occuring.
This change adds a set of debugfs files allowing userspace to read this
dispatch log.
Based on initial patches
On Tue, 24 Mar 2009, Anton Vorontsov wrote:
> commit 40ada30f9621fbd831ac2437b9a2a399aa ("tracing: clean up menu"),
> despite the "clean up" in its purpose, introduced a behavioural
> change for Kconfig symbols: we no longer able to select tracing
> support on PPC32 (because IRQFLAGS_SUPPORT isn'
From: Kumar Gala
Date: Mon, 23 Mar 2009 11:49:07 -0500
> Acked-by: Kumar Gala
>
> David, I'm expecting you to pick this up and put it into net-next.
Done, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listin
commit 40ada30f9621fbd831ac2437b9a2a399aa ("tracing: clean up menu"),
despite the "clean up" in its purpose, introduced a behavioural
change for Kconfig symbols: we no longer able to select tracing
support on PPC32 (because IRQFLAGS_SUPPORT isn't yet implemented).
The IRQFLAGS_SUPPORT is not manda
Hi Arnd,
nice to hear you.
On Wednesday 18 March 2009, mon...@monstr.eu wrote:
> > From: Michal Simek
> >
> >
> > Signed-off-by: Michal Simek
> > ---
> > arch/microblaze/include/asm/of_device.h | 45 ++
> > arch/microblaze/include/asm/of_platform.h | 64 ++
> > arch/microblaze/include/as
On Mon, Mar 23, 2009 at 07:51:23PM +0100, Arnd Bergmann wrote:
> On Wednesday 18 March 2009, mon...@monstr.eu wrote:
> > From: Michal Simek
> >
> >
> > Signed-off-by: Michal Simek
> > ---
> > arch/microblaze/include/asm/of_device.h | 45 ++
> > arch/microblaze/include/asm/of_platform.h |
On Mon, 2009-03-23 at 08:50 -0500, Kumar Gala wrote:
> On Mon, 23 Mar 2009, Kumar Gala wrote:
>
> > Please pull from 'merge' branch of
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
> >
> > to receive the following updates:
> >
> > arch/powerpc/kernel/head_32.S |
On Wednesday 18 March 2009, mon...@monstr.eu wrote:
> From: Michal Simek
>
>
> Signed-off-by: Michal Simek
> ---
> arch/microblaze/include/asm/of_device.h | 45 ++
> arch/microblaze/include/asm/of_platform.h | 64 ++
> arch/microblaze/include/asm/prom.h | 313
> arch/mic
From: Joakim Tjernlund
Date: Mon, 23 Mar 2009 11:17:39 +0100
> Sorry for the WS damaged patch, but my current company mailer cannot
> handle inline patches. Due to this we are setting up a new mail system
> but it will be a few days before this is ready.
> Therefore I am attaching this patch as w
Paul,
You are correct. Since it was such a small piece of code, I didn't use diff
between the kernel I am using (2.6.14) and the newest ones (2.6.28 on the
Linux). Also, I do not know how to look in the kernel files commit history.
I guess the link you gave me might be of some help.
Thanks for
I agree that VmWare is a reasonable solution.
Some of our field guys, that don't do Linux everyday, use the ELDK in a
VmWare appliance and this seems reasonable. We never had great luck
with cygwin stuff in this area.
-- John
> -Original Message-
> From: linuxppc-dev-bounces+john.linn=x
On Sun, Mar 22, 2009 at 10:45:23PM -0700, Li Yang-R58472 wrote:
> > I don't think so, in this case. The user is not asking for
> > "sleep" or deep sleep"; they are asking for a power state
> > that meets the definition of "standby" (which sleep does) or
> > which meets the definition of "mem"
On Mar 19, 2009, at 11:48 AM, Anton Vorontsov wrote:
Currently the driver just read "reg" property for constructing MDIO
bus IDs, but this won't work when we'll start using "ranges = <>" in
the device tree, so this will pop up:
Freescale PowerQUICC MII Bus: probed
sysfs: duplicate filename 'm.
On Mon, Mar 23, 2009 at 03:34:45PM +0900, 山崎 精二 wrote:
> Hi
>
> I downloaded linux-2.6.29-rc8.tar.bz2,and I patched .
> I was succeeded. Thank you very match.
> But I have the other problem.
>
> Compile was not succeeded.
>
> Message is ...
>
> CALLarch/powerpc/kernel/prom_init_check.sh
>
On Mon, Mar 23, 2009 at 4:51 AM, Stefan Roese wrote:
> I just noticed that physmap_of can't handle multiple devices of different type
> described in one device node. For example the Intel P30 48F4400 (64MByte)
> consists internally of 2 non-identical NOR chips. So a "simple"
[...]
> Now the real p
On Mon, 23 Mar 2009, Kumar Gala wrote:
> Please pull from 'merge' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
>
> to receive the following updates:
>
> arch/powerpc/kernel/head_32.S |9 +
> 1 file changed, 9 insertions(+)
>
> Kumar Gala (1):
On Mar 23, 2009, at 8:46 AM, Kumar Gala wrote:
Grant picked up the wrong version of "Respect _PAGE_COHERENT on
classic
ppc32 SW" (commit a4bd6a93c3f14691c8a29e53eb04dc734b27f0db)
It was missing the code to actually deal with the fixup of
_PAGE_COHERENT based on the CPU feature.
Signed-off-b
Grant picked up the wrong version of "Respect _PAGE_COHERENT on classic
ppc32 SW" (commit a4bd6a93c3f14691c8a29e53eb04dc734b27f0db)
It was missing the code to actually deal with the fixup of
_PAGE_COHERENT based on the CPU feature.
Signed-off-by: Kumar Gala
---
arch/powerpc/kernel/head_32.S |
I just noticed that physmap_of can't handle multiple devices of different type
described in one device node. For example the Intel P30 48F4400 (64MByte)
consists internally of 2 non-identical NOR chips. So a "simple"
fl...@0,0 {
#address-cells = <1>;
#si
Signed-off-by: Joakim Tjernlund
---
Sorry for the WS damaged patch, but my current company mailer cannot
handle inline patches. Due to this we are setting up a new mail system
but it will be a few days before this is ready.
Therefore I am attaching this patch as well, use that one
to apply instae
Hi
> The patch might be fine, but are you receiving this without the patch?
Befor patch,no sdhci-of.c found.
After patch,found sdhci-of.c.
> if you receive this with the patch then well there you go, but if this
> happens as a result with a clean fresh .tar.ball(vanilla kernel) then this
> is s
BM/AMCC PowerPC 440 GR Rev. B
Board: AMCC YELLOWSTONE
VCO: 1066 MHz
CPU: 533 MHz
PLB: 133 MHz
OPB: 66 MHz
PER: 66 MHz
PCI: 33 MHz
I2C: ready
DRAM: 256 MB
FLASH: 32 MB
PCI: Bus Dev VenId DevId Class Int
00 0c 1106 3038 0c03 00
Hi
I downloaded linux-2.6.29-rc8.tar.bz2,and I patched .
I was succeeded. Thank you very match.
But I have the other problem.
Compile was not succeeded.
Message is ...
CALLarch/powerpc/kernel/prom_init_check.sh
CC drivers/mmc/host/sdhci-of.o
drivers/mmc/host/sdhci-of.c:163: error:
2009/3/23 Li Yang-R58472
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, March 20, 2009 10:42 PM
> > To: Li Yang-R58472
> > Cc: Soohyung Cho; linuxppc-dev@ozlabs.org
> > Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp?
> >
> > Li Yang-R58472 wrote:
> > >> However,
"fsl,mpc8349-pmc" has .has_deep_sleep = 0, deep_sleeping=0 so the mem
should not do anything and just do a standby.
I am not sure if mem is a valid state in that case under /sys/power/state.
Scott, u can fix it!
-mj
On Mon, Mar 23, 2009 at 11:15 AM, Li Yang-R58472 wrote:
> > -Original Mes
34 matches
Mail list logo
