* 2.6.18-rc3->rc4 hugetlbfs regression
From: Dave Hansen @ 2006-08-15 15:22 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-mm
Cc: Suzuki Kp, PPC External List, Yao Fei Zhu, lge,
Nishanth Aravamudan
kernel BUG in cache_free_debugcheck at mm/slab.c:2748!
This is from a ppc64 machine running 2.6.18-rc4. It didn't apparently
happen with 2.6.18-rc3, but I don't see anything particularly suspect in
the changelogs, so it might be a wee bit more intermittent than it first
appeared.
You can get libhugetlbfs from here: http://libhugetlbfs.sourceforge.net/
Steps to reproduce:
1. boot kernel 2.6.18-rc4 with "hugepages=20"
2. mount none -t hugetlbfs /mnt/hugetlbfs
3. run libhugetlbfs, "make check" trigger xmon.
apple-lp1:/kernel/libhugetlbfs.git # make check
zero_filesize_segment (32): obj32/zero_filesize_segment:
obj32/zero_filesize_segment: cannot execute binary file
zero_filesize_segment (64): obj64/zero_filesize_segment:
obj64/zero_filesize_segment: cannot execute binary file
test_root (32): PASS
test_root (64): PASS
meminfo_nohuge (32): PASS
meminfo_nohuge (64): PASS
gethugepagesize (32): PASS
gethugepagesize (64): PASS
empty_mounts (32): PASS
empty_mounts (64): PASS
find_path (32): PASS
find_path (64): PASS
unlinked_fd (32): PASS
unlinked_fd (64): PASS
readback (32): PASS
Additional info:
0:mon> e
cpu 0x0: Vector: 700 (Program Check) at [c0000001cf6e3530]
pc: c0000000000c7458: .cache_free_debugcheck+0x1d0/0x2b0
lr: c0000000000c7410: .cache_free_debugcheck+0x188/0x2b0
sp: c0000001cf6e37b0
msr: 8000000000021032
current = 0xc0000001ccaf94e0
paca = 0xc000000000622300
pid = 6714, comm = readback
kernel BUG in cache_free_debugcheck at mm/slab.c:2748!
0:mon> t
[c0000001cf6e37b0] c0000000000c73cc .cache_free_debugcheck+0x144/0x2b0 (unreliable)
[c0000001cf6e3860] c0000000000c7a04 .kmem_cache_free+0xd8/0x164
[c0000001cf6e3900] c00000000002f630 .pgtable_free_tlb+0xd4/0x144
[c0000001cf6e39a0] c000000000032648 .hugetlb_free_pgd_range+0x1b8/0x26c
[c0000001cf6e3a70] c0000000000b4f68 .free_pgtables+0x90/0x134
[c0000001cf6e3b20] c0000000000b61ac .exit_mmap+0xcc/0x180
[c0000001cf6e3bd0] c00000000006209c .mmput+0x70/0x148
[c0000001cf6e3c60] c000000000067288 .exit_mm+0x118/0x138
[c0000001cf6e3cf0] c0000000000692c4 .do_exit+0x21c/0x958
[c0000001cf6e3da0] c000000000069aa8 .sys_exit_group+0x0/0x8
[c0000001cf6e3e30] c00000000000871c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000feb0b78
SP (ffcc4090) is in userspace
0:mon> r
R00 = 000000000000018f R16 = 00000000100a0000
R01 = c0000001cf6e37b0 R17 = 00000000100b2eb0
R02 = c000000000849ce0 R18 = 00000000100a0000
R03 = c0000001cfe90a08 R19 = 0000000000000000
R04 = c0000001cfe90a10 R20 = 0000000000000000
R05 = ffffffffffffffff R21 = 00000000e0ffffff
R06 = 0000000000000000 R22 = c0000001cf6e3b90
R07 = c000000000648c38 R23 = 00000000e0ffffff
R08 = 000000000001ffff R24 = 00000000e1000000
R09 = 0000000000000001 R25 = c00000000002f630
R10 = 0000000000000019 R26 = c0000001cfe90000
R11 = 0000000000000850 R27 = 0000000000000000
R12 = 0000000000000001 R28 = c0000001cfe90978
R13 = c000000000622300 R29 = 000000000000000e
R14 = 0000000010080000 R30 = c00000000065f098
R15 = 0000000000000000 R31 = c000000002b14380
pc = c0000000000c7458 .cache_free_debugcheck+0x1d0/0x2b0
lr = c0000000000c7410 .cache_free_debugcheck+0x188/0x2b0
msr = 8000000000021032 cr = 44000424
ctr = 0000000000000001 xer = 000000002000001a trap = 700
0:mon> di c0000000000c7458
c0000000000c7458 0b090000 tdnei r9,0
c0000000000c745c 801f0118 lwz r0,280(r31)
c0000000000c7460 7809bfe3 rldicl. r9,r0,55,63
c0000000000c7464 41820034 beq c0000000000c7498 #
.cache_free_debugcheck+0x210/0x2b0
c0000000000c7468 e93f0148 ld r9,328(r31)
c0000000000c746c e87f01d2 lwa r3,464(r31)
c0000000000c7470 7fe4fb78 mr r4,r31
c0000000000c7474 38a00005 li r5,5
c0000000000c7478 e9690000 ld r11,0(r9)
c0000000000c747c f8410028 std r2,40(r1)
c0000000000c7480 7c7c1a14 add r3,r28,r3
c0000000000c7484 7d6903a6 mtctr r11
c0000000000c7488 e8490008 ld r2,8(r9)
c0000000000c748c e9690010 ld r11,16(r9)
c0000000000c7490 4e800421 bctrl
c0000000000c7494 e8410028 ld r2,40(r1)
The BUG() hit here :
*dbg_redzone1(cachep, objp) = RED_INACTIVE;
*dbg_redzone2(cachep, objp) = RED_INACTIVE;
}
if (cachep->flags & SLAB_STORE_USER)
*dbg_userword(cachep, objp) = caller;
objnr = obj_to_index(cachep, slabp, objp);
BUG_ON(objnr >= cachep->num);
BUG_ON(objp != index_to_obj(cachep, slabp, objnr)); <---- Hit here.
if (cachep->flags & SLAB_DEBUG_INITIAL) {
/*
-- Dave
^ permalink raw reply
* No Clock on SPI
From: GSM909 @ 2006-08-15 16:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I´m writing a Driver for SPI. That is not working now.
I have a MPC8260 using Linux 2.6.14 (rheap patch).
Did someone else write a driver for SPI on this µC or an other driver? So I can see what i did wrong?
My SPCOM[STR] flag isn´t cleared automatically after one clock cycle.
What here going wrong ? ( I know this register is write only)
There is also no Clock on my SPICLK.
How I have to allocate the Memory for the BD´s and the buffer for the BD´s?
Is there something special when I allocate Memory for my Parameter Ram?
Is something wrong with the 2.6 Kernel so i have to use the 2.4 Kernel ?
I hope somebody could help. Thx
Regards
Fred
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
^ permalink raw reply
* A working SPI driver in linux
From: Purvis, Craig @ 2006-08-15 18:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 159 bytes --]
Hello Navin,
Could I have a copy of your SPI driver files.
Thanks!
Craig Purvis
HW Drivers Team Lead
Mentor Graphics, Embedded Systems Division
[-- Attachment #2: Type: text/html, Size: 917 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Olof Johansson @ 2006-08-15 19:05 UTC (permalink / raw)
To: James K Lewis
Cc: Arnd Bergmann, Jens Osterkamp, linux-kernel, linuxppc-dev, netdev,
Olof Johansson
In-Reply-To: <OF934FE4E3.EEC44FDD-ON872571C7.00668651-862571C7.00677A44@us.ibm.com>
On Fri, Aug 11, 2006 at 01:50:19PM -0500, James K Lewis wrote:
> Hi Olof,
>
> There are several reasons why an Ethernet driver should have an up to
> date version number:
>
> 1. Customers like to see they are really getting a new version.
>
> 2. It makes it easier for support personnel (me in this case) to see which
> driver they have. Sure, sometimes I can talk them thru doing a "sum" on
> the .ko and all that, but why not just use the version number? That's what
> it is for. And no, you can't just assume they have the version that came
> with the kernel they are running. It doesn't work that way.
>
> 3. It makes bug reporting easier.
>
> 4. I have already run into too many problems and wasted too much time
> working with drivers when the number was NOT getting updated.
Thanks for the info, Jim.
Sounds like it's most useful if a customer (or distro) takes the driver
out of the tree and run it with a different kernel, i.e. when kernel
and driver versions no longer go together. Makes sense.
-Olof
^ permalink raw reply
* Re: [PATCH 0/6] bootwrapper: arch/powerpc/boot code reorg patches
From: Hollis Blanchard @ 2006-08-15 19:37 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060808191450.GA10108@mag.az.mvista.com>
On Tue, 2006-08-08 at 12:14 -0700, Mark A. Greer wrote:
> Just a note that I will respin my patches to address all of your
> comments. However, it looks like the fdt code is going to change
> to use code from a common source base. I'm going to wait until
> that has settled and then I'll modify the code and repost the patches.
By the way, I don't expect the (ft_build.h) interface to change much
from what I emailed last week. So I think it's safe to build on top of
those.
The only addition I'd like to make is creating an ft_set_prop() that
will handle resizing the tree for you. With that change, you wouldn't
ft_get_prop() and then write directly to that pointer (as is done
currently).
I'm still waiting to hear the outcome of Matt's patches. I don't need
them, but if u-boot does then I'll have to merge them into the
standalone code.
-Hollis
^ permalink raw reply
* CPM2 UARTs: Won't work under low (<= 1200BD) baudrates?
From: David Tao @ 2006-08-15 19:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
Hello, guys,
I found that MPC8270 CPM UARTs, both SMCs and SCCs won't work under low baudrate.
Under 2400 baud or above the UARTs work fine, but once the baudrate set to 1200 or below, there is NO data can be sent out or received even programed to do so.
I am using Linux kernel 2.6.15 (from Denx ELDK4.0).
Can anybody help on this? Thanks in advance.
David
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
[-- Attachment #2: Type: text/html, Size: 623 bytes --]
^ permalink raw reply
* [RFC] Updated cuImage target
From: Matthew McClintock @ 2006-08-15 20:00 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I have mostly completed reworking a new cuImage target based off the
previous discussion. There are several changes from the version I
presented previously. So to summarize these changes, the cuImage
consists of the following:
1) A copy of the kernel is the first section in the cuImage target.
Furthermore, it is now a binary section (vs. elf for the zImage target).
More on this later.
2) The bootwrapper follows the kernel section.
3) The cuImage target automatically creates the 'uImage' which is
bootable by u-boot. The correct offset to the bootwrapper is set as the
entry point, and the load address is 0x0 to prevent excessive copying of
the data.
So now, when u-boot attempts to load the cuImage with the 'bootm'
command it now extracts the image (the decompression is handled by
u-boot) to the 0x0, and then jumps to the bootwrapper start address
located after the kernel image.
The bootwrapper code executes and fixes up a flat device tree for use by
the kernel proper, and then jumps the 0x0 and the kernel starts up. The
patch below consists of two things:
1) Makefile, Linker script, Config changes to allow the new cuImage
target
2) Beginning of work to allow the boot wrapper to create a correct flat
device tree for a Sandpoint board based off information passed to via
the board device structure.
Mark's boot wrapper patches and Sandpoint patches are required for this
to work.
-Matthew
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..cf7b7e0 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -146,7 +146,7 @@ all: $(KBUILD_IMAGE)
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin cuImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index daad857..77a0eb7 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -223,3 +223,53 @@ install: $(CONFIGURE) $(BOOTIMAGE)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+
+#-----------------------------------------------------------
+# build compatiblity u-boot images
+#-----------------------------------------------------------
+
+targets += cuImage
+
+quiet_cmd_cobjbin = OBJCOPY $@
+ cmd_cobjbin = $(OBJCOPY) --set-section-flags=.bss=$(OBJCOPYFLAGS)
--gap-fill=0xff -O binary $< $@
+
+uiet_cmd_cuimage = UIMAGE $@
+ cmd_cuimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T
kernel \
+ -C gzip -a 0x0 -e $2 -n 'Linux-$(KERNELRELEASE)' -d $< $@
+
+quiet_cmd_addsection_cuimage = ADDSEC $@
+ cmd_addsection_cuimage = $(CROSS32OBJCOPY) $@ \
+ --add-section=.kernel:vmlinux.bin=$(obj)/vmlinux-cuimage.bin \
+ --set-section-flags=.kernel:vmlinux.bin=$(OBJCOPYFLAGS)
+
+$(obj)/vmlinux-cuimage.bin: vmlinux FORCE
+ $(call if_changed,cobjbin)
+
+$(obj)/kernel-compat.c:
+ @touch $@
+
+$(obj)/kernel-compat.o: $(obj)/kernel-compat.c
$(obj)/vmlinux-cuimage.bin
+ $(call if_changed_dep,bootcc)
+ $(call cmd,addsection_cuimage)
+
+$(obj)/vmlinux-compat.elf: $(obj-boot) $(obj)/kernel-compat.o
+ $(call cmd,bootld,$(obj-boot) $(obj)/kernel-compat.o,cuImage.lds)
+ # need a more automated way to do this
+ sh fdt_attach.sh --fdt ../sandpoint_v3.dtb
arch/powerpc/boot/vmlinux-compat.elf
+
+$(obj)/vmlinux-compat.bin: $(obj)/vmlinux-compat.elf
+ $(call if_changed,objbin)
+
+$(obj)/vmlinux-compat.gz: $(obj)/vmlinux-compat.bin
+ $(call if_changed,mygzip)
+
+ENTRY=`objdump -t arch/powerpc/boot/vmlinux-compat.elf | gawk --
'{if($$5=="_zimage_start") {print $$1;}}'`
+
+$(obj)/cuImage: $(obj)/vmlinux-compat.gz $(obj-boot)
+ $(Q)rm -f $@
+ $(call cmd,cuimage,$(ENTRY))
+ @echo -n ' Image: $@ '
+ @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
+
+clean-files += vmlinux-compat.elf vmlinux-compat.bin vmlinux-compat.gz
cuImage kernel-compat.c
+
diff --git a/arch/powerpc/boot/cuImage.lds
b/arch/powerpc/boot/cuImage.lds
new file mode 100644
index 0000000..073e19c
--- /dev/null
+++ b/arch/powerpc/boot/cuImage.lds
@@ -0,0 +1,45 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_zimage_start)
+SECTIONS
+{
+ . = 0;
+
+ _vmlinux_start = .;
+ .kernel:vmlinux.bin : { *(.kernel:vmlinux.bin) }
+ _vmlinux_end = .;
+
+/* initrd still needs work */
+ _initrd_start = .;
+ _initrd_end = .;
+
+ _start = .;
+ .text :
+ {
+ *(.text)
+ *(.fixup)
+ }
+ _etext = .;
+ . = ALIGN(4096);
+ .data :
+ {
+ *(.rodata*)
+ *(.data*)
+ *(.sdata*)
+ __got2_start = .;
+ *(.got2)
+ __got2_end = .;
+ }
+
+ . = ALIGN(4096);
+ _edata = .;
+
+ . = ALIGN(4096);
+ __bss_start = .;
+ .bss :
+ {
+ *(.sbss)
+ *(.bss)
+ }
+ . = ALIGN(4096);
+ _end = . ;
+}
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index 0e49f58..a67844b 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -286,7 +286,7 @@ void start(unsigned long a1, unsigned lo
memset(__bss_start, 0, _end - __bss_start);
- ops = platform_init(promptr);
+ ops = platform_init(promptr, a1);
/* Override the dt_ops if there was an fdt attached to the zImage */
if (strcmp(dt_blob_start, EMPTY_SECTION_STR))
@@ -301,7 +301,8 @@ void start(unsigned long a1, unsigned lo
if (ops->platform_ops->fixups)
ops->platform_ops->fixups();
- prep_kernel(&a1, &a2, sp);
+ if (((unsigned long)_vmlinux_start) != 0)
+ prep_kernel(&a1, &a2, sp);
/* If cmdline came from zimage wrapper or if we can edit the one
* in the dt, print it out and edit it, if possible.
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 94d97b0..354d0a6 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -65,7 +65,7 @@ struct ops {
extern struct ops *ops;
-extern struct ops *platform_init(void *promptr);
+extern struct ops *platform_init(void *promptr, unsigned long a1);
extern struct fw_ops *dink_init(void);
extern struct dt_ops *fdt_init(void *dt_blob);
extern struct console_ops *ns16550_init(void);
diff --git a/arch/powerpc/boot/sandpoint.c
b/arch/powerpc/boot/sandpoint.c
index 0fe15b9..0feabbf 100644
--- a/arch/powerpc/boot/sandpoint.c
+++ b/arch/powerpc/boot/sandpoint.c
@@ -22,6 +22,8 @@ #define CPU_7XX 1
#define CPU_7457 2
#define CPU_NUM 3
+unsigned long bd_saved;
+
static u32 cpu_pll[CPU_NUM][32] = {
[CPU_824X] = { /* 824x */
5, 6, 9, 4, 4, 5, 2, 6, 6, 4, 9, 6, 5, 7, 6, 7,
@@ -84,6 +86,13 @@ #define mfspr(rn) ({unsigned long rval;
asm volatile("mfspr %0," __stringify(rn) \
: "=r" (rval)); rval;})
+#define SANDPOINT_UBOOT_LINK_ADDR 0xfff00000
+#define UBOOT_MAGIC 0x27051956
+#define UBOOT_BD_MEMSTART_OFFSET 0
+#define UBOOT_BD_MEMSIZE_OFFSET 1
+#define UBOOT_BD_CLOCKFREQ_OFFSET 11
+#define UBOOT_BD_BUSFREQ_OFFSET 12
+
static void
sandpoint_fixups(void)
{
@@ -91,7 +100,28 @@ sandpoint_fixups(void)
void *devp;
struct processor_info *pit;
extern u32 mpc10x_get_mem_size(void);
-
+ u32 *test_addr = (u32 *)SANDPOINT_UBOOT_LINK_ADDR;
+ u32 *bd = (u32 *)bd_saved;
+
+ switch (*test_addr) {
+ case UBOOT_MAGIC:
+ if ((devp = finddevice("/cpus/PowerPC,603e"))) {
+ v[0] = bd[UBOOT_BD_CLOCKFREQ_OFFSET];
+ setprop(devp, "clock-frequency", v, sizeof(v[0]));
+ v[0] = bd[UBOOT_BD_BUSFREQ_OFFSET] / 4;
+ setprop(devp, "timebase-frequency", v, sizeof(v[0]));
+ }
+ if ((devp = finddevice("/soc10x@fc000000"))) {
+ v[0] = bd[UBOOT_BD_BUSFREQ_OFFSET];
+ setprop(devp, "clock-frequency", v, sizeof(v[0]));
+ }
+ if ((devp = finddevice("/memory"))) {
+ v[0] = bd[UBOOT_BD_MEMSTART_OFFSET];
+ v[1] = bd[UBOOT_BD_MEMSIZE_OFFSET] + v[0];
+ setprop(devp, "reg", v, sizeof(v));
+ }
+ break;
+ default:
/* Update cpu's clock-frequency & timebase-frequency in fdt */
if ((pit = get_processor_info(mfspr(SPRN_PVR)))) {
if ((devp = finddevice("/cpus/PowerPC,603e"))) {
@@ -118,6 +148,8 @@ sandpoint_fixups(void)
v[1] = min(i, max_mem);
setprop(devp, "reg", v, sizeof(v));
}
+ break;
+ }
/* XXXX stuff from platforms/.../sandpoint.c should be here */
}
@@ -139,8 +171,10 @@ static struct ops sandpoint_ops;
static struct platform_ops sandpoint_platform_ops;
struct ops *
-platform_init(void *promptr)
+platform_init(void *promptr, unsigned long a1)
{
+ bd_saved = a1;
+
sandpoint_platform_ops.fixups = sandpoint_fixups;
sandpoint_platform_ops.exit = sandpoint_reset;
^ permalink raw reply related
* Re: U-boot and 2.6 kernel
From: Wolfgang Denk @ 2006-08-15 21:18 UTC (permalink / raw)
To: pranav choudhary; +Cc: linuxppc-embedded
In-Reply-To: <20060814113526.71320.qmail@web33213.mail.mud.yahoo.com>
In message <20060814113526.71320.qmail@web33213.mail.mud.yahoo.com> you wrote:
>
> I am using an old version of u-boot and 2.6.13 kernel on IXDP425 hardware. The booting process stalls. After a little debugging i found that the booting stalls sfter call to jump() [__FUNCTION__ = CON_Run_Firmware, __FILE__ == conleaf.c. It seems that t
> he correct image is not copied to KERNEL_RUN_ADDRESS.
> I found another thread that talked of old u-boot and 2.6 kernels but i could not make out anything useful from it. Can someone please give me some pointers on where to start debugging...
Start debugging at the kernel's entry point.
The kernel is independent from U-Boot.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Always borrow money from a pessimist; they don't expect to be paid
back.
^ permalink raw reply
* [PATCH] Allow MPC8641 HPCN to build with CONFIG_PCI disabled too.
From: Jon Loeliger @ 2006-08-15 21:19 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/kernel/prom_parse.c | 5 ++++-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 9 +++++++--
arch/powerpc/platforms/86xx/pci.c | 3 ++-
include/asm-powerpc/mpc86xx.h | 2 --
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 59f69d3..1dd6aef 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -601,10 +601,12 @@ static struct device_node *of_irq_find_p
return p;
}
+#ifdef CONFIG_PCI
static u8 of_irq_pci_swizzle(u8 slot, u8 pin)
{
return (((pin - 1) + slot) % 4) + 1;
}
+#endif /* CONFIG_PCI */
/* This doesn't need to be called if you don't have any special workaround
* flags to pass
@@ -895,6 +897,7 @@ int of_irq_map_one(struct device_node *d
}
EXPORT_SYMBOL_GPL(of_irq_map_one);
+#ifdef CONFIG_PCI
int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
{
struct device_node *dn, *ppnode;
@@ -971,4 +974,4 @@ #endif
return of_irq_map_raw(ppnode, &lspec, laddr, out_irq);
}
EXPORT_SYMBOL_GPL(of_irq_map_pci);
-
+#endif /* CONFIG_PCI */
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 4a33d95..496cc7c 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -52,6 +52,7 @@ unsigned long pci_dram_offset = 0;
#endif
+#ifdef CONFIG_PCI
static void mpc86xx_8259_cascade(unsigned int irq, struct irq_desc *desc,
struct pt_regs *regs)
{
@@ -60,14 +61,18 @@ static void mpc86xx_8259_cascade(unsigne
generic_handle_irq(cascade_irq, regs);
desc->chip->eoi(irq);
}
+#endif /* CONFIG_PCI */
void __init
mpc86xx_hpcn_init_irq(void)
{
struct mpic *mpic1;
- struct device_node *np, *cascade_node = NULL;
- int cascade_irq;
+ struct device_node *np;
phys_addr_t openpic_paddr;
+#ifdef CONFIG_PCI
+ struct device_node *cascade_node = NULL;
+ int cascade_irq;
+#endif
np = of_find_node_by_type(NULL, "open-pic");
if (np == NULL)
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index d7050c1..481e18e 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -188,7 +188,8 @@ int __init add_bridge(struct device_node
printk(KERN_INFO "Found MPC86xx PCIE host bridge at 0x%08lx. "
"Firmware bus number: %d->%d\n",
- rsrc.start, hose->first_busno, hose->last_busno);
+ (unsigned long) rsrc.start,
+ hose->first_busno, hose->last_busno);
DBG(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
hose, hose->cfg_addr, hose->cfg_data);
diff --git a/include/asm-powerpc/mpc86xx.h b/include/asm-powerpc/mpc86xx.h
index f260382..2d6ad85 100644
--- a/include/asm-powerpc/mpc86xx.h
+++ b/include/asm-powerpc/mpc86xx.h
@@ -23,8 +23,6 @@ #define _IO_BASE isa_io_base
#define _ISA_MEM_BASE isa_mem_base
#ifdef CONFIG_PCI
#define PCI_DRAM_OFFSET pci_dram_offset
-#else
-#define PCI_DRAM_OFFSET 0
#endif
#define CPU0_BOOT_RELEASE 0x01000000
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* Outstanding Patches Ping
From: Jon Loeliger @ 2006-08-15 22:01 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Paul,
Where do we stand on these two outstanding patches
that I have sent to the list?
- 08/03 Convert to mac-address for ethernet MAC data
- 08/09 Offer PCI as a CONFIG choice for PPC_86xx
I think all the outstanding issues and commentary
on them was resolved.
Thanks,
jdl
^ permalink raw reply
* IDE problems anyone?
From: Mark A. Greer @ 2006-08-15 22:15 UTC (permalink / raw)
To: linuxppc-dev
I'm having ide problems on the sandpoint (lost interrupt).
At least one other person is/was having a problem too
<http://lkml.org/lkml/2006/8/1/343>.
Is anyone else having a similar problem?
Maybe I have something horked wrt to the new irq stuff, I'm not sure.
Mark
^ permalink raw reply
* Trouble with 85xx CDS cascade irq (i8259)
From: Andy Fleming @ 2006-08-15 22:42 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list
Ok, I've been pounding my head into a wall over this thing for too
long now, and after combing through the source files line by line, I
am no closer to figuring this out. So let me describe my symptoms
and show you all my code, and maybe someone will be able to point out
the stupid mistake that I can't see.
I'm currently working on getting the 85xx platform working with the
new IRQ code. Specifically, I'm working on the 8555 CDS right now.
The 85xx CDS consists of a PCI carrier card (with the 8555 processor,
serial, and networking interfaces), placed in one of 4 PCI slots on a
custom motherboard (the Arcadia). The PCI interrupts are routed into
the carrier card through the standard PCI interrupt pins, which
requires some mucking around with interrupt assignments depending on
which slot the card is in. There is also a VIA chipset on the
Arcadia motherboard, which provides IDE (among other things), and the
i8259 PIC in there is routed in through PCI interrupt A.
When I try to boot, I get this:
Using MPC85xx CDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.18-rc2-gea0c3729-dirty (afleming@ld0175-tx32) (gcc
version 3.4.3) #26 Tue Aug 15 15:15:17 CDT 2006
setup_arch: bootmem
mpc85xx_cds_setup_arch()
CDS Version = 0x11 in slot 1
Found MPC85xx PCI host bridge at 0x00000000e0008000. Firmware bus
number: 0->1
Found MPC85xx PCI host bridge at 0x00000000e0009000. Firmware bus
number: 2->2
arch: exit
Built 1 zonelists. Total pages: 65536
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/nfsroot0/
ppc_82xx
ip=192.168.1.119:192.168.1.1:192.168.1.1:255.255.254.0:spacely:eth0:off
console=ttyS1,115200
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 4, shift: 2, mask: 3
mpic: Initializing for 60 sources
i8259 legacy interrupt controller initialized
PID hash table entries: 2048 (order: 11, 8192 bytes)
At this point, I have determined that I am caught in a never-ending
cycle of interrupts on the i8259 cascade (that is, the mpic interrupt
that the i8259 is cascaded through). i8259_irq() returns that it's
irq 7. I've tried booting the arch/ppc kernel, and it works. I've
added code to print out the i8259 registers, which didn't seem to
work (just got 0xff), but it did cause the kernel to boot
intermittently, or get further (frequently, it would fail when it
tried to get the interrupt for the e1000 I was using to test PCI
interrupts). Removing the debug code would not always return things
to the above state.
Here's the code that seems relevant. Any help is greatly appreciated:
void __init mpc85xx_cds_pic_init(void)
{
struct mpic *mpic;
struct resource r;
struct device_node *np = NULL;
struct device_node *cascade_node = NULL;
int cascade_irq;
np = of_find_node_by_type(np, "open-pic");
if (np == NULL) {
printk(KERN_ERR "Could not find open-pic node\n");
return;
}
of_address_to_resource(np, 0, &r);
mpic = mpic_alloc(np, r.start,
MPIC_PRIMARY | MPIC_WANTS_RESET |
MPIC_BIG_ENDIAN,
4, 0, " OpenPIC ");
BUG_ON(mpic == NULL);
mpic_assign_isu(mpic, 0, r.start + 0x10200);
mpic_assign_isu(mpic, 1, r.start + 0x10280);
mpic_assign_isu(mpic, 2, r.start + 0x10300);
mpic_assign_isu(mpic, 3, r.start + 0x10380);
mpic_assign_isu(mpic, 4, r.start + 0x10400);
mpic_assign_isu(mpic, 5, r.start + 0x10480);
mpic_assign_isu(mpic, 6, r.start + 0x10500);
mpic_assign_isu(mpic, 7, r.start + 0x10580);
/* Used only for 8548 so far, but no harm in
* allocating them for everyone */
mpic_assign_isu(mpic, 8, r.start + 0x10600);
mpic_assign_isu(mpic, 9, r.start + 0x10680);
mpic_assign_isu(mpic, 10, r.start + 0x10700);
mpic_assign_isu(mpic, 11, r.start + 0x10780);
/* External Interrupts */
mpic_assign_isu(mpic, 12, r.start + 0x10000);
mpic_assign_isu(mpic, 13, r.start + 0x10080);
mpic_assign_isu(mpic, 14, r.start + 0x10100);
mpic_init(mpic);
#ifdef CONFIG_PCI
/* Initialize the i8259 controller */
for_each_node_by_type(np, "interrupt-controller")
if (device_is_compatible(np, "chrp,iic")) {
cascade_node = np;
break;
}
if (cascade_node == NULL) {
printk(KERN_DEBUG "Could not find i8259 PIC\n");
return;
}
cascade_irq = irq_of_parse_and_map(cascade_node, 0);
if (cascade_irq == NO_IRQ) {
printk(KERN_ERR "Failed to map cascade interrupt\n");
return;
}
set_irq_chained_handler(cascade_irq, mpc85xx_8259_cascade);
i8259_init(cascade_node, 0);
#endif /* CONFIG_PCI */
}
static void mpc85xx_8259_cascade(unsigned int irq, struct
irq_desc *desc, struct pt_regs *regs)
{
unsigned int cascade_irq = i8259_irq(regs);
// cascade_irq is returned to be 7
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq, regs);
desc->chip->eoi(irq);
}
// --> This is where the PCI interrupts are scanned from the device tree
void __init
mpc85xx_cds_pcibios_fixup(void)
{
struct pci_dev *dev;
u_char c;
if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_1,
NULL))) {
/*
* U-Boot does not set the enable bits
* for the IDE device. Force them on here.
*/
pci_read_config_byte(dev, 0x40, &c);
c |= 0x03; /* IDE: Chip Enable Bits */
pci_write_config_byte(dev, 0x40, c);
/*
* Since only primary interface works, force the
* IDE function to standard primary IDE interrupt
* w/ 8259 offset
*/
dev->irq = 14;
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-
>irq);
pci_dev_put(dev);
}
/*
* Force legacy USB interrupt routing
*/
if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_2,
NULL))) {
dev->irq = 10;
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 10);
pci_dev_put(dev);
}
if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_2,
dev))) {
dev->irq = 11;
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 11);
pci_dev_put(dev);
}
/* Now map all the PCI irqs */
dev = NULL;
for_each_pci_dev(dev)
pci_read_irq_line(dev);
}
Here's the relevant device tree portions:
/ {
model = "MPC8555CDS";
compatible = "MPC85xxCDS";
soc8555@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00100000>; // CCSRBAR 1M
bus-frequency = <0>;
ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
address = [ 00 E0 0C 00 73 00 ];
interrupts = <0d 2 0e 2 12 2>;
interrupt-parent = <40000>;
phy-handle = <2452000>;
};
pci@8000 {
linux,phandle = <8000>;
interrupt-map-mask = <1f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x10 */
08000 0 0 1 40000 30 1
08000 0 0 2 40000 31 1
08000 0 0 3 40000 32 1
08000 0 0 4 40000 33 1
/* IDSEL 0x11 */
08800 0 0 1 40000 30 1
08800 0 0 2 40000 31 1
08800 0 0 3 40000 32 1
08800 0 0 4 40000 33 1
/* IDSEL 0x12 (Slot 1) */
09000 0 0 1 40000 30 1
09000 0 0 2 40000 31 1
09000 0 0 3 40000 32 1
09000 0 0 4 40000 33 1
/* IDSEL 0x13 (Slot 2) */
09800 0 0 1 40000 31 1
09800 0 0 2 40000 32 1
09800 0 0 3 40000 33 1
09800 0 0 4 40000 30 1
/* IDSEL 0x14 (Slot 3) */
0a000 0 0 1 40000 32 1
0a000 0 0 2 40000 33 1
0a000 0 0 3 40000 30 1
0a000 0 0 4 40000 31 1
/* IDSEL 0x15 (Slot 4) */
0a800 0 0 1 40000 33 1
0a800 0 0 2 40000 30 1
0a800 0 0 3 40000 31 1
0a800 0 0 4 40000 32 1
/* Bus 1 (Tundra Bridge) */
/* IDSEL 0x12 (ISA bridge) */
19000 0 0 1 40000 30 1
19000 0 0 2 40000 31 1
19000 0 0 3 40000 32 1
19000 0 0 4 40000 33 1>;
interrupt-parent = <40000>;
interrupts = <08 2>;
bus-range = <0 0>;
ranges = <02000000 0 80000000 80000000 0
20000000
01000000 0 00000000 e2000000 0
00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8000 1000>;
compatible = "85xx";
device_type = "pci";
i8259@19000 {
linux,phandle = <19000>;
clock-frequency = <0>;
interrupt-controller;
device_type = "interrupt-controller";
reg = <19000 0 0 0 1>;
#address-cells = <0>;
#interrupt-cells = <2>;
built-in;
compatible = "chrp,iic";
big-endian;
interrupts = <1>;
interrupt-parent = <8000>;
};
};
pci@9000 {
linux,phandle = <9000>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x15 */
a800 0 0 1 40000 3b 1
a800 0 0 2 40000 3b 1
a800 0 0 3 40000 3b 1
a800 0 0 4 40000 3b 1>;
interrupt-parent = <40000>;
interrupts = <09 2>;
bus-range = <0 0>;
ranges = <02000000 0 a0000000 a0000000 0
20000000
01000000 0 00000000 e3000000 0
00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <9000 1000>;
compatible = "85xx";
device_type = "pci";
};
pic@40000 {
linux,phandle = <40000>;
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
};
};
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Michael Ellerman @ 2006-08-16 0:29 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Jens Osterkamp, James K Lewis, linux-kernel,
linuxppc-dev, netdev
In-Reply-To: <20060815190524.GW6603@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]
On Tue, 2006-08-15 at 14:05 -0500, Olof Johansson wrote:
> On Fri, Aug 11, 2006 at 01:50:19PM -0500, James K Lewis wrote:
> > Hi Olof,
> >
> > There are several reasons why an Ethernet driver should have an up to
> > date version number:
> >
> > 1. Customers like to see they are really getting a new version.
> >
> > 2. It makes it easier for support personnel (me in this case) to see which
> > driver they have. Sure, sometimes I can talk them thru doing a "sum" on
> > the .ko and all that, but why not just use the version number? That's what
> > it is for. And no, you can't just assume they have the version that came
> > with the kernel they are running. It doesn't work that way.
> >
> > 3. It makes bug reporting easier.
> >
> > 4. I have already run into too many problems and wasted too much time
> > working with drivers when the number was NOT getting updated.
>
> Thanks for the info, Jim.
>
> Sounds like it's most useful if a customer (or distro) takes the driver
> out of the tree and run it with a different kernel, i.e. when kernel
> and driver versions no longer go together. Makes sense.
It only makes sense in addition to the kernel version number (which in
some cases can be meaningless), plus any distro and/or local patches,
plus the kernel config.
Without all that information you don't really know what you're talking
about, because any one of the many interfaces between the driver and the
core kernel may have changed.
So in practice I find it's much simpler to just get the exact source
that they're running, rather than trying to guess based on version
numbers. But that's just me :)
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Outstanding Patches Ping
From: Kumar Gala @ 2006-08-16 0:50 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155679316.10054.129.camel@cashmere.sps.mot.com>
On Aug 15, 2006, at 5:01 PM, Jon Loeliger wrote:
> Paul,
>
> Where do we stand on these two outstanding patches
> that I have sent to the list?
>
> - 08/03 Convert to mac-address for ethernet MAC data
Ack on the mac-address patch, and I think we should push it for
2.6.18, it deals with an interface issue that we really should get
into 2.6.18.
> - 08/09 Offer PCI as a CONFIG choice for PPC_86xx
>
> I think all the outstanding issues and commentary
> on them was resolved.
>
> Thanks,
> jdl
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH 4/6] ehea: header files
From: Michael Ellerman @ 2006-08-16 0:58 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, Jenkins, Clive, netdev, linux-kernel, linux-ppc,
Marcus Eder
In-Reply-To: <OF8C6BA147.30EE53F8-ONC12571CB.003C7748-C12571CB.003CBAA4@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
On Tue, 2006-08-15 at 13:07 +0200, Christoph Raisch wrote:
>
> "Jenkins, Clive" wrote on 15.08.2006 12:53:05:
>
> > > > You mean the eHEA has its own concept of page size? Separate from
> > the
> > > > page size used by the MMU?
> > > >
> > >
> > > yes, the eHEA currently supports only 4K pages for queues
> >
> > In that case, I suggest use the kernel's page size, but add a
> > compile-time
> > check, and quit with an error message if driver does not support it.
>
> eHEA does support other page sizes than 4k, but the HW interface expects to
> see 4k pages
> The adaption is done in the device driver, therefore we have a seperate 4k
> define.
Fair enough. You seem to only use it in drivers/net/ehea/ehea_qmr.c, if
so put the definition in there, that way someone is less likely to use
the EHEA_PAGESIZE definition where they really need PAGE_SIZE.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Have some truble when porting montavista linux3.1 in ML403 board
From: 杨强浩 @ 2006-08-16 1:47 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded list
In-Reply-To: <528646bc0607132228x88ab355w4fa978587a76bfbe@mail.gmail.com>
SGksIEdyYW50IExpa2VseSANCg0KCUkgYW0gcG9ydGluZyBtb250YXZpc3Rh
IGxpbnV4My4xIHRvIE1MNDAzIGJvYXJkLiBJIHVzZSB0aGUgcHJvamVjdCBz
eXN0ZW1fbGludXgueG1kIGluIHRoZSB4aWxpbnggTUw0MDMgcmVmZW5jZSAg
ZGlzaWduIC4gYW5kIGRvIGV2ZXJ5dGhpbmcgc3RlcCBieSBzdGVwIHdpdGgg
eW91ciBtYWlsDQoNCglodHRwOi8vb3psYWJzLm9yZy9waXBlcm1haWwvbGlu
dXhwcGMtZW1iZWRkZWQvMjAwNS1KdWx5LzAxOTA5MS5odG1sDQoNCglkbyBu
b3QgY2hhbmdlIGFueXRoaW5nLiBCdXQgd2hlbiBJIGRvdyB0aGUgbXkgeklt
YWdlLmVsZiB3aXRoIFhNRCBhbmQgcnVuIGl0ICx0aGUgY29uc29sZSBzaG93
IDoNCg0KIGxvYWRlZCBhdDogICAgIDAwNDAwMDAwIDAwNEJBMUU0DQogYm9h
cmQgZGF0YSBhdDogMDA0QjcxM0MgMDA0QjcxNTQNCiByZWxvY2F0ZWQgdG86
ICAwMDQwNTY0OCAwMDQwNTY2MA0KIHppbWFnZSBhdDogICAgIDAwNDA1QjUz
IDAwNEI2M0YzDQogYXZhaWwgcmFtOiAgICAgMDA0QkIwMDAgMDQwMDAwMDAN
Cg0KIExpbnV4L1BQQyBsb2FkOiBjb25zb2xlPXR0eTEgY29uc29sZT10dHlT
MCw5NjAwIHJvb3Q9L2Rldi94c3lzYWNlL2Rpc2MwL3BhcnQyIHJ3DQogaXA9
b2ZmDQogVW5jb21wcmVzc2luZyBMaW51eC4uLmRvbmUuDQogTm93IGJvb3Rp
bmcgdGhlIGtlcm5lbA0KDQoNCg0KdGhlbiwgaXQgc3RvcCxub3RoaW5nIHRv
IGRvLklmIEkgZG93IHRoZSAgekltYWdlLmVsZiBvZiB4aWxpbnggYW5kIHJ1
biBpdCAsdGhlIGNvbnNvbGUgc2hvdyA6DQoNCglsb2FkZWQgYXQ6ICAgICAw
MDQwMDAwMCAwMDRCQTFFNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgDQoJYm9hcmQgZGF0YSBhdDogMDA0QjcxM0MgMDA0QjcxNTQgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KCXJlbG9jYXRlZCB0bzogIDAw
NDA1NjQ4IDAwNDA1NjYwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICANCgl6aW1hZ2UgYXQ6ICAgICAwMDQwNUMxMyAwMDRCNjk1MCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgDQoJYXZhaWwgcmFtOiAgICAgMDA0
QkIwMDAgMDQwMDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KDQoJTGludXgvUFBDIGxvYWQ6IGNvbnNvbGU9dHR5MSBjb25zb2xlPXR0
eVMwLDk2MDAgcm9vdD0vZGV2L3hzeXNhY2UvZGlzYzAvcGFydDIgCXJ3ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAJaXA9b2ZmICAg
ICAgIA0KCVVuY29tcHJlc3NpbmcgTGludXguLi5kb25lLiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIA0KCU5vdyBib290aW5nIHRoZSBrZXJuZWwgICAg
ICAgICAgICAgICAgICAgICAgDQoJTGludXggdmVyc2lvbiAyLjQuMjBfbXZs
MzEtbWw0MDMgKHJ5c2VycEB6ZXBoeXIwKSAoZ2NjIHZlcnNpb24gMy4zLjEg
CShNb250YVZpc3RhDQogMy4zLjEtMy4wLjEwLjAzMDA1MzIgMjAwMy0xMi0y
NCkpICMyIFRodSBGZWIgMTYgMTc6MjcNCgkuLi4uLi4uLi4uLi4uLi4uLi4N
Cg0KDQoJSXQgaXMgYWJsZSB0byBib290Lg0KDQoJSSBmaW5kIHRoZSB0d28g
aW1hZ2UgaXMgZGlmZmVyIGluIHppbWFnZSBsb2NhdGlvbg0KICAgICAgbXk6
DQoJICB6aW1hZ2UgYXQ6ICAgICAwMDQwNUI1MyAwMDRCNjNGMw0KICAgICAg
eGlsaW54Og0KCSAgemltYWdlIGF0OiAgICAgMDA0MDVDMTMgMDA0QjY5NTAN
Cg0KDQoJd2h5PyB0aGV5IGFyZSBidWlsZCB3aXRoIHNhbWUgQlNQIGFuZCBj
b25maWcuDQoNCglXb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIGFkdmljZSAsIHRo
YW5rcyENCg0KDQpCUiENCkRhdmlkIFlhbmcNCg0KDQoNCqGhoaGhoaGhoaGh
oaGhoaF5YW5nLXFoQG5ldXNvZnQuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGh
oTIwMDYtMDgtMTYNCg0KCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCkNvbmZpZGVudGlhbGl0eSBOb3RpY2U6
IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgYW5k
IGFueSBhY2NvbXBhbnlpbmcgYXR0YWNobWVudChzKSBpcyBpbnRlbmRlZCBv
bmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYW5k
IG1heSBiZSBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQgb2YgTmV1
c29mdCBHcm91cCBMdGQuLCBpdHMgc3Vic2lkaWFyaWVzIGFuZC9vciBpdHMg
YWZmaWxpYXRlcy4gSWYgYW55IHJlYWRlciBvZiB0aGlzIGNvbW11bmljYXRp
b24gaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHVuYXV0aG9yaXpl
ZCB1c2UsIGZvcndhcmRpbmcsIHByaW50aW5nLCBzdG9yaW5nLCBkaXNjbG9z
dXJlIG9yIGNvcHlpbmcgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgYW5kIG1h
eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t
dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5
IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgYW5kIGRlbGV0ZSB0aGUg
b3JpZ2luYWwgbWVzc2FnZSBhbmQgYWxsIGNvcGllcyBmcm9tIHlvdXIgc3lz
dGVtLiBUaGFuayB5b3UuIAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoK
^ permalink raw reply
* hoe to define CPM_MAP_ADDR ?
From: jie han @ 2006-08-16 3:24 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]
I am trying to take a working embedded linux system from kernel 2.4 to
2.6. The hardware is a custom board using a MPC8270 processor.
The working system uses u-boot 1.1.1 with linux kernel 2.4.24.
I am using the same u-boot and I am trying to port linux kernel 2.6.15
to our platform. I just wonder hwo to define CPM_MAP_ADDR to my config file
at /arch/ppc/platforms/olt8270.h,thsi show file context as follow
#ifndef __OLT8270_PLATFORM
#define __OLT8270_PLATFORM
//#define CPM_MAP_ADDR ((uint)0xf0000000)
#define IMAP_ADDR ((uint)0xf0000000)
#define BOOTROM_RESTART_ADDR ((uint)0xfff00100)
/* For our show_cpuinfo hooks. */
#define CPUINFO_VENDOR "Ocean Broadband Ltd"
#define CPUINFO_MACHINE "OLT8270 PowerPC"
/* A Board Information structure that is given to a program when
* prom starts it up.
*/
typedef struct bd_info {
unsigned long bi_memstart; /* Memory start address */
unsigned long bi_memsize; /* Memory (end) size in bytes */
unsigned long bi_flashstart; /* start of FLASH memory */
unsigned long bi_flashsize; /* size of FLASH memory */
unsigned long bi_flashoffset; /* reserved area for startup monitor */
unsigned long bi_sramstart; /* start of SRAM memory */
unsigned long bi_sramsize; /* size of SRAM memory */
unsigned long bi_immr; /* IMMR when called from boot rom */
unsigned long bi_bootflags; /* boot flag (for Lynx OS) */
unsigned long bi_ip_addr; /* IP Address */
unsigned char bi_enetaddr[6]; /* Ethernet address */
unsigned short bi_ethspeed; /* Ethernet speed in Mbps */
unsigned long bi_intfreq; /* Internal Freq, in Hz */
unsigned long bi_busfreq; /* Bus Freq, in MHz */
unsigned long bi_cpmfreq; /* CPM Freq, in MHz */
unsigned long bi_brgfreq; /* BRG Freq, in MHz */
unsigned long bi_sccfreq; /* SCC Freq, in MHz */
unsigned long bi_vco; /* VCO Out from PLL */
unsigned long bi_baudrate; /* Default console baud rate */
} bd_t;
extern bd_t m8xx_board_info;
#endif /* __OLT8270_PLATFORM */
Sincerely,
Jie
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
[-- Attachment #2: Type: text/html, Size: 2471 bytes --]
^ permalink raw reply
* RE: hoe to define CPM_MAP_ADDR ?
From: Liu Dave-r63238 @ 2006-08-16 3:49 UTC (permalink / raw)
To: jie han, linuxppc-embedded
In-Reply-To: <20060816032420.3004.qmail@web15110.mail.cnb.yahoo.com>
You can refer to the other board config file like MPC8260ADS.
-Dave
> I am trying to take a working embedded linux system from=20
> kernel 2.4 to=20
> 2.6. The hardware is a custom board using a MPC8270 processor.
> The working system uses u-boot 1.1.1 with linux kernel 2.4.24.
> I am using the same u-boot and I am trying to port linux=20
> kernel 2.6.15=20
> to our platform. I just wonder hwo to define CPM_MAP_ADDR to=20
> my config file
> at /arch/ppc/platforms/olt8270.h,thsi show file context as follow
>=20
> #ifndef __OLT8270_PLATFORM
> #define __OLT8270_PLATFORM
>=20
> //#define CPM_MAP_ADDR ((uint)0xf0000000)
> #define IMAP_ADDR ((uint)0xf0000000)
>=20
> #define BOOTROM_RESTART_ADDR ((uint)0xfff00100)
>=20
> /* For our show_cpuinfo hooks. */
> #define CPUINFO_VENDOR "Ocean Broadband Ltd"
> #define CPUINFO_MACHINE "OLT8270 PowerPC"
>=20
> /* A Board Information structure that is given to a program when
> * prom starts it up.
> */
> typedef struct bd_info {
> unsigned long bi_memstart; /* Memory start address */
> unsigned long
> bi_memsize; /* Memory (end) size in bytes */
> unsigned long bi_flashstart; /* start of FLASH memory */
> unsigned long bi_flashsize; /* size of FLASH memory */
> unsigned long bi_flashoffset; /* reserved area for startup monitor */
> unsigned long bi_sramstart; /* start of SRAM memory */
> unsigned long bi_sramsize; /* size of SRAM memory */
>=20
> unsigned long bi_immr; /* IMMR when called from boot rom */
>=20
> unsigned long bi_bootflags; /* boot flag (for Lynx OS) */
>=20
> unsigned long bi_ip_addr; /* IP Address */
> unsigned char bi_enetaddr[6]; /* Ethernet address */
> unsigned short bi_ethspeed; /* Ethernet speed in Mbps */
>=20
> unsigned long bi_intfreq; /* Internal Freq, in Hz */
> unsigned long bi_busfreq; /* Bus Freq, in MHz */
> unsigned long bi_cpmfreq; /* CPM Freq, in MHz */
> unsigned long bi_brgfreq; /* BRG Freq, in MHz */
> unsigned long bi_sccfreq; /* SCC Freq, in MHz
> */
> unsigned long bi_vco; /* VCO Out from PLL */
> unsigned long bi_baudrate; /* Default console baud rate */
> } bd_t;
>=20
> extern bd_t m8xx_board_info;
>=20
> #endif /* __OLT8270_PLATFORM */
>=20
>=20
>=20
> Sincerely,
>=20
>=20
> Jie
>=20
> ________________________________
>=20
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone=20
> calls. Great rates starting at 1=A2/min.=20
> <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.r
> d.yahoo.com/evt=3D39666/*http://messenger.yahoo.com>=20
>=20
^ permalink raw reply
* [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-16 4:00 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, anton
The RTAS console doesn't have to be Cell specific. If we have both
the put and get char RTAS functions, init the rtas console.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Paulus: This is relatively low risk, so if the Cell guys ack it, it
could be a candidate for 2.6.18.
arch/powerpc/kernel/rtas.c | 5 +++++
arch/powerpc/platforms/cell/setup.c | 4 ----
2 files changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
@@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
if (basep)
rtas_getchar_token = *basep;
+
+ if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
+ rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
+ udbg_init_rtas_console();
+
#endif
/* break now */
Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
@@ -150,10 +150,6 @@ static int __init cell_probe(void)
!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
return 0;
-#ifdef CONFIG_UDBG_RTAS_CONSOLE
- udbg_init_rtas_console();
-#endif
-
hpte_init_native();
return 1;
^ permalink raw reply
* [PATCH] Add CONFIG_POWERPC
From: Michael Ellerman @ 2006-08-16 4:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We don't seem to have a top-level config symbol like other archs do. We have
PPC64 and PPC, but I think it'd be cleaner to have just one for cases where
we really mean PPC64 and/or PPC.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
Index: git/arch/powerpc/Kconfig
===================================================================
--- git.orig/arch/powerpc/Kconfig
+++ git/arch/powerpc/Kconfig
@@ -11,6 +11,10 @@ config PPC64
This option selects whether a 32-bit or a 64-bit kernel
will be built.
+config POWERPC
+ bool
+ default y
+
config PPC32
bool
default y if !PPC64
^ permalink raw reply
* Re: [PATCH] Add CONFIG_POWERPC
From: Paul Mackerras @ 2006-08-16 4:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20060816041617.690EB67A3F@ozlabs.org>
Michael Ellerman writes:
> We don't seem to have a top-level config symbol like other archs do. We have
> PPC64 and PPC, but I think it'd be cleaner to have just one for cases where
> we really mean PPC64 and/or PPC.
CONFIG_PPC already means either 32-bit or 64-bit PowerPC (always has
done, even before the merge).
Paul.
^ permalink raw reply
* Re: [PATCH] Add CONFIG_POWERPC
From: Michael Ellerman @ 2006-08-16 5:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17634.40549.377775.121184@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
On Wed, 2006-08-16 at 14:26 +1000, Paul Mackerras wrote:
> Michael Ellerman writes:
>
> > We don't seem to have a top-level config symbol like other archs do. We have
> > PPC64 and PPC, but I think it'd be cleaner to have just one for cases where
> > we really mean PPC64 and/or PPC.
>
> CONFIG_PPC already means either 32-bit or 64-bit PowerPC (always has
> done, even before the merge).
Hmm, but won't that also match arch/ppc ?
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [POWERPC] iseries: remove some gcc 4.1 warnings
From: Stephen Rothwell @ 2006-08-16 5:20 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
gcc 4.1 produces some warnings that it is ignoring the packed attribute
on some structure elements, so just remove them.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/main_store.h | 46 ++++++++++++++-------------
1 files changed, 23 insertions(+), 23 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/iseries/main_store.h b/arch/powerpc/platforms/iseries/main_store.h
index 74f6889..4b31658 100644
--- a/arch/powerpc/platforms/iseries/main_store.h
+++ b/arch/powerpc/platforms/iseries/main_store.h
@@ -63,7 +63,7 @@ struct IoHriMainStoreSegment4 {
/* Main Store VPD for Power4 */
struct IoHriMainStoreChipInfo1 {
u32 chipMfgID __attribute((packed));
- char chipECLevel[4] __attribute((packed));
+ char chipECLevel[4];
};
struct IoHriMainStoreVpdIdData {
@@ -74,9 +74,9 @@ struct IoHriMainStoreVpdIdData {
};
struct IoHriMainStoreVpdFruData {
- char fruLabel[8] __attribute((packed));
- u8 numberOfSlots __attribute((packed));
- u8 pluggingType __attribute((packed));
+ char fruLabel[8];
+ u8 numberOfSlots;
+ u8 pluggingType;
u16 slotMapIndex __attribute((packed));
};
@@ -90,8 +90,8 @@ #define MaxAreaAdrRangeBlocks 4
struct IoHriMainStoreArea4 {
u32 msVpdFormat __attribute((packed));
- u8 containedVpdType __attribute((packed));
- u8 reserved1 __attribute((packed));
+ u8 containedVpdType;
+ u8 reserved1;
u16 reserved2 __attribute((packed));
u64 msExists __attribute((packed));
@@ -101,16 +101,16 @@ struct IoHriMainStoreArea4 {
u32 procNodeId __attribute((packed));
u32 numAdrRangeBlocks __attribute((packed));
- struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks] __attribute((packed));
+ struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks];
- struct IoHriMainStoreChipInfo1 chipInfo0 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo1 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo2 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo3 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo4 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo5 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo6 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo7 __attribute((packed));
+ struct IoHriMainStoreChipInfo1 chipInfo0;
+ struct IoHriMainStoreChipInfo1 chipInfo1;
+ struct IoHriMainStoreChipInfo1 chipInfo2;
+ struct IoHriMainStoreChipInfo1 chipInfo3;
+ struct IoHriMainStoreChipInfo1 chipInfo4;
+ struct IoHriMainStoreChipInfo1 chipInfo5;
+ struct IoHriMainStoreChipInfo1 chipInfo6;
+ struct IoHriMainStoreChipInfo1 chipInfo7;
void *msRamAreaArray __attribute((packed));
u32 msRamAreaArrayNumEntries __attribute((packed));
@@ -122,22 +122,22 @@ struct IoHriMainStoreArea4 {
u32 numaDimmArrayNumEntries __attribute((packed));
u32 numaDimmArrayEntrySize __attribute((packed));
- struct IoHriMainStoreVpdIdData idData __attribute((packed));
+ struct IoHriMainStoreVpdIdData idData;
u64 powerData __attribute((packed));
u64 cardAssemblyPartNum __attribute((packed));
u64 chipSerialNum __attribute((packed));
u64 reserved3 __attribute((packed));
- char reserved4[16] __attribute((packed));
+ char reserved4[16];
- struct IoHriMainStoreVpdFruData fruData __attribute((packed));
+ struct IoHriMainStoreVpdFruData fruData;
- u8 vpdPortNum __attribute((packed));
- u8 reserved5 __attribute((packed));
- u8 frameId __attribute((packed));
- u8 rackUnit __attribute((packed));
- char asciiKeywordVpd[256] __attribute((packed));
+ u8 vpdPortNum;
+ u8 reserved5;
+ u8 frameId;
+ u8 rackUnit;
+ char asciiKeywordVpd[256];
u32 reserved6 __attribute((packed));
};
--
1.4.1.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Ellerman @ 2006-08-16 5:21 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060816040040.1E20967B55@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
On Tue, 2006-08-15 at 23:00 -0500, Michael Neuling wrote:
> The RTAS console doesn't have to be Cell specific. If we have both
> the put and get char RTAS functions, init the rtas console.
>
> Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
> +++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> @@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
> basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
> if (basep)
> rtas_getchar_token = *basep;
> +
> + if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
> + rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
> + udbg_init_rtas_console();
> +
> #endif
>
> /* break now */
> Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
> +++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> @@ -150,10 +150,6 @@ static int __init cell_probe(void)
> !of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
> return 0;
>
> -#ifdef CONFIG_UDBG_RTAS_CONSOLE
> - udbg_init_rtas_console();
> -#endif
> -
I'd like to see it still guarded by UDBG_RTAS_CONSOLE, otherwise there's
no way to select a different type of early console on a machine which
has those tokens in the device tree.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [POWERPC] iseries: remove const warning
From: Stephen Rothwell @ 2006-08-16 5:24 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Just one bit of fallout from the constification of the get_property
return value.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/viopath.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/iseries/viopath.c b/arch/powerpc/platforms/iseries/viopath.c
index efeb6ae..9baa4ee 100644
--- a/arch/powerpc/platforms/iseries/viopath.c
+++ b/arch/powerpc/platforms/iseries/viopath.c
@@ -117,6 +117,7 @@ static int proc_viopath_show(struct seq_
HvLpEvent_Rc hvrc;
DECLARE_MUTEX_LOCKED(Semaphore);
struct device_node *node;
+ const char *sysid;
buf = kmalloc(HW_PAGE_SIZE, GFP_KERNEL);
if (!buf)
@@ -152,15 +153,15 @@ static int proc_viopath_show(struct seq_
seq_printf(m, "AVAILABLE_VETH=%x\n", vlanMap);
node = of_find_node_by_path("/");
- buf = NULL;
+ sysid = NULL;
if (node != NULL)
- buf = get_property(node, "system-id", NULL);
+ sysid = get_property(node, "system-id", NULL);
- if (buf == NULL)
+ if (sysid == NULL)
seq_printf(m, "SRLNBR=<UNKNOWN>\n");
else
/* Skip "IBM," on front of serial number, see dt.c */
- seq_printf(m, "SRLNBR=%s\n", buf + 4);
+ seq_printf(m, "SRLNBR=%s\n", sysid + 4);
of_node_put(node);
--
1.4.1.1
^ 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