* question about of_platform vs 'platform'
From: Mike Hench @ 2008-03-19 21:49 UTC (permalink / raw)
To: linuxppc-dev
Sorry if this is a stupid question
I am new to PPC.
I am trying to make the SPI work on a MPC8313erdb board.
It isn't loading.
To that end, I added a printk to drivers/base/dd.c __driver_match
function
dmesg |grep -i spi
bus: 'of_platform': driver_probe_device: matching device e0007000.spi
with drive
r fsl-elbc
bus: 'platform': driver_probe_device: matching device fsl-usb2-udc.0
with driver
mpc83xx_spi
bus: 'platform': driver_probe_device: matching device mpc83xx_wdt.0 with
driver
mpc83xx_spi
bus: 'platform': driver_probe_device: matching device fsl-i2c.0 with
driver mpc8
3xx_spi
bus: 'platform': driver_probe_device: matching device fsl-i2c.1 with
driver mpc8
3xx_spi
bus: 'platform': driver_probe_device: matching device Fixed MDIO bus.0
with driv
er mpc83xx_spi
it seems there is some sort of mismatch
how did the kernel decide that SPI was an 'of_platform' device.
The driver just uses 'platform' sorts of calls.
As opposed to the mpc52xx driver which uses of_platform.
The DTS file spi entry look similar to the i2c entries.
Those are treated as 'platform' devices.
A nudge/shove in the right direction would be appreciated.
Thanks.
Mike
^ permalink raw reply
* Re: [PATCH] Hide resources on Axon PCIE root complex nodes
From: Paul Mackerras @ 2008-03-19 21:59 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <62a10dda33b8e6b790f13057daea1430ed81ef1c.1205907051.git.michael@ellerman.id.au>
Michael Ellerman writes:
> The PCI bridge representing the PCIE root complex on Axon, contains device
> BARs for a memory range and ROM that define inbound accesses. This confuses
> the kernel resource management code, the resources need to be hidden when
> Axon is a host bridge.
Since you didn't say, I assume this isn't needed for 2.6.25... right?
(Please, everybody, if you want a patch in 2.6.25, put something in the
subject line to indicate that, such as a [2.6.25] tag.)
Paul.
^ permalink raw reply
* 7448/2.6.20 problems (double boots or hangs)
From: Leisner, Martin @ 2008-03-19 21:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lund, Nathan (Nathan.Lund@usa.xerox.com)
My taiga board is now dead -- on our development board (with a taiga
kernel
and a custom modified dts) we see either
1) it hangs at the same point ("PID has table entries")
or
2) it boots but it seems to restart the boot process after the "PID hash
table entries line"
This was never a problem with 2.6.10 or with 2.6.22.
I modified a driver, saw this oddness and changed to the original driver
(the oddness went away). I did this about 3 times so I can say "ah
ha!!"
We're using 2.6.20.11...but I recall later to 2.6.20s were no better...
Any recommendations/hypothesis?
marty
arch: exit =20
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 131072
[ 0.000000] Normal 131072 -> 131072
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 131072 =20
[ 0.000000] Built 1 zonelists. Total pages: 130048
[ 0.000000] Kernel command line:
nfsroot=3D13.121.21.120:/usr/local/tmp/ganymede ip=3Ddhcp
console=3DttyS0,115200
[ 0.000000] mpic: Setting up MPIC "Tsi108_PIC" version 1.2 at
c0007400, max 4 CPUs =20
[ 0.000000] mpic: ISU size: 24, shift: 5, mask: 1f
[ 0.000000] mpic: Initializing for 24 sources =20
[ 0.000000] PID hash table entries: 2048 (order: 11, 8192 bytes)
=20
[ 0.000000] Using MPC7448 HPC2 machine description
[ 0.000000] setup ppc6xx_idle
[ 0.000000] Total memory =3D 512MB; using 1024kB for hash table (at
cff00000)
[ 0.000000] Linux version 2.6.20 (mleisner@mleisner-linux) (gcc
version 4.0.0 (DENX ELDK 4.1 4.0.0)) #27 Wed Mar 5 10:56:11 EST 2008
[ 0.000000] Found tsi108 PCI host bridge at 0xc0001000. Firmware bus
number: 0->0
[ 0.000000] MPC7448HPC2 (TAIGA) Platform
[ 0.000000] Jointly ported by Freescale and Tundra Semiconductor
[ 0.000000] Enabling L2 cache then enabling the HID0 prefetch engine.
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 131072
^ permalink raw reply
* Re: 7448/2.6.20 problems (double boots or hangs)
From: Gerhard Pircher @ 2008-03-19 22:31 UTC (permalink / raw)
To: Leisner, Martin, linuxppc-dev; +Cc: Nathan.Lund
In-Reply-To: <556445368AFA1C438794ABDA8901891C084C2113@USA0300MS03.na.xerox.net>
-------- Original-Nachricht --------
> Datum: Wed, 19 Mar 2008 17:52:16 -0400
> Von: "Leisner, Martin" <Martin.Leisner@xerox.com>
> An: linuxppc-dev@ozlabs.org
> CC: "Lund, Nathan \\(Nathan.Lund@usa.xerox.com\\)" <Nathan.Lund@xerox.com>
> Betreff: 7448/2.6.20 problems (double boots or hangs)
> My taiga board is now dead -- on our development board (with a taiga
> kernel
> and a custom modified dts) we see either
>
>
> 1) it hangs at the same point ("PID has table entries")
> or
> 2) it boots but it seems to restart the boot process after the "PID hash
> table entries line"
I observed the same behavior on my AmigaOne, if the PAGE_COHERENT flag was
set for page mappings by CPU_FTR_NEED_COHERENT. The 7448 CPU doesn't need
CPU_FTR_NEED_COHERENT to be set (no CPU bug that needs to be worked
around), but there is no define for the 7448 in arch/powerpc/cputable.h in
kernel v2.6.20 (but it's in v2.6.22!). Thus I guess it is detected as a
744[0|5|7], which have this flag set.
On the other side my hardware is _very_ buggy, so it's unlikely that this
could be the problem on your hardware.
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: question about of_platform vs 'platform'
From: Scott Wood @ 2008-03-19 22:43 UTC (permalink / raw)
To: Mike Hench; +Cc: linuxppc-dev
In-Reply-To: <6629C06B144F5C4098DFF95C4FF9DAF702BA1D37@mailsrv.engagenet.com>
On Wed, Mar 19, 2008 at 04:49:18PM -0500, Mike Hench wrote:
> bus: 'of_platform': driver_probe_device: matching device e0007000.spi
> with drive
> r fsl-elbc
> bus: 'platform': driver_probe_device: matching device fsl-usb2-udc.0
> with driver
> mpc83xx_spi
> bus: 'platform': driver_probe_device: matching device mpc83xx_wdt.0 with
> driver
> mpc83xx_spi
> bus: 'platform': driver_probe_device: matching device fsl-i2c.0 with
> driver mpc8
> 3xx_spi
> bus: 'platform': driver_probe_device: matching device fsl-i2c.1 with
> driver mpc8
> 3xx_spi
> bus: 'platform': driver_probe_device: matching device Fixed MDIO bus.0
> with driv
> er mpc83xx_spi
>
> it seems there is some sort of mismatch
> how did the kernel decide that SPI was an 'of_platform' device.
It will try to match all device nodes under probed buses to an of_platform
device.
> The DTS file spi entry look similar to the i2c entries.
> Those are treated as 'platform' devices.
There is glue code in arch/powerpc/sysdev/fsl_soc.c:of_fsl_spi_probe() to
create platform devices from the device nodes.
It doesn't seem to be registered as an initcall, though -- you need to call
it from platform code. See mpc832x_rdb.c for an example.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Stephen Rothwell @ 2008-03-19 23:27 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847389-17771-1-git-send-email-sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
Hi Stefan,
Just a few trivial things ...
On Tue, 18 Mar 2008 14:36:29 +0100 Stefan Roese <sr@denx.de> wrote:
>
> +++ b/arch/powerpc/sysdev/ppc4xx_soc.c
>
> +static int __init ppc4xx_l2c_probe(void)
> +{
> + struct device_node *np = NULL;
This initialisation is unneeded.
> + /* Map DCRs */
> + dcrreg = of_get_property(np, "dcr-reg", &len);
> + if (!dcrreg || (len != 4*sizeof(u32))) {
I prefer spaces around binary operators.
> + printk(KERN_ERR "%s: Can't get DCR register base !",
> + np->full_name);
> + return -ENODEV;
Since of_find_compatible_node() gets a reference to np, you need an
of_node_put(np) before you return.
> + if (irq == NO_IRQ) {
> + printk(KERN_ERR "irq_of_parse_and_map failed\n");
> + return -ENODEV;
And again.
> + if (request_irq(irq, l2c_error_handler, IRQF_DISABLED, "L2C", 0) < 0) {
> + printk(KERN_ERR "Cannot install L2C error handler"
> + ", cache is not enabled\n");
> + return -ENODEV;
And again.
> + return 0;
And again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Make 83xx perfmon support selectable
From: Kumar Gala @ 2008-03-19 23:48 UTC (permalink / raw)
To: Scott Wood; +Cc: Paul Mackerras, Phillips Kim, linuxppc-dev list
In-Reply-To: <20080318170542.GA4099@loki.buserror.net>
On Mar 18, 2008, at 12:05 PM, Scott Wood wrote:
> On Fri, Mar 07, 2008 at 05:59:03PM -0600, Andy Fleming wrote:
>> Not all e300 cores support the performance monitors, and the ones
>> that don't will be confused by the mf/mtpmr instructions. This
>> allows the support to be optional, so the 8349 can turn it off
>> while the 8379 can turn it on. Sadly, those aren't config options,
>> so it will be left to the defconfigs and the users to make that
>> determination.
>
> So does this mean we can't do multiplatform of something with
> perfmon and
> something without perfmon? Seems like this should come from the
> device
> tree, or PVR, or some other runtime check.
It possible if your binutils supports generating the instructions. I
believe Kim was going to look at doing a patch to use a #define
MFPMR(x)/#define MTPMR() so we don't have to worry about toolchain
versions.
- k
^ permalink raw reply
* interrupt handlers PowerPC via GCC
From: Tehn Yit Chin @ 2008-03-20 0:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Apologies for such a basic question. I am trying to write an ISR on a
MPC551x. When I tried to use the interrupt attribute with
powerpc-eabi-gcc such as
_attribute_((interrupt_handler)) foobarISR(void)
{
}
it complains of a syntax error. Upon further investigation in the GCC,
it appears that the interrupt attribute is not supported by
powerpc-eabi-gcc.
Am I missing something fundamental here? How are the current interrupt
service routines created at the moment?
Any pointers would be appreciated.
tyc
^ permalink raw reply
* Re: simple MPC5200B system
From: Wolfgang Denk @ 2008-03-20 0:14 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <47DF821B.6090600@matrix-vision.de>
In message <47DF821B.6090600@matrix-vision.de> you wrote:
>
> I've pulled the latest git and built a mpc5200_simple system with a
> minimal dts.
> There's not a single char put on the console ....
You did build your device tree with "-b 0", didn't you?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
EMACS belongs in <sys/errno.h>: Editor too big!
^ permalink raw reply
* Re: simple MPC5200B system
From: David Gibson @ 2008-03-20 0:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Andre Schwarz, linux-ppc list
In-Reply-To: <20080320001445.C03DD24A8B@gemini.denx.de>
On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
> In message <47DF821B.6090600@matrix-vision.de> you wrote:
> >
> > I've pulled the latest git and built a mpc5200_simple system with a
> > minimal dts.
> > There's not a single char put on the console ....
>
> You did build your device tree with "-b 0", didn't you?
Ugh.. I really need to fix dtc to pick the default boot cpu value more
sensibly, don't I.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* unprivileged use of MSR_SE
From: Roland McGrath @ 2008-03-20 0:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Are there any powerpc instructions that can read or change the MSR
explicitly from user mode? Any that can see or affect the MSR_SE bit?
e.g. x86 has pushf/popf unprivileged instructions, with which a user
program can both see the single-step flag set, and enable single-step for
its own next instruction (presumably when it has a handler for SIGTRAP).
This actually gets used in arcane places.
I recall being told before there's no unprivileged way to see or touch
MSR_SE. But it looks to me like a user program can set the bit in a
sigcontext and sigreturn to set it. Is that intentionally supported?
Or could sigreturn ignore the MSR_SE bit without breaking any strange user?
On x86 do we some machinations so that PTRACE_GETREGS et al show the
single-step bit set if user-mode itself had set it, but not if
PTRACE_SINGLESTEP set it. If you use PTRACE_SETREGS et al to set the
single-step bit, then it stays set even if you use PTRACE_CONT.
I'd like to clean this up for powerpc too. If there is no way at all for
user-mode to set MSR_SE, then it doesn't much matter whether it shows up
when ptrace reads it--ptrace just needs to ignore attempts to set it. So
if there's no reason not to, what I would do is remove MSR_SE from the
MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.
Does that make sense?
Thanks,
Roland
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-03-20 0:43 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more bug-fixes and a defconfig update for various powerpc
platforms. The defconfig update only updates 9 of the defconfigs but
still dominates the diffstat, since the bug-fixes are all fairly
small.
Thanks,
Paul.
arch/powerpc/boot/Makefile | 4 -
arch/powerpc/boot/wrapper | 4 -
arch/powerpc/configs/cell_defconfig | 141 ++++++++++++++---------
arch/powerpc/configs/celleb_defconfig | 117 ++++++++++++-------
arch/powerpc/configs/chrp32_defconfig | 165 +++++++++++----------------
arch/powerpc/configs/g5_defconfig | 137 ++++++++++++++--------
arch/powerpc/configs/iseries_defconfig | 99 +++++++++++-----
arch/powerpc/configs/pmac32_defconfig | 195 ++++++++++++++++++++------------
arch/powerpc/configs/ppc64_defconfig | 169 +++++++++++++++++-----------
arch/powerpc/configs/ps3_defconfig | 103 ++++++++++-------
arch/powerpc/configs/pseries_defconfig | 136 +++++++++++++---------
arch/powerpc/kernel/process.c | 6 +
arch/powerpc/kernel/ptrace.c | 10 +-
arch/powerpc/mm/slb.c | 6 +
arch/powerpc/platforms/cell/iommu.c | 41 ++++---
arch/powerpc/platforms/cell/setup.c | 36 ++++++
16 files changed, 835 insertions(+), 534 deletions(-)
commit 93ce4e2d2d7404e80d5612fb1cc13d4aad5e42fc
Author: Paul Mackerras <paulus@samba.org>
Date: Thu Mar 20 11:21:32 2008 +1100
[POWERPC] Update some defconfigs
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ebf3a6509299e46c531f88ee727372bd95cf542a
Author: Michael Ellerman <michael@ellerman.id.au>
Date: Wed Mar 19 17:10:55 2008 +1100
[POWERPC] Hide resources on Axon PCIE root complex nodes
The PCI bridge representing the PCIE root complex on Axon, contains
device BARs for a memory range and ROM that define inbound accesses.
This confuses the kernel resource management code -- the resources
need to be hidden when Axon is a host bridge.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 3a4295d101d9654ca909b64c786f9da6ca1bf37a
Author: Michael Ellerman <michael@ellerman.id.au>
Date: Fri Mar 14 16:47:39 2008 +1100
[POWERPC] Fix cell IOMMU code to cope with empty dma-ranges and non-PCI devices
The cell IOMMU code to parse the dma-ranges properties, used for the fixed
mapping, was broken in two ways for some devices.
Firstly it didn't cope with empty dma-ranges properties. An empty property
implies no translation so can be safely skipped.
The code also wrongly assumed it would be looking at PCI devices, and hard
coded the number of address and size cells.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit a72a6f53ddb95723960bb64c011457e9739941d7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Tue Mar 18 16:13:10 2008 +1100
[POWERPC] Fix build failure for tqm8540 and sbc85xx defconfigs
The wrapper script didn't have entries for the TQM8540 board and the
SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
8250 based and not CPM based by looking at its defconfig. There was
also a trailing * on the TQM8555 entry that I removed too.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 44387e9ff25267c78a99229aca55ed750e9174c7
Author: Anton Blanchard <anton@samba.org>
Date: Mon Mar 17 15:27:09 2008 +1100
[POWERPC] Fix PMU + soft interrupt disable bug
Since the PMU is an NMI now, it can come at any time we are only soft
disabled. We must hard disable around the two places we allow the kernel
stack SLB and r1 to go out of sync. Otherwise the PMU exception can
force a kernel stack SLB into another slot, which can lead to it
getting evicted, which can lead to a nasty unrecoverable SLB miss
in the exception entry code.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit c2372eb9bcafdd149b26987a8c25bbed92fd2775
Author: Roland McGrath <roland@redhat.com>
Date: Thu Mar 13 19:25:35 2008 +1100
[POWERPC] user_regset PTRACE_SETREGS regression fix
The PTRACE_SETREGS request was only recently added on powerpc,
and gdb does not use it. So it slipped through without getting
all the testing it should have had.
The user_regset changes had a simple bug in storing to all of
the 32-bit general registers block on 64-bit kernels. This bug
only comes up with PTRACE_SETREGS, not PPC_PTRACE_SETREGS.
It causes a BUG_ON to hit, so this fix needs to go in ASAP.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
From: Linus Torvalds @ 2008-03-20 2:40 UTC (permalink / raw)
To: Roland McGrath
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Paul Mackerras,
Andrew Morton, Ingo Molnar, Richard Henderson
In-Reply-To: <20080319212024.EA03126F995@magilla.localdomain>
On Wed, 19 Mar 2008, Roland McGrath wrote:
>
> The arch_ptrace and compat_arch_ptrace functions can now return
> -ENOSYS for requests they do not actually implement in arch
> code.
Hmm.. I see the whole series, and I see this patch, but I think it adds
new code and new complexity, and I don't really see *why*.
So I'm obviously not going to apply it outside the merge window anyway,
but even for later I'd really like to know what you're building up
towards, because without understanding the upsides it just feels like it
adds ugly code and unnecessary infrastructure without any real point to
it.
And I have to say, I really hate that
ret = arch_ptrace(child, request, addr, data);
if (ret == -ENOSYS && !forced_successful_syscall_return())
ret = ptrace_request(child, request, addr, data);
thing. Instead of doing it that ugly way (return value and a special
per-arch forced_successful_syscall_return() thing), this really smells
like you just want to change the calling conventions for "arch_ptrace()"
instead.
Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
whether it handled things or not?
Linus
^ permalink raw reply
* linux-next: Tree for March 20
From: Stephen Rothwell @ 2008-03-20 3:39 UTC (permalink / raw)
To: linux-next
Cc: Theodore Tso, Greg KH, Dan, LKML, linuxppc-dev, Paul Mackerras,
Williams
[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]
Hi all,
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(tar balls at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64.
I have started this tree by reverting the following:
driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
should be merged late
driver-core/ib-convert-struct-class_device-to-struct-device.patch
conflicts with the infiniband tree
driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
breaks non CONFIG_PM builds of drivers/serial/serial_core.c
There were a few merge conflicts (fairly trivial).
I have added POWERPC-really-export-empty_zero_page.patch and reverted
async-tx commit 9974693221954ef1019f87d32ae26a0757d2ee85 ("dmaengine: ack
to flags: make use of the unused bits in the 'ack' field") as these are
still needed to make powerpc allmodconfig build (in particular ext4 and
drivers/dma/fsldma.c). These have been reported previously.
We are up to 48 trees, more are welcome (even if they are currently
empty). The influx of new trees has slowed completely. Thanks to those
who have contributed, and to those who haven't, please do.
In particular, I have very few of the architecture trees ....
Status of my local build tests is at
http://kisskb.ellerman.id.au/linux-next. If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: unprivileged use of MSR_SE
From: Paul Mackerras @ 2008-03-20 4:10 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev
In-Reply-To: <20080320002407.D911C26F995@magilla.localdomain>
Roland McGrath writes:
> Are there any powerpc instructions that can read or change the MSR
> explicitly from user mode? Any that can see or affect the MSR_SE bit?
No and no.
> e.g. x86 has pushf/popf unprivileged instructions, with which a user
> program can both see the single-step flag set, and enable single-step for
> its own next instruction (presumably when it has a handler for SIGTRAP).
> This actually gets used in arcane places.
On ppc32 there is a sys_debug_setcontext system call that is there to
allow a process to debug itself. It does a setcontext and optionally
sets the MSR_SE or MSR_BE bit. We don't have it on ppc64 for some
reason (we should add it).
> I recall being told before there's no unprivileged way to see or touch
> MSR_SE. But it looks to me like a user program can set the bit in a
> sigcontext and sigreturn to set it. Is that intentionally supported?
The only MSR bit that sigreturn copies from the signal frame back into
the MSR is the MSR_LE (little-endian) bit. I just checked the various
forms (rt/non-rt, 32/64 bit) and they all do that as far as I can
see. If you see a path where we restore more than that let me know.
We do also use the MSR_VEC and MSR_SPE bits in the MSR image in the
signal frame to indicate whether the frame contains altivec or SPE
bits, but those bits don't get put back into the MSR on signal return.
> Or could sigreturn ignore the MSR_SE bit without breaking any strange user?
It already does AFAICS.
> On x86 do we some machinations so that PTRACE_GETREGS et al show the
> single-step bit set if user-mode itself had set it, but not if
> PTRACE_SINGLESTEP set it. If you use PTRACE_SETREGS et al to set the
> single-step bit, then it stays set even if you use PTRACE_CONT.
>
> I'd like to clean this up for powerpc too. If there is no way at all for
> user-mode to set MSR_SE, then it doesn't much matter whether it shows up
> when ptrace reads it--ptrace just needs to ignore attempts to set it. So
> if there's no reason not to, what I would do is remove MSR_SE from the
> MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.
MSR_DEBUGCHANGE is already gone. I don't mind making sigreturn clear
MSR_SE (should setcontext do so too?), but please give me a nice
detailed explanation why we should do that, and why we don't want to
do what we do at present, which is that sigreturn doesn't affect the
process's MSR at all (well, just the LE bit).
Paul.
^ permalink raw reply
* Re: unprivileged use of MSR_SE
From: Paul Mackerras @ 2008-03-20 4:15 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev
In-Reply-To: <20080320002407.D911C26F995@magilla.localdomain>
Roland McGrath writes:
> I'd like to clean this up for powerpc too. If there is no way at all for
> user-mode to set MSR_SE, then it doesn't much matter whether it shows up
> when ptrace reads it--ptrace just needs to ignore attempts to set it. So
> if there's no reason not to, what I would do is remove MSR_SE from the
> MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.
OK, I found MSR_DEBUGCHANGE, it's in ptrace.c. :) So it only applies
to attempts to change the MSR of a process using ptrace. So, what you
want is just to disallow changing MSR via PTRACE_POKEUSR or
equivalent, then?
Paul.
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Randy Dunlap @ 2008-03-20 4:21 UTC (permalink / raw)
To: Stephen Rothwell, v4l-dvb-maintainer
Cc: Theodore Tso, Greg KH, LKML, linuxppc-dev, linux-next,
Paul Mackerras, Dan Williams
In-Reply-To: <20080320143953.8d6b5a60.sfr@canb.auug.org.au>
On Thu, 20 Mar 2008 14:39:53 +1100 Stephen Rothwell wrote:
> Hi all,
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> (tar balls at
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
gcc doesn't like nested /* comments:
next-20080320/drivers/media/video/bt8xx/bttv-cards.c:3030:38: warning: "/*" within comment
next-20080320/drivers/media/video/bt8xx/bttv-cards.c:3032:20: warning: "/*" within comment
---
~Randy
^ permalink raw reply
* [PATCH 2/2] Force 4K IOPages when eHEA is present in the machine.
From: Tony Breeds @ 2008-03-20 4:33 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Olof Johansson, Jan-Bernd Themann
In-Reply-To: <63cdefde19cb2a4adc17ed771f21261673428ce7.1205987625.git.tony@bakeyournoodle.com>
eHEA doesn't work with 64k iopages, If an eHEA /can/ be present in the system
limit iopages to 4k.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/mm/hash_utils_64.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 590f1f6..4fd5e8a 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -302,14 +302,37 @@ static int __init htab_dt_scan_page_sizes(unsigned long node,
return 0;
}
+#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
+static int __init scan_dt_for_ehea(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ if (depth != 0)
+ return 0;
+
+ if (of_flat_dt_search(node, "HEA ", "ibm,drc-names"))
+ return 1;
+
+ return 0;
+}
+#endif
+
+
static void __init htab_init_page_sizes(void)
{
int rc;
+#ifdef CONFIG_PPC_64K_PAGES
+ int has_ehea = 0;
+#endif
/* Default to 4K pages only */
memcpy(mmu_psize_defs, mmu_psize_defaults_old,
sizeof(mmu_psize_defaults_old));
+#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
+ /* Scan to see if this system can have an EHEA, if so we'll
+ * demote io_psize to 4K */
+ has_ehea = of_scan_flat_dt(scan_dt_for_ehea, NULL);
+#endif
/*
* Try to find the available page sizes in the device-tree
*/
@@ -351,9 +374,10 @@ static void __init htab_init_page_sizes(void)
mmu_vmalloc_psize = MMU_PAGE_64K;
if (mmu_linear_psize == MMU_PAGE_4K)
mmu_linear_psize = MMU_PAGE_64K;
- if (cpu_has_feature(CPU_FTR_CI_LARGE_PAGE))
- mmu_io_psize = MMU_PAGE_64K;
- else
+ if (cpu_has_feature(CPU_FTR_CI_LARGE_PAGE)) {
+ if (!has_ehea)
+ mmu_io_psize = MMU_PAGE_64K;
+ } else
mmu_ci_restrictions = 1;
}
#endif /* CONFIG_PPC_64K_PAGES */
--
1.5.4.3
^ permalink raw reply related
* [PATCH 1/2] Implement of_flat_dt_search() and use it for of_flat_dt_is_compatible.
From: Tony Breeds @ 2008-03-20 4:33 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Olof Johansson, Jan-Bernd Themann
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/prom.c | 21 ++++++++++++++-------
include/asm-powerpc/prom.h | 2 ++
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index eac97f4..f73e18b 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -205,25 +205,32 @@ void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
} while(1);
}
-int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
+int __init of_flat_dt_search(unsigned long node, const char *str,
+ const char *prop_name)
{
- const char* cp;
- unsigned long cplen, l;
+ const char *cp;
+ unsigned long plen, l;
- cp = of_get_flat_dt_prop(node, "compatible", &cplen);
+ cp = of_get_flat_dt_prop(node, prop_name, &plen);
if (cp == NULL)
return 0;
- while (cplen > 0) {
- if (strncasecmp(cp, compat, strlen(compat)) == 0)
+ while (plen > 0) {
+ if (strncasecmp(cp, str, strlen(str)) == 0)
return 1;
l = strlen(cp) + 1;
cp += l;
- cplen -= l;
+ plen -= l;
}
return 0;
}
+int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
+{
+
+ return of_flat_dt_search(node, compat, "compatible");
+}
+
static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
unsigned long align)
{
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 78b7b0d..7b587f1 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -134,6 +134,8 @@ extern int __init of_scan_flat_dt(int (*it)(unsigned long node,
void *data);
extern void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
unsigned long *size);
+extern int __init of_flat_dt_search(unsigned long node, const char *str,
+ const char *prop_name);
extern int __init of_flat_dt_is_compatible(unsigned long node, const char *name);
extern unsigned long __init of_get_flat_dt_root(void);
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] Linux >=2.6.24 support for FEC on MPC5200 (not B!)
From: Grant Likely @ 2008-03-20 5:06 UTC (permalink / raw)
To: René Bürgel; +Cc: linuxppc-dev
In-Reply-To: <47D827A5.8040701@unicontrol.de>
On Wed, Mar 12, 2008 at 12:57 PM, Ren=E9 B=FCrgel <r.buergel@unicontrol.de>=
wrote:
> Here is a patch for the lite5200 to get the FEC working again for kernel
> >=3D2.6.24. It was created against Linux 2.6.24.
>
> The FEC driver is also compatible with the MPC5200, not only with the
> MPC5200B, so an according entry was added to the drivers matching list.
> Furthermore the settings for the PHY were entered in the dts file for
> the Lite5200. Note, that this is not exactly the same as in the
> Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
> at :00 for the 5200B. I could test the patch on a Lite5200 and a
> Lite5200B, both booted a kernel via tftp and mounted the root via nfs
> successfully.
> I hope, you can include the patch into the official tree.
Oops, I spoke too soon on picking this up. The patch looks mostly
good, but it does not apply to the head of the tree. Can you please
rebase it on top of Linus' current tree and repost? While you're at
it, I've got a couple of minor comments below that should be
addressed:
> + mdio@3000 {
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + device_type =3D "mdio";
Drop the device_type property
> + compatible =3D "mpc5200-fec-phy";
should be "mpc5200-mdio" (see current lite5200 for the example)
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Greg KH @ 2008-03-20 4:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Theodore Tso, LKML, linuxppc-dev, linux-next, Paul Mackerras,
Dan Williams
In-Reply-To: <20080320143953.8d6b5a60.sfr@canb.auug.org.au>
On Thu, Mar 20, 2008 at 02:39:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> (tar balls at
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source. There are also quilt-import.log and merge.log files
> in the Next directory. Between each merge, the tree was built with
> a ppc64_defconfig for powerpc and an allmodconfig for x86_64.
>
> I have started this tree by reverting the following:
> driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
> should be merged late
> driver-core/ib-convert-struct-class_device-to-struct-device.patch
> conflicts with the infiniband tree
> driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
> breaks non CONFIG_PM builds of drivers/serial/serial_core.c
These should be fixed tomorrow, I have new ones in my inbox to solve
these issues (I hope...)
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Stephen Rothwell @ 2008-03-20 6:17 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Tso, Dan, LKML, linuxppc-dev, linux-next, Paul Mackerras,
Williams
In-Reply-To: <20080320045719.GA26938@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Wed, 19 Mar 2008 21:57:19 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Thu, Mar 20, 2008 at 02:39:53PM +1100, Stephen Rothwell wrote:
> >
> > I have started this tree by reverting the following:
> > driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
> > should be merged late
> > driver-core/ib-convert-struct-class_device-to-struct-device.patch
> > conflicts with the infiniband tree
> > driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
> > breaks non CONFIG_PM builds of drivers/serial/serial_core.c
>
> These should be fixed tomorrow, I have new ones in my inbox to solve
> these issues (I hope...)
Great, I look forward to it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v2] [POWERPC] Add AMCC Glacier 460GT eval board dts
From: Stefan Roese @ 2008-03-20 6:34 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Glacier dts. The Glacier is nearly identical to the
Canyonlands (460EX). Here the differences:
- 4 ethernet ports instead of 2
- no SATA port
- no USB port
Signed-off-by: Stefan Roese <sr@denx.de>
---
This version adds "amcc,glacier" to the toplevel compatible property.
arch/powerpc/boot/dts/glacier.dts | 464 +++++++++++++++++++++++++++++++++++++
1 files changed, 464 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/glacier.dts
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
new file mode 100644
index 0000000..7381cdd
--- /dev/null
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -0,0 +1,464 @@
+/*
+ * Device Tree Source for AMCC Glacier (460GT)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,glacier";
+ compatible = "amcc,glacier", "amcc,canyonlands";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ ethernet2 = &EMAC2;
+ ethernet3 = &EMAC3;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,460GT";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <a 4 b 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460gt";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460gt";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460gt", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460gt", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460gt", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <20>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 6 4
+ /*RXEOB*/ 7 4
+ /*SERR*/ 3 4
+ /*TXDE*/ 4 4
+ /*RXDE*/ 5 4>;
+ desc-base-addr-high = <8>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460gt", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <b0000000 4 b0000000 50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460gt", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupts = <6 4>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1d 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-460gt", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601500 8>;
+ has-mdio;
+ };
+
+ RGMII1: emac-rgmii@ef601600 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601600 8>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601350 30>;
+ };
+
+ TAH1: emac-tah@ef601450 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601450 30>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 10 4
+ /*Wake*/ 1 &UIC2 14 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 11 4
+ /*Wake*/ 1 &UIC2 15 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ tah-device = <&TAH1>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC2: ethernet@ef601100 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC2>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 12 4
+ /*Wake*/ 1 &UIC2 16 4>;
+ reg = <ef601100 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <2>;
+ mal-rx-channel = <10>;
+ cell-index = <2>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC3: ethernet@ef601200 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC3>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 13 4
+ /*Wake*/ 1 &UIC2 17 4>;
+ reg = <ef601200 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <3>;
+ mal-rx-channel = <18>;
+ cell-index = <3>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIX0: pci@c0ec00000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pcix-460gt", "ibm,plb-pcix";
+ primary;
+ large-inbound-windows;
+ enable-msi-hole;
+ reg = <c 0ec00000 8 /* Config space access */
+ 0 0 0 /* no IACK cycles */
+ c 0ed00000 4 /* Special cycles */
+ c 0ec80000 100 /* Internal registers */
+ c 0ec80100 fc>; /* Internal messaging registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+ 01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 0 to 0x3f */
+ bus-range = <0 3f>;
+
+ /* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
+ interrupt-map-mask = <0000 0 0 0>;
+ interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <d 00000000 20000000 /* Config space access */
+ c 08010000 00001000>; /* Registers */
+ dcr-reg = <100 020>;
+ sdr-base = <300>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+ 01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 40 to 0x7f */
+ bus-range = <40 7f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = <d 20000000 20000000 /* Config space access */
+ c 08011000 00001000>; /* Registers */
+ dcr-reg = <120 020>;
+ sdr-base = <340>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+ 01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 80 to 0xbf */
+ bus-range = <80 bf>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.4
^ permalink raw reply related
* Re: [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Stefan Roese @ 2008-03-20 6:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080320102710.4b6d8060.sfr@canb.auug.org.au>
Hi Stephan,
On Thursday 20 March 2008, Stephen Rothwell wrote:
> Just a few trivial things ...
Thanks. Will fix and resubmit.
Best regards,
Stefan
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Olaf Hering @ 2008-03-20 6:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18400.41990.995316.729968@cargo.ozlabs.ibm.com>
On Wed, Mar 19, Paul Mackerras wrote:
> Olaf Hering writes:
>
> > I cant reproduce this bug on my board, but:
> >
> > The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
> > ipic_init() fails. init_ipic_sysfs() will crash in that case.
> >
> > Something like this may fix it:
>
> Is this needed for 2.6.25? Is the system at all usable if ipic_init
> fails?
CONFIG_PPC_MPC51* needs to be disabled for pmac/chrp/bplan .configs.
A full featured ppc32_defconfig will probably catch such errors.
^ permalink raw reply
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