summaryrefslogtreecommitdiffstats
path: root/arch/ppc64/kernel/prom_init.c
diff options
context:
space:
mode:
authorBenjamin Herrenschmidt <benh@kernel.crashing.org>2005-06-01 14:54:25 +1000
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-06-01 07:54:13 -0700
commit44e4665cc9d856d15f04a012c78e4ab48f71290b (patch)
tree70d440628c5a426f6de14b65a230e076584fe7fe /arch/ppc64/kernel/prom_init.c
parent21e3024cbddb712f6a078bf4132d7682d3c4e35e (diff)
downloadlinux-44e4665cc9d856d15f04a012c78e4ab48f71290b.tar.bz2
[PATCH] ppc64: Fix a device-tree bug on Apple's
Apple's Open Firmware has a funny bug when creating the /cpus nodes where it leaves a dangling '\0' character in the CPU name which ends up appearing in the full path of the node. This is bogus and confuses /proc/device-tree badly. This patch strips those bogus zero's from the node full path when reading the device-tree from Open Firmware. The "name" property is not modified and still contains the spurrious 0 (it basically contains 0 tailing 0 instead of one) but that shouldn't be a problem. An equivalent patch for ppc32 will follow shortly Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'arch/ppc64/kernel/prom_init.c')
-rw-r--r--arch/ppc64/kernel/prom_init.c10
1 files changed, 9 insertions, 1 deletions
diff --git a/arch/ppc64/kernel/prom_init.c b/arch/ppc64/kernel/prom_init.c
index bc53967a8643..3de950de3671 100644
--- a/arch/ppc64/kernel/prom_init.c
+++ b/arch/ppc64/kernel/prom_init.c
@@ -1566,7 +1566,7 @@ static void __init scan_dt_build_struct(phandle node, unsigned long *mem_start,
{
int l, align;
phandle child;
- char *namep, *prev_name, *sstart;
+ char *namep, *prev_name, *sstart, *p, *ep;
unsigned long soff;
unsigned char *valp;
unsigned long offset = reloc_offset();
@@ -1588,6 +1588,14 @@ static void __init scan_dt_build_struct(phandle node, unsigned long *mem_start,
call_prom("package-to-path", 3, 1, node, namep, l);
}
namep[l] = '\0';
+ /* Fixup an Apple bug where they have bogus \0 chars in the
+ * middle of the path in some properties
+ */
+ for (p = namep, ep = namep + l; p < ep; p++)
+ if (*p == '\0') {
+ memmove(p, p+1, ep - p);
+ ep--; l--;
+ }
*mem_start = _ALIGN(((unsigned long) namep) + strlen(namep) + 1, 4);
}