* Re: compile quirk linux-2.6.24 (with workaround)
From: Grant Likely @ 2008-02-05 15:24 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080205091548.724c4e20@zod.rchland.ibm.com>
On 2/5/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > I mean, if you have not included 4xx support in the kernel, as is the
> > case here, it does not make sense to add the 4xx bootwrapper code, no ?
>
> It does, in a manner. There are both generic and platform specific
> pieces to the bootwrapper. Having everything always built helps keep
> the generic bits from breaking, which is important as they're often
> tightly coupled. That's at least the reason I can think of.
>
> The powerpc maintainers have been over this quite a bit and I don't see
> it changing anytime soon.
That would mean we're dropping support for compilers which can't build
405/440 specific wrapper bits (or other core specific quirks that need
to go in the wrapper) That doesn't sound appropriate to me.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Josh Boyer @ 2008-02-05 15:15 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080205143926.GA9709@powerlinux.fr>
On Tue, 5 Feb 2008 15:39:26 +0100
Sven Luther <sven@powerlinux.fr> wrote:
> On Tue, Feb 05, 2008 at 07:08:33AM -0600, Josh Boyer wrote:
> > On Mon, 4 Feb 2008 10:51:21 +0100
> > Sven Luther <sven@powerlinux.fr> wrote:
> >
> > > On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > > > Dear linux powerpc Maintainers and Users,
> > > >
> > > > recently I have tried to compile a new kernel on a Debian sarge ppc
> > > > system (PowerBook5,6 MacRISC3 Power Macintosh).
> > >
> > > This is a G4 based system.
> > >
> > > > The build system bailed out with
> > > > BOOTCC arch/powerpc/boot/4xx.o
> > > > cc1: error: bad value (440) for -mcpu= switch
> > > > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> > > >
> > > > I have tracked this a few steps and the attached patch made the compile for me
> > > > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > > > cannot produce code for 4xx it seems.
> > >
> > > You should normally not need to build the 4xx bootloader part. Make sure
> > > that, i don't know why this happens. Can you look into
> > > arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> > > and make sure it is disabled in the main config ?
> >
> > That's not true. All the wrapper bits are built for every board always.
>
> Yes, which is why it fails. But Should they not be conditionally built
> upon including support or not for the actual board ?
One would think so.
> I mean, if you have not included 4xx support in the kernel, as is the
> case here, it does not make sense to add the 4xx bootwrapper code, no ?
It does, in a manner. There are both generic and platform specific
pieces to the bootwrapper. Having everything always built helps keep
the generic bits from breaking, which is important as they're often
tightly coupled. That's at least the reason I can think of.
The powerpc maintainers have been over this quite a bit and I don't see
it changing anytime soon.
josh
^ permalink raw reply
* Re: [Virtex 4 PPC] Which Linux?
From: Robert Schwebel @ 2008-02-05 14:58 UTC (permalink / raw)
To: IngoM; +Cc: linuxppc-embedded
In-Reply-To: <15268468.post@talk.nabble.com>
On Mon, Feb 04, 2008 at 05:54:55AM -0800, IngoM wrote:
> 2) Linux
> I'd like to build my kernel and filesystem myself. But which way to go?
> Using OE, buildroot, ELDK...
> Can you please provide some starting points for me?
ptxdist would be another alternative.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Problems booting in ML403
From: A. Nolson @ 2008-02-05 14:52 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am having problems while trying to boot my linux kernel 2.6.24-rc3 (
secretlab git). After some days studying this list and other related
documents/wikis about how to make work a linux kernel in my ML403, I
managed to make it work partially.
I am using ELDK 4.1 "uclibc" as a cross compiler. I have also used ELDK
rootfs in my compactflash, when I boot it hangs at some point. This is
my console output:
loaded at: 00400000
005981A0
board data at: 00596124
005961A0
relocated to: 004040DC
00404158
zimage at: 00404ECD
00595EB8
avail ram: 00599000
04000000
Linux/PPC load: console=ttyS0,9600 console=tty0,9600 console=ttyUL0,9600
root=/d
ev/xsa2 rw
init=/sbin/init
Uncompressing
Linux...done.
Now booting the
kernel
[ 0.000000] Linux version 2.6.24-rc3-gd7ed933b-dirty (ios@xxx) (gcc vers
ion 4.0.0 (DENX ELDK 4.1 4.0.0)) #6 Mon Feb 4 14:06:43 CET
2008
[ 0.000000] Xilinx ML403 Reference System (Virtex-4
FX)
[ 0.000000] Zone PFN
ranges:
[ 0.000000] DMA 0 ->
16384
[ 0.000000] Normal 16384 ->
16384
[ 0.000000] HighMem 16384 ->
16384
[ 0.000000] Movable zone start PFN for each
node
[ 0.000000] early_node_map[1] active PFN
ranges
[ 0.000000] 0: 0 ->
16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pag
es:
16256
[ 0.000000] Kernel command line: console=ttyS0,9600 console=tty0,9600
console
=ttyUL0,9600 root=/dev/xsa2 rw
init=/sbin/init
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to
0xFDFFE000
[ 0.000000] PID hash table entries: 256 (order: 8, 1024
bytes)
[ 0.000449] Console: colour dummy device
80x25
[ 0.000546] console [tty0]
enabled
[ 0.002982] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
[ 0.004906] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
[ 0.038813] Memory: 61312k available (2740k kernel code, 784k data,
112k init
, 0k
highmem)
[ 0.039615] SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4,
CPUs=1, N
odes=1
[ 0.220715] Mount-cache hash table entries:
512
[ 0.231019] net_namespace: 64
bytes
[ 0.244246] NET: Registered protocol family
16
[ 0.368073] NET: Registered protocol family
2
[ 0.461661] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.467834] TCP established hash table entries: 2048 (order: 2, 16384
bytes)
[ 0.468813] TCP bind hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.469483] TCP: Hash tables configured (established 2048 bind
2048)
[ 0.469711] TCP reno
registered
[ 0.493382] sysctl table check failed: /kernel/l2cr .1.31 Missing
strategy
[ 0.493825] Call
Trace:
[ 0.493957] [c3c11e80] [c0008380] show_stack+0x4c/0x174
(unreliable)
[ 0.494322] [c3c11eb0] [c0037170]
set_fail+0x50/0x68
[ 0.494637] [c3c11ed0] [c00377f8]
sysctl_check_table+0x670/0x6bc
[ 0.494922] [c3c11f10] [c003780c]
sysctl_check_table+0x684/0x6bc
[ 0.495203] [c3c11f50] [c0024e7c]
register_sysctl_table+0x5c/0xac
[ 0.495533] [c3c11f70] [c034ab68]
register_ppc_htab_sysctl+0x18/0x2c
[ 0.495864] [c3c11f80] [c034484c]
kernel_init+0xc8/0x284
[ 0.496130] [c3c11ff0] [c0004b18]
kernel_thread+0x44/0x60
[ 0.630804] Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
[ 0.642747] JFS: nTxBlock = 479, nTxLock =
3832
[ 0.650497] SGI XFS with ACLs, large block numbers, no debug
enabled
[ 0.687400] io scheduler noop
registered
[ 0.687710] io scheduler anticipatory
registered
[ 0.687880] io scheduler deadline
registered
[ 0.689104] io scheduler cfq registered
(default)
[ 2.129848] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharing
disabled
[ 2.150840] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 3) is a
16550A
[ 2.151248] console [ttyS0]
enabled
[ 5.425398] RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 block
size
[ 5.532502] loop: module
loaded
[ 5.572824] xsysace xsysace.0: Xilinx SystemACE revision
1.0.12
[ 5.645558] xsysace xsysace.0: capacity: 1019088
sectors
[ 5.710732] xsa: xsa1 xsa2
xsa3
[ 5.763112] Xilinx SystemACE device driver,
major=254
[ 5.826421] nbd: registered device at major
43
[ 5.921820] XTemac: using sgDMA
mode.
[ 5.966225] XTemac: using TxDRE
mode
[ 6.009573] XTemac: using RxDRE
mode
[ 6.052783] XTemac: buffer descriptor size: 32768
(0x8000)
[ 6.120289] XTemac: (buffer_descriptor_init) phy: 0x3d80000, virt:
0xff100000
, size:
0x8000
[ 6.231949] eth%d: XTemac: No PHY detected. Assuming a PHY at
address 0
[ 6.313017] eth0: Dropping NETIF_F_SG since no checksum
feature.
[ 6.392778] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5060000,
irq=0
[ 6.476905] eth0: XTemac id 1.0f, block id 5, type
8
[ 6.539381] NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c
$Revision:
1.41
$
[ 6.633905] INFTL: inftlcore.c $Revision: 1.19 $, inftlmount.c
$Revision: 1.1
8
$
[ 6.725083] SSFDC read-only Flash Translation
layer
[ 6.791347] i8042.c: No controller
found.
[ 6.843298] mice: PS/2 mouse device common for all
mice
[ 6.912775] i2c /dev entries
driver
[ 6.958352] TCP cubic
registered
[ 6.998344] NET: Registered protocol family
1
[ 7.051264] NET: Registered protocol family
17
[ 7.110285] RPC: Registered udp transport
module.
[ 7.167370] RPC: Registered tcp transport
module.
[ 9.302726] kjournald starting. Commit interval 5
seconds
[ 9.408788] EXT3 FS on xsa2, internal
journal
[ 9.461599] EXT3-fs: recovery
complete.
[ 9.547744] EXT3-fs: mounted filesystem with ordered data
mode.
[ 9.619378] VFS: Mounted root (ext3
filesystem).
[ 9.675834] Freeing unused kernel memory: 112k
init
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I actually had tried before with the original rootfs that comes with the
given montavista demo, and I got this:
(...)
[ 12.906329] kjournald starting. Commit interval 5 seconds
[ 12.972902] EXT3-fs warning: maximal mount count reached, running
e2fsck is r
ecommended
[ 13.109355] EXT3 FS on xsa2, internal
journal
[ 13.162196] EXT3-fs: recovery
complete.
[ 13.247717] EXT3-fs: mounted filesystem with ordered data
mode.
[ 13.319357] VFS: Mounted root (ext3
filesystem).
[ 13.375883] Freeing unused kernel memory: 112k
init
[ 13.441190] Warning: unable to open an initial
console.
[ 19.728949] eth0: XTemac: Options:
0xb8f2
[ 31.747487] eth0: XTemac: Not able to set the speed to 1000 (status:
0x148)
[ 41.806572] eth0: XTemac: Not able to set the speed to 100 (status:
0x148)
[ 51.864570] eth0: XTemac: Not able to set the speed to 10 (status:
0x148)
[ 51.946095] eth0: XTemac: could not negotiate
speed
[ 52.004713] eth0: XTemac: Send Threshold = 16, Receive Threshold =
2
[ 52.080998] eth0: XTemac: Send Wait bound = 1, Receive Wait bound =
1
[ 64.670479] eth0: XTemac: PHY Link carrier lost.
Stopping here. Any ideas? Is there a problem with my eldk rootfs?
Thanks in advance!
^ permalink raw reply
* Re: [PATCH] Fix legacy serial search for opb bus ports
From: Paul Gortmaker @ 2008-02-05 14:50 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <9efb8c0e313840ccb1bdf918406cdc812ec5de94.1202212897.git.michael@ellerman.id.au>
In message: [PATCH] Fix legacy serial search for opb bus ports
on 05/02/2008 Michael Ellerman wrote:
> The patch to legacy_serial.c (1a7507c7da2df6856e085e0fbb0c9ea8c12ac4e,
> Reduce code duplication in legacy_serial, add UART parent types) changed
> the semantics for opb ports from type = "opb" || compatible = "ibm,opb"
> to type = "opb" && compatible = "ibm,opb".
Ah. I'd originally coded it as an || -- but then Arnd suggested I
condense it further by using of_match_node() -- which was a good idea,
but that is where it accidentally changed to && without me catching it.
Thanks for finding this, and sorry for the debug adventure (I know
vanishing uarts isn't fun).
Paul.
Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> The result is serial ports on our QS21s (Cell blades) don't get found,
> and for some reason the machine doesn't boot at all - possibly it's
> panicking due to lack of a console?
>
> The fix is to add two entries to the of_device_id table, one that looks
> for type = "opb" and the other compatible = "ibm,opb".
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/kernel/legacy_serial.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index 76b862b..61dd174 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -36,7 +36,8 @@ static struct legacy_serial_info {
> static struct __initdata of_device_id parents[] = {
> {.type = "soc",},
> {.type = "tsi-bridge",},
> - {.type = "opb", .compatible = "ibm,opb",},
> + {.type = "opb", },
> + {.compatible = "ibm,opb",},
> {.compatible = "simple-bus",},
> {.compatible = "wrs,epld-localbus",},
> };
> --
> 1.5.2.rc1.1884.g59b20
>
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Sven Luther @ 2008-02-05 14:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080205070833.3a5b7c11@zod.rchland.ibm.com>
On Tue, Feb 05, 2008 at 07:08:33AM -0600, Josh Boyer wrote:
> On Mon, 4 Feb 2008 10:51:21 +0100
> Sven Luther <sven@powerlinux.fr> wrote:
>
> > On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > > Dear linux powerpc Maintainers and Users,
> > >
> > > recently I have tried to compile a new kernel on a Debian sarge ppc
> > > system (PowerBook5,6 MacRISC3 Power Macintosh).
> >
> > This is a G4 based system.
> >
> > > The build system bailed out with
> > > BOOTCC arch/powerpc/boot/4xx.o
> > > cc1: error: bad value (440) for -mcpu= switch
> > > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> > >
> > > I have tracked this a few steps and the attached patch made the compile for me
> > > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > > cannot produce code for 4xx it seems.
> >
> > You should normally not need to build the 4xx bootloader part. Make sure
> > that, i don't know why this happens. Can you look into
> > arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> > and make sure it is disabled in the main config ?
>
> That's not true. All the wrapper bits are built for every board always.
Yes, which is why it fails. But Should they not be conditionally built
upon including support or not for the actual board ?
I mean, if you have not included 4xx support in the kernel, as is the
case here, it does not make sense to add the 4xx bootwrapper code, no ?
Friendly,
Sven Luther
^ permalink raw reply
* Reboot at die_probe
From: Lehmann, Hans (Ritter Elektronik) @ 2008-02-05 13:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi ,
i have strange problems with my cf card driver on our MPC5200 embedded
board. The cf card is mapped to memory space and interrupt is connected
to IRQ1(rising edge sensitive). First the driver was written for Kernel
2.6.14 and worked pretty. Now I ported it to Kernel 2.6.24 and get
strange behaviour I do not understand.
After I load the modul, the kernel start to reboot when i call function
ide_device_add(). The reboot appears while device responses in function
"actual_try_to_identify" (ide-probe.c), after kernel sent the identify
command (0xec) to status/command register (hwif->outb(cmd,
DIE_COMMAND_REG;).=20
To figure out whether card will be identify correct, I changed irq from
edge sensitive to level sensitive and card will be identified proper,
but get error "lost interrupt".
I habe no idea what happend.
Kindly regards
Hans
=20
^ permalink raw reply
* Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'
From: Bernhard Walle @ 2008-02-05 13:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Mariusz Kozlowski, paulus, linux-kernel
In-Reply-To: <20080204144036.cf22a402.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> [2008-02-04 23:40]:
> We did this wrong. We should have introduced a new reserve_bootmem_foo()
> and migrated over to that in stages. Once all callers are migrated, remove
> the old interface.
Well, my original proposal was to add a new function but then someone
complained that we already have too much bootmem functions. I don't
remember if this was on LKML or internally in Bugzilla.
However, sorry, it was my fault of course.
Bernhard
^ permalink raw reply
* Re: [PATCH] [POWERPC] get rid of `model = "UCC"' in the ucc nodes
From: David Gibson @ 2008-02-05 13:20 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, Jon Loeliger
In-Reply-To: <fa686aa40802010823n1b837ffk7110a72e2bd44bf6@mail.gmail.com>
On Fri, Feb 01, 2008 at 09:23:47AM -0700, Grant Likely wrote:
> On 2/1/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > > --- a/Documentation/powerpc/booting-without-of.txt
> > > +++ b/Documentation/powerpc/booting-without-of.txt
> > > @@ -1675,7 +1675,6 @@ platforms are moved over to use the flattened-
> > > device-tree model.
> > > ucc@2000 {
> > > device_type = "network";
> > > compatible = "ucc_geth";
> > > - model = "UCC";
> > > device-id = <1>;
> >
> > can we change device-id to cell-index?
>
> <aside>
> Here's a thought; do we really need a cell-index at all? (and I'm
> talking in general; not just this specific case). I'm starting to
> think we should migrate away from using it.
_Need_ perhaps not, but in some cases I think the alternatives are
overly complex.
> cell-index has been useful for things like clock controllers to know
> what offset into a shared clock control register or something like
> that and a driver would pass the cell-index value to the shared reg
> driver when requesting service.
Right. Except that if the shared resource is just a single register,
calling the routines to access it a "shared reg driver" gives a
misleading impression. Depending on how the shared reg is used, even
a lock may not be necessary, so potentially the drivers for the
individual device instances using the shared resource can (safely)
directly access it.
> However, I think the information
> encoded in cell-index is already encoded in the device tree in a
> different manor.
>
> Typically, shared registers and the like are all chip specific and the
> behaviour of the shared register drivers usually needs to be tweaked
> for different SoCs. Each ip core on an SoC is already uniquely
> indexed via the reg property. True, 'reg' is sparse (0x2000, 0x2200,
> 0x2300, ...) whereas cell-index is tight (0,1,2,3,...), but I don't
> think that introduces any additional difficulty.
>
> So, instead of a driver passing it's cell-index value to the shared
> reg driver, it would pass it's reg base instead. The shared register
> driver could then choose an internal representation that makes sense
> for it instead of whatever layout was chosen by the device tree.
Except that the "shared reg driver" then needs a way to map from reg
property to index. So either it has to have that hardcoded, or the
shared resource will need its own device tree representation for the
mapping.
In some cases the shared resource is complex enough that that makes
sense (e.g. an mdio bus shared between ethernet MACs to take an
extreme example). But when the "shared reg driver" consists entirely
of:
(readl(shared_reg_addr) & (1UL << cell_index))
and/or:
writel(shared_reg_addr, 1UL << cell_index)
your approach would seem to be overkill and then some. (The latter
example can be safe without locking in the case of a read/clear
register).
Exactly this sort of thing is fairly common on 4xx, which is just the
context in which BenH invented "cell-index" as a really simple way of
representing the index into shared registers like this.
> Dropping cell-index would mean one less property to keep in sync when
> tailoring device trees. (== less complexity for board porters).
> Besides, the purpose of cell-index is often misunderstood already by
> people trying to use it to describe port numbers (ttyS0, ttyS1, etc).
This is indeed a problem. But I don't think ditching cell-index
entirely is a sensible solution, sorry.
--
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
* Re: compile quirk linux-2.6.24 (with workaround)
From: Josh Boyer @ 2008-02-05 13:08 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080204095121.GA18167@powerlinux.fr>
On Mon, 4 Feb 2008 10:51:21 +0100
Sven Luther <sven@powerlinux.fr> wrote:
> On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > Dear linux powerpc Maintainers and Users,
> >
> > recently I have tried to compile a new kernel on a Debian sarge ppc
> > system (PowerBook5,6 MacRISC3 Power Macintosh).
>
> This is a G4 based system.
>
> > The build system bailed out with
> > BOOTCC arch/powerpc/boot/4xx.o
> > cc1: error: bad value (440) for -mcpu= switch
> > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> >
> > I have tracked this a few steps and the attached patch made the compile for me
> > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > cannot produce code for 4xx it seems.
>
> You should normally not need to build the 4xx bootloader part. Make sure
> that, i don't know why this happens. Can you look into
> arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> and make sure it is disabled in the main config ?
That's not true. All the wrapper bits are built for every board always.
josh
^ permalink raw reply
* Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'
From: Sergei Shtylyov @ 2008-02-05 13:00 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Mariusz Kozlowski, paulus, bwalle, linux-kernel
In-Reply-To: <20080204144036.cf22a402.akpm@linux-foundation.org>
Hello.
Andrew Morton wrote:
>> This is from ppc32:
>> CC arch/powerpc/mm/mem.o
>>arch/powerpc/mm/mem.c: In function 'do_init_bootmem':
>>arch/powerpc/mm/mem.c:256: error: too few arguments to function 'reserve_bootmem'
>>arch/powerpc/mm/mem.c:261: error: too few arguments to function 'reserve_bootmem'
>>Leftover from introduce-flags-for-reserve_bootmem.patch?
> Yes, I've had to fix that patch many times.
> --- a/arch/powerpc/mm/mem.c~introduce-flags-for-reserve_bootmem-powerpc-fix
> +++ a/arch/powerpc/mm/mem.c
> @@ -253,12 +253,13 @@ void __init do_init_bootmem(void)
> lmb_size_bytes(&lmb.reserved, i) - 1;
> if (addr < total_lowmem)
> reserve_bootmem(lmb.reserved.region[i].base,
> - lmb_size_bytes(&lmb.reserved, i));
> + lmb_size_bytes(&lmb.reserved, i),
> + BOOTMEM_DEFAULT);
> else if (lmb.reserved.region[i].base < total_lowmem) {
> unsigned long adjusted_size = total_lowmem -
> lmb.reserved.region[i].base;
> reserve_bootmem(lmb.reserved.region[i].base,
> - adjusted_size);
> + adjusted_size, BOOTMEM_DWEFAULT);
BOOTMEM_DWEFAULT, are you sure? :-)
WBR, Sergei
^ permalink raw reply
* [PATCH] Fix legacy serial search for opb bus ports
From: Michael Ellerman @ 2008-02-05 12:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paul.gortmaker
The patch to legacy_serial.c (1a7507c7da2df6856e085e0fbb0c9ea8c12ac4e,
Reduce code duplication in legacy_serial, add UART parent types) changed
the semantics for opb ports from type = "opb" || compatible = "ibm,opb"
to type = "opb" && compatible = "ibm,opb".
The result is serial ports on our QS21s (Cell blades) don't get found,
and for some reason the machine doesn't boot at all - possibly it's
panicking due to lack of a console?
The fix is to add two entries to the of_device_id table, one that looks
for type = "opb" and the other compatible = "ibm,opb".
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/legacy_serial.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 76b862b..61dd174 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -36,7 +36,8 @@ static struct legacy_serial_info {
static struct __initdata of_device_id parents[] = {
{.type = "soc",},
{.type = "tsi-bridge",},
- {.type = "opb", .compatible = "ibm,opb",},
+ {.type = "opb", },
+ {.compatible = "ibm,opb",},
{.compatible = "simple-bus",},
{.compatible = "wrs,epld-localbus",},
};
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: Commit for mm/page_alloc.c breaks boot process on my machine
From: Mel Gorman @ 2008-02-05 10:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <1202169686.7079.17.camel@pasglop>
On (05/02/08 11:01), Benjamin Herrenschmidt didst pronounce:
>
> >
> > It's a virtual address so it depends on the value of CONFIG_KERNEL_START
> > as to whether this is a user program address or not.
>
> Shouldn't it be PAGE_OFFSET ? I mean, CONFIG_KERNEL_START should work
> on powerpc, but still...
>
mel@arnold:~/git/linux-2.6$ grep PAGE_OFFSET include/asm-ppc/page.h
#define PAGE_OFFSET CONFIG_KERNEL_START
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Jochen Friedrich @ 2008-02-05 10:01 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: Scott Wood, linuxppc-dev, Paul Mackerras
In-Reply-To: <200802050946.21292.yur@emcraft.com>
Hi Yuri,
> Does anybody use swap with some of the 8xx-based boards supported in
> powerpc branch ?
modded DBox2 boxes do. Unfortunately, i don't have such a modded box.
The tuxbox project currently uses a really ugly hack to support swapping:
http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=commitdiff;h=fc9d6ed33d85933f3900718a118a0cc2b776f067
Thanks,
Jochen
^ permalink raw reply
* powerPC 860 Port to asm/powerpc, early_dev_init problem
From: Gray, Steve - UK @ 2008-02-05 9:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi List
I have a PPC860 on our own embedded platform.
I using a denx kernel snapshot from the git repository date 4 Feb 2008
I am using U-boot 1.3.1 with CONFIG_OF_LIBFDT enable, and have ported
into the kernel tree, the necessary makefiles and Kconfig changes, to
give me a kernel that now compiles,
I am able to get this to work as required with asm/ppc, and drop to a
Busybox prompt and mount rootFS over NFS
Oon reading the list this will be dropped this summer, so I have
undertaken the role to port this into the asm/powerpc branch.
I have a problem that I am not able to understand and am looking to the
list for some help.
Using a BDI-3000 I can step through the kernel startup code and
encounter a problem as described below
early_init_devtree prom.c @ line 1042, params =3D 0x7ffec0
Call of_scan_flat_dt prom.c @ line 1058 now my debugger is showing the
passed value as 0xc07ffec0
This now results in a bus error when accessing *p at line 104 of prom.c
This Flat device tree is new to me, and to many others I guess.=20
Im pretty sure that I may of simply overlooked something with this new
flat device tree but am not sure what.=20
I also don't understand why the parameter has changed?
Can any body point me back into the right direction?
Thanks in advance
Steve
^ permalink raw reply
* Re: [PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso.
From: Chirag Jog @ 2008-02-05 9:07 UTC (permalink / raw)
To: Tony Breeds
Cc: linuxppc-dev, Sripathi Kodi, paulus, linux-kernel, john stultz
In-Reply-To: <20080205051648.GX6887@bakeyournoodle.com>
* Tony Breeds <tony@bakeyournoodle.com> [2008-02-05 16:16:48]:
> On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> > Hi Paul,
> >
> > On PPC, I see a disparity between clock_getres implementations in the
> > vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> > with CONFIG_HIGH_RES_TIMERS=y.
> >
> > clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
> > when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
> > sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
> > to be returning some pre-defined (incorrect) variables.
> >
> > Could you please let me know the reason for this? Is it something that
> > should be fixed in vdso?
>
> Can you try the attached patch and see it if works for you?
I tried this patch.
It seems to solve the reported problem and give a 1ns resolution.
Thanks.
--
Cheers,
Chirag Jog
^ permalink raw reply
* Re: [PATCH] [POWERPC] iSeries: fix section mismatch in viocd
From: Jens Axboe @ 2008-02-05 8:17 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20080205141731.49a91ed4.sfr@canb.auug.org.au>
On Tue, Feb 05 2008, Stephen Rothwell wrote:
> WARNING: drivers/cdrom/viocd.o(.text+0x504): Section mismatch in reference from the function .viocd_probe() to the function .init.text:.find_capability()
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/cdrom/viocd.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Jens, can this go in through the powerpc tree?
Certainly
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Benjamin Herrenschmidt @ 2008-02-05 7:37 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200802021047.32055.yur@emcraft.com>
On Sat, 2008-02-02 at 10:47 +0300, Yuri Tikhonov wrote:
> Hello,
>
> Here is the patch which makes Linux-2.6 swap routines operate correctly on
> the ppc-8xx-based machines.
Best is to just remove writeback completely and let the generic
code handle it.
Ben.
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
> --
> diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
> index eb8d26f..321bda2 100644
> --- a/arch/ppc/kernel/head_8xx.S
> +++ b/arch/ppc/kernel/head_8xx.S
> @@ -329,8 +329,18 @@ InstructionTLBMiss:
> mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
> lwz r10, 0(r11) /* Get the pte */
>
> +#ifdef CONFIG_SWAP
> + /* do not set the _PAGE_ACCESSED bit of a non-present page */
> + andi. r11, r10, _PAGE_PRESENT
> + beq 4f
> + ori r10, r10, _PAGE_ACCESSED
> + mfspr r11, SPRN_MD_TWC /* get the pte address again */
> + stw r10, 0(r11)
> +4:
> +#else
> ori r10, r10, _PAGE_ACCESSED
> stw r10, 0(r11)
> +#endif
>
> /* The Linux PTE won't go exactly into the MMU TLB.
> * Software indicator bits 21, 22 and 28 must be clear.
> @@ -395,8 +405,17 @@ DataStoreTLBMiss:
> DO_8xx_CPU6(0x3b80, r3)
> mtspr SPRN_MD_TWC, r11
>
> - mfspr r11, SPRN_MD_TWC /* get the pte address again */
> +#ifdef CONFIG_SWAP
> + /* do not set the _PAGE_ACCESSED bit of a non-present page */
> + andi. r11, r10, _PAGE_PRESENT
> + beq 4f
> + ori r10, r10, _PAGE_ACCESSED
> +4:
> + /* and update pte in table */
> +#else
> ori r10, r10, _PAGE_ACCESSED
> +#endif
> + mfspr r11, SPRN_MD_TWC /* get the pte address again */
> stw r10, 0(r11)
>
> /* The Linux PTE won't go exactly into the MMU TLB.
> @@ -575,7 +594,16 @@ DataTLBError:
>
> /* Update 'changed', among others.
> */
> +#ifdef CONFIG_SWAP
> + ori r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE
> + /* do not set the _PAGE_ACCESSED bit of a non-present page */
> + andi. r11, r10, _PAGE_PRESENT
> + beq 4f
> + ori r10, r10, _PAGE_ACCESSED
> +4:
> +#else
> ori r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
> +#endif
> mfspr r11, SPRN_MD_TWC /* Get pte address again */
> stw r10, 0(r11) /* and update pte in table */
>
> diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
> index c159315..76717ff 100644
> --- a/include/asm-ppc/pgtable.h
> +++ b/include/asm-ppc/pgtable.h
> @@ -341,14 +341,6 @@ extern unsigned long ioremap_bot, ioremap_base;
> #define _PMD_PAGE_MASK 0x000c
> #define _PMD_PAGE_8M 0x000c
>
> -/*
> - * The 8xx TLB miss handler allegedly sets _PAGE_ACCESSED in the PTE
> - * for an address even if _PAGE_PRESENT is not set, as a performance
> - * optimization. This is a bug if you ever want to use swap unless
> - * _PAGE_ACCESSED is 2, which it isn't, or unless you have 8xx-specific
> - * definitions for __swp_entry etc. below, which would be gross.
> - * -- paulus
> - */
> #define _PTE_NONE_MASK _PAGE_ACCESSED
>
> #else /* CONFIG_6xx */
>
^ permalink raw reply
* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Yuri Tikhonov @ 2008-02-05 6:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080204182421.GA3930@loki.buserror.net>
Hi Scott,
You are right. The TLB handlers for 8xx in arch/powerpc branch set the
PAGE_ACCESSED flag unconditionally too. And the
include/asm-powerpc/pgtable-ppc32.h file still includes the comment that this
is the bug. So, probably the corresponding patch for powerpc branch will be
usefull. Does anybody use swap with some of the 8xx-based boards supported in
powerpc branch ?
Regards, Yuri
On Monday 04 February 2008 21:24, Scott Wood wrote:
> On Sat, Feb 02, 2008 at 12:22:17PM +0100, Jochen Friedrich wrote:
> > Hi Yuri,
> >
> > > Here is the patch which makes Linux-2.6 swap routines operate correctly
on
> > > the ppc-8xx-based machines.
> >
> > is there any 8xx board left which isn't ported to ARCH=powerpc?
>
> More importantly, is this something that is also broken in arch/powerpc? It
> looks like it has the same code...
>
> -Scott
>
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
^ permalink raw reply
* Re: [PATCH 5/6] Add OF-tree support to RapidIO controller driver.
From: Stephen Rothwell @ 2008-02-05 5:44 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <12016890832943-git-send-email-wei.zhang@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
On Wed, 30 Jan 2008 18:30:52 +0800 Zhang Wei <wei.zhang@freescale.com> wrote:
>
> -void fsl_rio_setup(int law_start, int law_size)
> +int fsl_rio_setup(struct of_device *dev)
> {
> + if (!dev->node) {
> + dev_err(&dev->dev, "Device OF-Node is NULL");
> + return -EFAULT;
Probably -EINVAL would be better. Here and all the other -EFAULTs.
> + aw = *(u32 *)of_get_property(dev->node, "#address-cells", NULL);
> + sw = *(u32 *)of_get_property(dev->node, "#size-cells", NULL);
What happens if either of these properties is missing?
> +static struct of_device_id fsl_of_rio_rpn_ids[] = {
This should be "const" please.
--
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] [POWERPC] Use a sensible default for clock_getres() in the vdso.
From: Tony Breeds @ 2008-02-05 5:16 UTC (permalink / raw)
To: Sripathi Kodi; +Cc: linuxppc-dev, paulus, linux-kernel, john stultz
In-Reply-To: <200801271932.59823.sripathik@in.ibm.com>
On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> Hi Paul,
>
> On PPC, I see a disparity between clock_getres implementations in the
> vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> with CONFIG_HIGH_RES_TIMERS=y.
>
> clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
> when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
> sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
> to be returning some pre-defined (incorrect) variables.
>
> Could you please let me know the reason for this? Is it something that
> should be fixed in vdso?
Can you try the attached patch and see it if works for you?
From: Tony Breeds <tony@bakeyournoodle.com>
Subject: [PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso.
This ensures that the syscall and the (fast) vdso versions of clock_getres()
will return the same resolution.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/asm-offsets.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index ed083fe..e6e4928 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -22,6 +22,7 @@
#include <linux/mman.h>
#include <linux/mm.h>
#include <linux/suspend.h>
+#include <linux/hrtimer.h>
#ifdef CONFIG_PPC64
#include <linux/time.h>
#include <linux/hardirq.h>
@@ -312,7 +313,7 @@ int main(void)
DEFINE(CLOCK_REALTIME, CLOCK_REALTIME);
DEFINE(CLOCK_MONOTONIC, CLOCK_MONOTONIC);
DEFINE(NSEC_PER_SEC, NSEC_PER_SEC);
- DEFINE(CLOCK_REALTIME_RES, TICK_NSEC);
+ DEFINE(CLOCK_REALTIME_RES, (KTIME_MONOTONIC_RES).tv64);
#ifdef CONFIG_BUG
DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry));
--
1.5.4
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] [POWERPC] of: add alias helper functions.
From: Stephen Rothwell @ 2008-02-05 4:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, davem, david
In-Reply-To: <20080204161604.10674.9289.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
Hi Grant,
On Mon, 04 Feb 2008 09:16:08 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Add helper functions for translating back and forth between alias
> properties and device tree nodes.
Do you have a use for this yet (I assume you do - it would be nice to
have a reason in the changelog)?
Overall looks ok, just a few comments?
Dave (Miller) is this useful for Sparc?
> +struct device_node *of_find_node_by_alias(const char *alias)
> +{
> + struct device_node *np, *alias_np;
> + const char *path;
> +
> + np = NULL;
struct device_node *np = NULL;
struct device_node *alias_np;
> +const char *of_node_alias(struct device_node *np, const char *prefix)
> + /* Loop over the aliases looking for a match */
> + alias = NULL;
> + for (pp = alias_np->properties; pp != 0; pp = pp->next) {
^
Use NULL for pointers (or just test "pp").
> + if (test_np == np)
> + alias = pp->name + prefix_len;
> + of_node_put(test_np);
> + if (alias)
> + break;
This could be:
of_node_put(test_np);
if (test_np == np) {
alias = pp->name + prefix_len;
break;
}
As you can still test for pointer equality after dropping the ref count.
--
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] [POWERPC] iSeries: fix section mismatch in iseries_veth
From: Stephen Rothwell @ 2008-02-05 3:19 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Jeff Garzik, netdev
WARNING: vmlinux.o(.text+0x25dca0): Section mismatch in reference from the function .veth_probe() to the function .init.text:.veth_probe_one()
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/iseries_veth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Jeff, can this go in through the powerpc tree?
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index 419861c..58d3bb6 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -1020,7 +1020,7 @@ static const struct ethtool_ops ops = {
.get_link = veth_get_link,
};
-static struct net_device * __init veth_probe_one(int vlan,
+static struct net_device *veth_probe_one(int vlan,
struct vio_dev *vio_dev)
{
struct net_device *dev;
--
1.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: fix section mismatch in viocd
From: Stephen Rothwell @ 2008-02-05 3:17 UTC (permalink / raw)
To: paulus; +Cc: Jens Axboe, ppc-dev
WARNING: drivers/cdrom/viocd.o(.text+0x504): Section mismatch in reference from the function .viocd_probe() to the function .init.text:.find_capability()
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/cdrom/viocd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Jens, can this go in through the powerpc tree?
diff --git a/drivers/cdrom/viocd.c b/drivers/cdrom/viocd.c
index 8473b9f..cac06bc 100644
--- a/drivers/cdrom/viocd.c
+++ b/drivers/cdrom/viocd.c
@@ -558,7 +558,7 @@ static struct cdrom_device_ops viocd_dops = {
.capability = CDC_CLOSE_TRAY | CDC_OPEN_TRAY | CDC_LOCK | CDC_SELECT_SPEED | CDC_SELECT_DISC | CDC_MULTI_SESSION | CDC_MCN | CDC_MEDIA_CHANGED | CDC_PLAY_AUDIO | CDC_RESET | CDC_DRIVE_STATUS | CDC_GENERIC_PACKET | CDC_CD_R | CDC_CD_RW | CDC_DVD | CDC_DVD_R | CDC_DVD_RAM | CDC_RAM
};
-static int __init find_capability(const char *type)
+static int find_capability(const char *type)
{
struct capability_entry *entry;
--
1.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: fix section mismatch in viodsasd
From: Stephen Rothwell @ 2008-02-05 3:15 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
WARNING: vmlinux.o(.text+0x3017c): Section mismatch in reference from the function .vio_create_viodasd() to the function .devinit.text:.vio_register_device_node()
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/vio.c | 2 +-
include/asm-powerpc/vio.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index f0bad70..f988672 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -176,7 +176,7 @@ static void __devinit vio_dev_release(struct device *dev)
* Returns a pointer to the created vio_dev or NULL if node has
* NULL device_type or compatible fields.
*/
-struct vio_dev * __devinit vio_register_device_node(struct device_node *of_node)
+struct vio_dev *vio_register_device_node(struct device_node *of_node)
{
struct vio_dev *viodev;
const unsigned int *unit_address;
diff --git a/include/asm-powerpc/vio.h b/include/asm-powerpc/vio.h
index 9204c15..56512a9 100644
--- a/include/asm-powerpc/vio.h
+++ b/include/asm-powerpc/vio.h
@@ -66,7 +66,7 @@ extern void __devinit vio_unregister_device(struct vio_dev *dev);
struct device_node;
-extern struct vio_dev * __devinit vio_register_device_node(
+extern struct vio_dev *vio_register_device_node(
struct device_node *node_vdev);
extern const void *vio_get_attribute(struct vio_dev *vdev, char *which,
int *length);
--
1.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
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