* Re: libfdt: libfdt_env.h must be included first
From: David Gibson @ 2007-09-28 5:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070928151322.a9dee5d9.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Fri, Sep 28, 2007 at 03:13:22PM +1000, Stephen Rothwell wrote:
> On Fri, 28 Sep 2007 14:52:06 +1000 David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > libfdt.h currently includes fdt.h, then libfdt_env.h. This is
> > incorrect, because depending on the environment into which libfdt is
> > embedded, libfdt_env.h may be needed to define datatypes used in
> > fdt.h. This patch corrects the problem.
>
> So why doesn't fdt.h include libfdt_env.h, then?
Because libfdt_env.h is specifically for libfdt, whereas fdt.h
contains passive structures only, related to the flat tree structure
but without reference to any particular code for handling it.
Basically, fdt.h includes no other headers as a compromise to make it
more easily usable in various contexts. In fact the only thing it
needs is the C99 fixed-width integer types, but I want it to be also
usable in contexts which don't have a <stdint.h> (e.g. the kernel
bootwrapper).
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* libfdt: Make unit address optional for finding nodes
From: David Gibson @ 2007-09-28 5:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present, the fdt_subnode_offset() and fdt_path_offset() functions
in libfdt require the exact name of the nodes in question be passed,
including unit address.
This is contrary to traditional OF-like finddevice() behaviour, which
allows the unit address to be omitted (which is useful when the device
name is unambiguous without the address).
This patch introduces similar behaviour to
fdt_subnode_offset_namelen(), and hence to fdt_subnode_offset() and
fdt_path_offset() which are implemented in terms of the former. The
unit address can be omitted from the given node name. If this is
ambiguous, the first such node in the flattened tree will be selected
(this behaviour is consistent with IEEE1275 which specifies only that
an arbitrary node matching the given information be selected).
This very small change is then followed by many more diffs which
change the test examples and testcases to exercise this behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Jon, I initially considered making this behaviour optional,
i.e. adding a flag to subnode_offset() determining if it needed exact
matches or name-without-address matches. I couldn't see that it was
actually any use, though.
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-09-27 18:36:03.000000000 +1000
@@ -62,8 +62,8 @@
return err; \
}
-static int offset_streq(const void *fdt, int offset,
- const char *s, int len)
+static int nodename_eq(const void *fdt, int offset,
+ const char *s, int len)
{
const char *p = fdt_offset_ptr(fdt, offset, len+1);
@@ -74,10 +74,12 @@ static int offset_streq(const void *fdt,
if (memcmp(p, s, len) != 0)
return 0;
- if (p[len] != '\0')
+ if (p[len] == '\0')
+ return 1;
+ else if (!memchr(s, '@', len) && (p[len] == '@'))
+ return 1;
+ else
return 0;
-
- return 1;
}
char *fdt_string(const void *fdt, int stroffset)
@@ -110,7 +112,7 @@ int fdt_subnode_offset_namelen(const voi
level++;
if (level != 1)
continue;
- if (offset_streq(fdt, offset+FDT_TAGSIZE, name, namelen))
+ if (nodename_eq(fdt, offset+FDT_TAGSIZE, name, namelen))
/* Found it! */
return offset;
break;
Index: dtc/tests/trees.S
===================================================================
--- dtc.orig/tests/trees.S 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/trees.S 2007-09-27 17:58:54.000000000 +1000
@@ -78,7 +78,7 @@ test_tree1_struct:
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
PROP_STR(test_tree1, prop_str, TEST_STRING_1)
- BEGIN_NODE("subnode1")
+ BEGIN_NODE("subnode@1")
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
BEGIN_NODE("subsubnode")
@@ -86,10 +86,10 @@ test_tree1_struct:
END_NODE
END_NODE
- BEGIN_NODE("subnode2")
+ BEGIN_NODE("subnode@2")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
- BEGIN_NODE("subsubnode")
+ BEGIN_NODE("subsubnode@0")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
END_NODE
END_NODE
Index: dtc/tests/subnode_offset.c
===================================================================
--- dtc.orig/tests/subnode_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/subnode_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -48,7 +48,7 @@ int check_subnode(struct fdt_header *fdt
if (tag != FDT_BEGIN_NODE)
FAIL("Incorrect tag 0x%08x on property \"%s\"", tag, name);
- if (!streq(nh->name, name))
+ if (!nodename_eq(nh->name, name))
FAIL("Subnode name mismatch \"%s\" instead of \"%s\"",
nh->name, name);
@@ -59,13 +59,13 @@ int main(int argc, char *argv[])
{
void *fdt;
int subnode1_offset, subnode2_offset;
- int subsubnode1_offset, subsubnode2_offset;
+ int subsubnode1_offset, subsubnode2_offset, subsubnode2_offset2;
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = check_subnode(fdt, 0, "subnode1");
- subnode2_offset = check_subnode(fdt, 0, "subnode2");
+ subnode1_offset = check_subnode(fdt, 0, "subnode@1");
+ subnode2_offset = check_subnode(fdt, 0, "subnode@2");
if (subnode1_offset == subnode2_offset)
FAIL("Different subnodes have same offset");
@@ -74,10 +74,15 @@ int main(int argc, char *argv[])
check_property_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
- subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode");
+ subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
+ subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
check_property_typed(fdt, subsubnode1_offset, "prop-int", TEST_VALUE_1);
check_property_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_property_typed(fdt, subsubnode2_offset2, "prop-int", TEST_VALUE_2);
+
+ if (subsubnode2_offset != subsubnode2_offset2)
+ FAIL("Different offsets with and without unit address");
PASS();
}
Index: dtc/tests/path_offset.c
===================================================================
--- dtc.orig/tests/path_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/path_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -48,7 +48,7 @@ int check_subnode(void *fdt, int parent,
if (tag != FDT_BEGIN_NODE)
FAIL("Incorrect tag 0x%08x on property \"%s\"", tag, name);
- if (!streq(nh->name, name))
+ if (!nodename_eq(nh->name, name))
FAIL("Subnode name mismatch \"%s\" instead of \"%s\"",
nh->name, name);
@@ -61,8 +61,8 @@ int main(int argc, char *argv[])
int root_offset;
int subnode1_offset, subnode2_offset;
int subnode1_offset_p, subnode2_offset_p;
- int subsubnode1_offset, subsubnode2_offset;
- int subsubnode1_offset_p, subsubnode2_offset_p;
+ int subsubnode1_offset, subsubnode2_offset, subsubnode2_offset2;
+ int subsubnode1_offset_p, subsubnode2_offset_p, subsubnode2_offset2_p;
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
@@ -74,11 +74,11 @@ int main(int argc, char *argv[])
else if (root_offset != 0)
FAIL("fdt_path_offset(\"/\") returns incorrect offset %d",
root_offset);
- subnode1_offset = check_subnode(fdt, 0, "subnode1");
- subnode2_offset = check_subnode(fdt, 0, "subnode2");
+ subnode1_offset = check_subnode(fdt, 0, "subnode@1");
+ subnode2_offset = check_subnode(fdt, 0, "subnode@2");
- subnode1_offset_p = fdt_path_offset(fdt, "/subnode1");
- subnode2_offset_p = fdt_path_offset(fdt, "/subnode2");
+ subnode1_offset_p = fdt_path_offset(fdt, "/subnode@1");
+ subnode2_offset_p = fdt_path_offset(fdt, "/subnode@2");
if (subnode1_offset != subnode1_offset_p)
FAIL("Mismatch between subnode_offset (%d) and path_offset (%d)",
@@ -89,10 +89,12 @@ int main(int argc, char *argv[])
subnode2_offset, subnode2_offset_p);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
- subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode");
+ subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
+ subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
- subsubnode1_offset_p = fdt_path_offset(fdt, "/subnode1/subsubnode");
- subsubnode2_offset_p = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode1_offset_p = fdt_path_offset(fdt, "/subnode@1/subsubnode");
+ subsubnode2_offset_p = fdt_path_offset(fdt, "/subnode@2/subsubnode@0");
+ subsubnode2_offset2_p = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode1_offset != subsubnode1_offset_p)
FAIL("Mismatch between subnode_offset (%d) and path_offset (%d)",
Index: dtc/tests/tests.h
===================================================================
--- dtc.orig/tests/tests.h 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/tests.h 2007-09-27 17:58:54.000000000 +1000
@@ -126,6 +126,7 @@ const void *check_getprop(void *fdt, int
})
#define check_getprop_string(fdt, nodeoffset, name, s) \
check_getprop((fdt), (nodeoffset), (name), strlen(s)+1, (s))
+int nodename_eq(const char *s1, const char *s2);
//void *load_blob(const char *filename);
void *load_blob_arg(int argc, char *argv[]);
void save_blob(const char *filename, void *blob);
Index: dtc/tests/testutils.c
===================================================================
--- dtc.orig/tests/testutils.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/testutils.c 2007-09-27 17:58:54.000000000 +1000
@@ -125,6 +125,21 @@ const void *check_getprop(void *fdt, int
return propval;
}
+int nodename_eq(const char *s1, const char *s2)
+{
+ int len = strlen(s2);
+
+ len = strlen(s2);
+ if (strncmp(s1, s2, len) != 0)
+ return 0;
+ if (s1[len] == '\0')
+ return 1;
+ else if (!memchr(s2, '@', len) && (s1[len] == '@'))
+ return 1;
+ else
+ return 0;
+}
+
#define CHUNKSIZE 128
void *load_blob(const char *filename)
Index: dtc/tests/get_name.c
===================================================================
--- dtc.orig/tests/get_name.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/get_name.c 2007-09-27 17:58:54.000000000 +1000
@@ -74,10 +74,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_name(fdt, "/");
- check_name(fdt, "/subnode1");
- check_name(fdt, "/subnode2");
- check_name(fdt, "/subnode1/subsubnode");
- check_name(fdt, "/subnode2/subsubnode");
+ check_name(fdt, "/subnode@1");
+ check_name(fdt, "/subnode@2");
+ check_name(fdt, "/subnode@1/subsubnode");
+ check_name(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/get_path.c
===================================================================
--- dtc.orig/tests/get_path.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/get_path.c 2007-09-27 17:58:54.000000000 +1000
@@ -82,10 +82,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_path(fdt, "/");
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/supernode_atdepth_offset.c
===================================================================
--- dtc.orig/tests/supernode_atdepth_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/supernode_atdepth_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -135,10 +135,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_path(fdt, "/");
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/node_offset_by_prop_value.c
===================================================================
--- dtc.orig/tests/node_offset_by_prop_value.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/node_offset_by_prop_value.c 2007-09-27 17:58:54.000000000 +1000
@@ -83,10 +83,10 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
- subsubnode1_offset = fdt_path_offset(fdt, "/subnode1/subsubnode");
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
+ subsubnode1_offset = fdt_path_offset(fdt, "/subnode@1/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode@0");
if ((subnode1_offset < 0) || (subnode2_offset < 0)
|| (subsubnode1_offset < 0) || (subsubnode2_offset < 0))
Index: dtc/tests/nop_node.c
===================================================================
--- dtc.orig/tests/nop_node.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/nop_node.c 2007-09-27 17:58:54.000000000 +1000
@@ -39,21 +39,21 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset < 0)
FAIL("Couldn't find \"/subnode1\": %s",
fdt_strerror(subnode1_offset));
check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -61,21 +61,21 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_nop_node(subnode1): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -83,19 +83,19 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_nop_node(subnode2): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode2_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subsubnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subsubnode2_offset),
Index: dtc/tests/notfound.c
===================================================================
--- dtc.orig/tests/notfound.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/notfound.c 2007-09-27 17:58:54.000000000 +1000
@@ -53,7 +53,7 @@ int main(int argc, char *argv[])
val = fdt_getprop(fdt, 0, "nonexistant-property", &lenerr);
check_error("fdt_getprop(\"nonexistant-property\"", lenerr);
- subnode1_offset = fdt_subnode_offset(fdt, 0, "subnode1");
+ subnode1_offset = fdt_subnode_offset(fdt, 0, "subnode@1");
if (subnode1_offset < 0)
FAIL("Couldn't find subnode1: %s", fdt_strerror(subnode1_offset));
Index: dtc/tests/parent_offset.c
===================================================================
--- dtc.orig/tests/parent_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/parent_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -77,10 +77,10 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
err = fdt_parent_offset(fdt, 0);
if (err != -FDT_ERR_NOTFOUND)
FAIL("fdt_parent_offset(/) returns %d instead of "
Index: dtc/tests/del_node.c
===================================================================
--- dtc.orig/tests/del_node.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/del_node.c 2007-09-27 17:58:54.000000000 +1000
@@ -42,21 +42,21 @@ int main(int argc, char *argv[])
oldsize = fdt_totalsize(fdt);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset < 0)
- FAIL("Couldn't find \"/subnode1\": %s",
+ FAIL("Couldn't find \"/subnode@1\": %s",
fdt_strerror(subnode1_offset));
check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2\": %s",
+ FAIL("Couldn't find \"/subnode@2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -64,21 +64,21 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_del_node(subnode1): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -86,19 +86,19 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_del_node(subnode2): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode2_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subsubnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subsubnode2_offset),
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/sw_tree1.c 2007-09-27 17:58:54.000000000 +1000
@@ -54,16 +54,16 @@ int main(int argc, char *argv[])
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_property_string(fdt, "prop-str", TEST_STRING_1));
- CHECK(fdt_begin_node(fdt, "subnode1"));
+ CHECK(fdt_begin_node(fdt, "subnode@1"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_begin_node(fdt, "subsubnode"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
- CHECK(fdt_begin_node(fdt, "subnode2"));
+ CHECK(fdt_begin_node(fdt, "subnode@2"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
- CHECK(fdt_begin_node(fdt, "subsubnode"));
+ CHECK(fdt_begin_node(fdt, "subsubnode@0"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
Index: dtc/tests/rw_tree1.c
===================================================================
--- dtc.orig/tests/rw_tree1.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/rw_tree1.c 2007-09-27 17:58:54.000000000 +1000
@@ -72,14 +72,14 @@ int main(int argc, char *argv[])
CHECK(fdt_setprop_typed(fdt, 0, "prop-int", TEST_VALUE_1));
CHECK(fdt_setprop_string(fdt, 0, "prop-str", TEST_STRING_1));
- OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode1"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@1"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
- OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode2"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@2"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
- OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode@0"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
Index: dtc/tests/test_tree1.dts
===================================================================
--- dtc.orig/tests/test_tree1.dts 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/test_tree1.dts 2007-09-27 17:58:54.000000000 +1000
@@ -2,7 +2,7 @@
prop-int = <deadbeef>;
prop-str = "hello world";
- subnode1 {
+ subnode@1 {
prop-int = <deadbeef>;
subsubnode {
@@ -10,10 +10,10 @@
};
};
- subnode2 {
+ subnode@2 {
prop-int = <abcd1234>;
- subsubnode {
+ subsubnode@0 {
prop-int = <abcd1234>;
};
};
--
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: [PATCH] Make sure to of_node_get() the result of pci_device_to_OF_node()
From: Michael Ellerman @ 2007-09-28 6:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Arnd Bergmann
In-Reply-To: <8183225ab4b14684bb0939e0c5258caaf5b8102f.1190008974.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]
On Mon, 2007-09-17 at 16:03 +1000, Michael Ellerman wrote:
> pci_device_to_OF_node() returns the device node attached to a PCI device,
> but doesn't actually grab a reference - we need to do it ourselves.
Hi Paul,
Can you stick this in your 24 tree for the moment, the warnings it fixes
are giving people the willys. I'll look at the proper fix of having
pci_device_to_OF_node() take the reference and fixing all the callers.
cheers
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
> index 57a6149..2b2dfcc 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -119,7 +119,7 @@ static struct axon_msic *find_msi_translator(struct pci_dev *dev)
> const phandle *ph;
> struct axon_msic *msic = NULL;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return NULL;
> @@ -176,7 +176,7 @@ static int setup_msi_msg_address(struct pci_dev *dev, struct msi_msg *msg)
> int len;
> const u32 *prop;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return -ENODEV;
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
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: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] Celleb: New HTAB Guest OS Interface on Beat
From: Ishizaki Kou @ 2007-09-28 6:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1190881866.6158.13.camel@pasglop>
> On Thu, 2007-09-27 at 16:53 +0900, Ishizaki Kou wrote:
> > This is a patch kit to work with new Guest OS Interface
> > to tweak HTAB on Beat. It detects old and new Guest OS Interfaces
> > automatically.
>
> You may also consider adding an API to Beat to invalidate ranges of
> addresses. We could us that through the batch invalidate mechanism to
> speed up significantly process tear down and forks typically.
Thank you for your suggestion, we'll consider it for next release of
Beat.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Ishizaki Kou @ 2007-09-28 8:04 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190932629.6158.37.camel@pasglop>
Ben-san,
> > It should have been set in setup_64.c, in setup_paca() (which is
called
> > twice) in that statement:
> >
> > local_paca = &paca[cpu];
> >
> > As local_paca is defined as being a variable held in register r13.
Maybe
> > something bad's happening with the compiler ?
> Can you check early_setup disassembly, see if r13 is assigned (it
should
> be in two spots) and if it's clobbered by the compiler somewhere ?
> Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
> makefile and let us know if it makes a difference... r13 is marked
> reserved by the ABI but segher seems to imply that gcc may decide to
ues
> it anyway (ouch !)
I reviewed early_setup() disassembly sets r13 correctly. Now I found
the kernel works well without our hack, so I think I can decline the
patch [1/7].
Commit edd0622bd2e8f755c960827e15aa6908c3c5aa94 seems to break the
kernel and commit 175587cca7447daf5a13e4a53d32360ed8cba804 backs out
the symptom. Calling slb_flush_and_rebolt() at slb_initialize()
function breaks the SLB table since it is called before setting up
PACA.
Thank you for your hint.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Michael Ellerman @ 2007-09-28 8:40 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
Antonino A. Daplas
In-Reply-To: <46FBE6FD.3030605@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
On Thu, 2007-09-27 at 10:23 -0700, Geoff Levand wrote:
> Michael Ellerman wrote:
> > On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> >> Hi,
> >>
> >> Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> >> used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> >> (ps3fb):
> >> [1] ps3av: eliminate unneeded temporary variables
> >> [2] ps3av: eliminate PS3AV_DEBUG
> >> [3] ps3av: use PS3 video mode ids in autodetect code
> >> [4] ps3av: treat DVI-D like HDMI in autodetect
> >> [5] ps3av: add autodetection for VESA modes
> >> [6] ps3av: add quirk database for broken monitors
> >> [7] ps3av: remove unused ps3av_set_mode()
> >> [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
> >>
> >> Please review, and queue for 2.6.24 if they're ok. Thanks!
> >>
> >> Question: As several DVI-D displays advertise they support 1080i modes while
> >> they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> >> modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> >> better than 1080i anyway. What do you think?
> >
> > Definitely. If the autodetection fails Linux is basically unusable on
> > PS3 unless you hack the kernel sources and build your own kboot and
> > otheros.bld - not entirely trivial for novice users. So it's pretty
> > important that it works 100%.
>
> It is not that bad. If a bootloader is configued to use autodetection
> so that it is shown at best video mode, then it should have advertised
> key sequences to default to known video modes, with at least a 480p 'safe'
> mode.
Oh OK, that is a good idea. What's the "safe mode" key sequence for the
otheros.bld you provide on kernel.org?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
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: 189 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Michael Ellerman @ 2007-09-28 8:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, Antonino A. Daplas
In-Reply-To: <Pine.LNX.4.62.0709271344130.10467@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
On Thu, 2007-09-27 at 13:53 +0200, Geert Uytterhoeven wrote:
> On Thu, 27 Sep 2007, Michael Ellerman wrote:
> > On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> > > Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> > > used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> > > (ps3fb):
> > > [1] ps3av: eliminate unneeded temporary variables
> > > [2] ps3av: eliminate PS3AV_DEBUG
> > > [3] ps3av: use PS3 video mode ids in autodetect code
> > > [4] ps3av: treat DVI-D like HDMI in autodetect
> > > [5] ps3av: add autodetection for VESA modes
> > > [6] ps3av: add quirk database for broken monitors
> > > [7] ps3av: remove unused ps3av_set_mode()
> > > [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
> > >
> > > Please review, and queue for 2.6.24 if they're ok. Thanks!
> > >
> > > Question: As several DVI-D displays advertise they support 1080i modes while
> > > they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> > > modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> > > better than 1080i anyway. What do you think?
> >
> > Definitely. If the autodetection fails Linux is basically unusable on
> > PS3 unless you hack the kernel sources and build your own kboot and
> > otheros.bld - not entirely trivial for novice users. So it's pretty
> > important that it works 100%.
>
> Well, this code has been in Geoff's git tree for a while, and it's been several
> weeks ago I got complaints (which have been adressed by adding displays to the
> quirk database). The new kboot (from Distro Kit 1.4.1) also uses it.
Well yeah. Your instructions for diagnosing a quirk are to add #define
DEBUG to ps3av.c and then send the _output from the kernel log_ ... ?
Not to mention that for every quirk reported there's probably 50 users
who just figured Linux on PS3 was broken and gave up.
> The only 100% (sic) mode is 480p (actual usable resolution is 576x384), which
> is quite limited due to the very low resolution. This is what the current
> mainline kernel uses by default, causing complaints from people who don't like
> their shiny expensive full-HD displays being driven by 480p by default.
Sure that's annoying, but not quite as annoying as getting a completely
black screen that you can do nothing about - short of hacking the kernel
and building your own otheros.bld.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
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: 189 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-09-28 9:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBF9B7.9010007@freescale.com>
On Thursday 27 September 2007 20:43, Scott Wood wrote:
> Jon Smirl wrote:
> > The call to msleep() is inside a block protected with
> >
> > :#define in_interrupt() (irq_count())
> >
> > if (!in_interrupt)
> >
> > The stack trace looks like it is in a timer interrupt so shouldn't
> > irq_count be non-zero?
> > Could there be some lack of coordination on irq_count and the timer
> > tick with the preempt patch applied? Or does irq_count() not count
> > soft irqs?
> >
> > (!in_interrupt) may be the wrong way to protect this code.
>
> I think in_atomic() is what you want.
I tried with in_atomic(). The BUG report is gone, but the problem still=20
exists.=20
While network stress testing:=20
[...]
NETDEV WATCHDOG: eth0: transmit timed out
net eth0: transmit timed out
net eth0: queues didn't drain
net eth0: tx: index: 35, outdex: 36
net eth0: rx: index: 24, outdex: 25
PHY: f0003000:00 - Link is Down
PHY: f0003000:00 - Link is Up - 100/Full
The link is up again, but any connection is dead (no answers to ping etc.).=
=20
But the serial console is still working. I'm not sure if the RT-Preempt pat=
ch=20
*causes* this behavior or only *discover* it. Any idea?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=C2=A0Pengutronix - Linux Solutions for Science and Industry
=C2=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=C2=A0 =C2=A0 =C2=A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Misbah khan @ 2007-09-28 9:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FC8EFE.2000108@mock.com>
Jeff Mock-2 wrote:
>
>
>
> Misbah khan wrote:
>>
>>
>> Scott Wood-2 wrote:
>>> Misbah khan wrote:
>>>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>>>> provided by the Linux kernel. I want to know that if anybody is used it
>>>> and have full faith in its operation then please let me know. Driver in
>>>> the while loop is calling these API's hence i want to make sure that
>>>> its
>>>> operation will remain stable.
>>> They're used all over the place. Is there anything about them that you
>>> find suspect?
>>>
>>> -Scott
>>>
>>> I have devloped a character driver for FPGA which is memory mapped and
>>> using these API's to test a bit , set a bit or to clear a bit in the
>>> memory for eg :-
>>>
>>> /* poll till data is transfered from sdram to dpram */
>>> while((test_bit(DFR_BUSY,(UINT32 *)(\
>>> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>>> && (delay < MAX_DELAY_BUSY))
>>> {
>>> KDEBUG3(" In the Dfr delay loop \n");
>>> mdelay(DELAY);
>>> delay+=DELAY;
>>> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>>
>>> if(delay==MAX_DELAY_BUSY)
>>> {
>>> KDEBUG1("Out of the the Dfr busy loop \n");
>>> return -1;
>>> }
>>>
>>> People working for FPGA are sure that they are not making the bit high
>>> where in my driver is returning -1 from the kernel space aborting it
>>> after
>>> running for few minutes or so . Please let me know that This function is
>>> stable and i should tell them that the driver is stable in its operation
>>> and they should check it from there side.
>>>
>
>
> I think a more more likely source of the problem is that the FPGA
> pointer is not cast volatile, or perhaps the FPGA is mapped cached and
> the hardware doesn't always get touched when you think it does. The bit
> manipulation macros are probably fine.
>
> jeff
>
> FPGA is Indeed mapped non cashed here is the part of the code
>
> /* Physical bus memory is mapped */
> mmap_reg_ptr=(UINT32 *)ioremap_nocache(PHY_MEM_ADDR,PHY_MEM_SIZE);
>
> And is it ok if I caste FPGA pointer volatile like this will reduce the
> probability of failure
>
> /* poll till data is transfered from sdram to dpram */
> while((test_bit(DFR_BUSY,(volatile UINT32 *)(\
> (volatile UINT32 *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
> && (delay < MAX_DELAY_BUSY))
> {
> KDEBUG3(" In the Dfr delay loop \n");
> mdelay(DELAY);
> delay+=DELAY;
> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>
> if(delay==MAX_DELAY_BUSY)
> {
> KDEBUG1("Out of the the Dfr busy loop \n");
> return CASHEL_FAILURE;
> }
> __________________
>
> is there anything else that we could do to rely fully in our code.
>
> Misbah
> _____________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12937117
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-28 9:29 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070928.170401.-1300520897.kouish@swc.toshiba.co.jp>
On Fri, 2007-09-28 at 17:04 +0900, Ishizaki Kou wrote:
> Commit edd0622bd2e8f755c960827e15aa6908c3c5aa94 seems to break the
> kernel and commit 175587cca7447daf5a13e4a53d32360ed8cba804 backs out
> the symptom. Calling slb_flush_and_rebolt() at slb_initialize()
> function breaks the SLB table since it is called before setting up
> PACA.
>
> Thank you for your hint.
Ah yes, there was a temporary breakage there that got fixed indeed,
I remember.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Segher Boessenkool @ 2007-09-28 9:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070927183855.GA18226@loki.buserror.net>
> On non-book-E-or-4xx, exceptions execute in real mode. If a fault
> happens
> that leads to a register dump, the kernel currently prints XXXXXXXX
> because
> it doesn't realize that PC is a physical address.
>
> This patch checks the state of the IMMU, and if necessary converts PC
> into a
> virtual address.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> OK, just CONFIG_BOOKE this time. :-P
You forgot to fix the commit message ;-P
Segher
^ permalink raw reply
* Re: [PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)
From: Paul Jackson @ 2007-09-28 9:49 UTC (permalink / raw)
To: travis; +Cc: linux-mm, ak, linux-kernel, linuxppc-dev, sparclinux, akpm,
clameter
In-Reply-To: <20070912015647.214306428@sgi.com>
Mike,
I think there is a bug either in this ia64 patch, or in the related
generic arch patch: Convert cpu_sibling_map to be a per cpu variable
(v3).
It dies early in boot on me, on the SGI internal 8 processor IA64
system that you and I know as 'margin'. The death is a hard hang, due
to a corrupt stack, due to a bogus cpu index.
I haven't tracked it down all the way, but have gotten this far. If I add
the following patch, I get a panic on the BUG_ON if I have these two patches
in 2.6.23-rc8-mm1, but it boots just fine if I don't have these two patches.
It seems that the "cpu_sibling_map[cpu]" cpumask_t is empty (all zero
bits) with your two patches applied, but has some non-zero bits
otherwise, which leads to 'group' being NR_CPUS instead of a useful CPU
number. Unfortunately, I have no idea why the "cpu_sibling_map[cpu]"
cpumask_t is empty -- good luck on that part.
The patch that catches this bug earlier is this:
--- 2.6.23-rc8-mm1.orig/kernel/sched.c 2007-09-28 01:42:20.144561024 -0700
+++ 2.6.23-rc8-mm1/kernel/sched.c 2007-09-28 02:27:14.239075497 -0700
@@ -5905,6 +5905,7 @@ static int cpu_to_phys_group(int cpu, co
#else
group = cpu;
#endif
+ BUG_ON(group == NR_CPUS);
if (sg)
*sg = &per_cpu(sched_group_phys, group);
return group;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: Flash paritioning and JFFS2
From: Mirek23 @ 2007-09-28 9:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1189180542.4826.33.camel@louie>
Dear All,
Finally I have sorted out few problems with linux and u-boot and I have
tried to come back to the jffs2 and mtd partitioning issue.
I am using CFI driver and I pass partitioning information from command line
via u-boot.
This part works fine:
Unfortunatly I have the problem when accesing the flash partitions because
my Avnet evaluation board is designet in such a way that the data should be
accessed in the mode x16 (16 bits in each goal).
Linux CFI driver is able to detect the x16 mode but it does not handle it
correctly.
I will give you an example:
My mtd1 partition contains the u-boot environment. When I print the mtd1
contents with (busybox) hexdump I get:
00000000 eb 92 00 00 62 6f 00 00 61 72 00 00 3d 63 00 00
|....bo..ar..=c..|
00000010 73 6f 00 00 3d 74 00 00 55 4c 00 00 39 36 00 00
|so..=t..UL..96..|
00000020 20 72 00 00 74 3d 00 00 65 76 00 00 66 73 00 00 |
r..t=..ev..fs..|
00000030 77 20 00 00 73 72 00 00 74 3d 00 00 39 2e 00 00 |w
..sr..t=..9...|
00000040 39 2e 00 00 34 2e 00 00 33 3a 00 00 70 74 00 00
|9...4...3:..pt..|
00000050 6c 64 00 00 31 2f 00 00 63 5f 00 00 78 2c 00 00
|ld..1/..c_..x,..|
00000060 70 20 00 00 70 3d 00 00 3a 3a 00 00 72 74 00 00 |p
..p=..::..rt..|
00000070 34 2d 00 00 72 65 00 00 65 74 00 00 3a 64 00 00
|4-..re..et..:d..|
When I copy the contents of the /dev/mtd1 to the file by 2 bytes (bs=2) I
get correct
readout:
dd if=/dev/mtd1 of=./u-boot_Env.txt bs=2 count=128k
hexdump ./u-boot_Env.txt
00000000 eb 92 c9 6d 62 6f 6f 74 61 72 67 73 3d 63 6f 6e
|...mbootargs=con|
00000010 73 6f 6c 65 3d 74 74 79 55 4c 30 2c 39 36 30 30
|sole=ttyUL0,9600|
00000020 20 72 6f 6f 74 3d 2f 64 65 76 2f 6e 66 73 20 72 | root=/dev/nfs
r|
00000030 77 20 6e 66 73 72 6f 6f 74 3d 31 32 39 2e 31 32 |w
nfsroot=129.12|
00000040 39 2e 31 34 34 2e 31 31 33 3a 2f 6f 70 74 2f 65
|9.144.113:/opt/e|
00000050 6c 64 6b 34 31 2f 70 70 63 5f 34 78 78 2c 74 63
|ldk41/ppc_4xx,tc|
The real problems begin when I want to deal with jffs2 file system.
I have mtd3 partition which is intended to hold jffs2 fs.
To create the jffs2 fs I do:
./mkfs.jffs2 --pad=0xA0000 --eraseblock=0x20000 --root=/tmp/bin/mtd1/work/
--output=image2.jffs2
flash_erase /dev/mtd3
dd if=./image2.jffs2 of=/dev/mtd3 bs=2 count=655360
After that I have jffs2 fs under /dev/mtd3.
When I try to mount the jffs2 partition fun begins:
mount -t jffs2 /dev/mtdblock3 /mnt
[ 2828.462121] jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985, 0x2003,
0x00000000) has invalid CRC 0xf0600000 (calculated 0xf9d690b3)
[ 2828.610485] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000008: 0xf060 instead
[ 2828.719326] jffs2_scan_eraseblock(): Node at 0x0000000c {0x1985, 0xe001,
0x00000000) has invalid CRC 0xc3200000 (calculated 0x92fedd67)
[ 2828.870047] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000014: 0xc320 instead
[ 2828.979854] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000024: 0x46fc instead
.
.
.
.
[ 2834.858103] Further such events for this erase block will not be printed
[ 2835.029913] Cowardly refusing to erase blocks on filesystem with no valid
JFFS2 nodes
[ 2835.124378] empty_blocks 0, bad_blocks 0, c->nr_blocks 5
mount: mounting /dev/mtdblock3 on /mnt failed
I have examined carefully the above output and what I see is that linux does
not properly access the flash memory:
I did the hexdump on the image2.jffs2 (which is placed in /dev/mtd3) and
compared it with the jffs2 mount messages:
hexdump -C image2.jffs2
00000000 19 85 20 03 00 00 00 0c f0 60 dc 98 19 85 e0 01 |..
......`......|
00000010 00 00 00 31 c3 20 dd 5d 00 00 00 01 00 00 00 00 |...1.
.]........|
jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985, 0x2003, 0x00000000) has
invalid CRC 0xf0600000 (calculated 0xf9d690b3)
The linux mount complains about wrong CRC (invalid CRC 0xf0600000) but in
the memory it is
f0 60 dc 98 (so it means that it was read in byte by byte mode but not in
x16 (2 bytes) mode).
Does somebody know how to fix this problem?
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Flash-paritioning-and-JFFS2-tf4317566.html#a12937526
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-28 9:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18172.15699.359375.286439@cargo.ozlabs.ibm.com>
-------- Original-Nachricht --------
> Datum: Fri, 28 Sep 2007 09:31:31 +1000
> Von: Paul Mackerras <paulus@samba.org>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> You appear to have a working 16550-style serial port which the udbg
> infrastructure sees. Thus you should be able to use xmon, talking to
I couldn't get udbg running yet. Maybe i didn't specify a proper kernel
boot argument.
> it via the serial port. Put "xmon" on the kernel command line and the
> kernel will drop into xmon early in the boot process (in setup_arch).
> Then, either the kernel will oops at some point and drop into xmon,
> and you can then inspect memory and registers and get a stack trace,
> or it will hang at some point. If it hangs, you can work out where it
> hangs by putting in breakpoints at various points and seeing which
> breakpoints you get to (this might take several boots).
Okay, I'll investigate it. Is there a documentation for xmon (Google
wasn't really helpful in this case).
Thanks!
regards,
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Valentine Barshak @ 2007-09-28 14:23 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <20070925022935.GI30338@localhost.localdomain>
David Gibson wrote:
> On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
>> Currently zImage is linked at the 4MB base address.
>> Some platforms (using cuboot, treeboot) need the zImage's
>> entry point and base address. They place zImage exactly
>> at the base address it's been linked to. Sometimes 4MB left
>> at the start of the memory is simply not enough to unpack zImage.
>> This could happen with initramfs enabled, since the kernel image
>> packed along with initramfs.cpio could be over 5MB in size.
>> This patch checks vmlinux image size and links zImage at
>> the base address that is equal to the unpacked image size
>> aligned to 4MB boundary. This way zImage base address is 4MB
>> only if unpacked kernel image size is less then 4MB.
>
> Good plan. However..
>
> [snip]
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S
>> --- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22 00:48:08.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.000000000 +0400
>> @@ -3,7 +3,7 @@
>> EXTERN(_zimage_start)
>> SECTIONS
>> {
>> - . = (4*1024*1024);
>> + . = ALIGN((_kend - _kstart), (4*1024*1024));
>
> ..I don't see any reason to keep the 4MB granularity. I would just
> align the address to say a 64k boundary (64k because that's the
> granularity used in the normal ABI).
Looking deeper at this I've found that currently u-boot thinks that
memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
defined as (8 << 20)), although all physical memory is identity mapped.
That's why it puts command line and board info structure as high as
possible within the first 8MB. This worked fine with uImage, since
u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
(we need space at the start of the memory to eventually put vmlinux
image there). So, if unpacked kernel image crosses 8MB boundary, it gets
damaged by u-boot when it prepares cmd_line and bdinfo. The possible
workaround for that is to always link zImage at >=8MB base or to have
4MB granularity like this:
+ . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
Reserve at least 64K for u-boot cmd_line and bdinfo.
Thanks,
Valentine.
>
>> _start = .;
>> .text :
>> {
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
^ permalink raw reply
* [patch 2/2] mpc8349emitx.dts: Setup USB-DR for peripheral mode.
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
In-Reply-To: <20070928142113.163317000@sunsite.dk>
Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make
much sense for the mini-AB connector on the ITX board.
Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet
properly support it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -99,6 +99,7 @@
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <26 8>;
+ dr_mode = "peripheral";
phy_type = "ulpi";
};
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 1/2] Fix mpc834x USB-MPH configuration.
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
In-Reply-To: <20070928142113.163317000@sunsite.dk>
mpc834x USB-MPH configuration got broken by commit
6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/platforms/83xx/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/platforms/83xx/usb.c
+++ linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
@@ -76,14 +76,14 @@
if (port0_is_dr)
printk(KERN_WARNING
"834x USB port0 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB0;
+ sicrl &= ~MPC834X_SICRL_USB0;
}
prop = of_get_property(np, "port1", NULL);
if (prop) {
if (port1_is_dr)
printk(KERN_WARNING
"834x USB port1 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB1;
+ sicrl &= ~MPC834X_SICRL_USB1;
}
of_node_put(np);
}
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 0/2] MPC834x USB patches
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
MPC834x USB patches. The first is quite serious and would be nice
to get in 2.6.23.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-09-28 15:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200709271907.50479.jbe@pengutronix.de>
On Thursday 27 September 2007 19:07, Juergen Beisert wrote:
> On Friday 10 August 2007 11:51, Domen Puncer wrote:
> > Not for merge (yet)! But please do review.
> >
> > fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> > good shape, so I tried to change that.
> > Diff against original is quite big (fec_phy.c is completely rewritten)
> > and confuzing, so I'm including whole drivers/net/fec_mpc52xx/ .
> >
> > I still have 'make CONFIG_FEC_MPC52xx_MDIO=3Dn compile and work' on my
> > TODO, maybe even ethtool support.
I add a few more debug outputs and now with this driver I can run a
$ nmap <ip>
from my host against the target and target's network stops always at the sa=
me=20
point.
The last output from the driver is (with DEBUG macro defined):
net eth0: ievent: 08020000
and no further interrupt occurs anymore (I checked all three interrupt entr=
y=20
functions)
nmap on host's side outputs:
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-28 16:56 CEST
Interesting ports on 192.168.23.226:
Not shown: 852 filtered ports, 843 closed ports
PORT STATE SERVICE
22/tcp open ssh
23/tcp open telnet
Nmap finished: 1 IP address (1 host up) scanned in 14.120 seconds
But I can't run it a second time, as the network on target's side doesn't=20
respond. Any idea?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: Milton Miller @ 2007-09-28 15:16 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev
In-Reply-To: <20070928024052.GA18840@localhost.localdomain>
On Sep 27, 2007, at 9:40 PM, David Gibson wrote:
> On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
>> On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
>>>> The actual binary structure is compatable, just not the contents of
>>>> the
>>>> properties nor how any slave cpus wait (for some trees it doesn't
>>>> matter).
>>
>> Sorry, copy and paste error. I was tring to point out this changelog
>> in 2.6.10:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
>> a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed
>
> Hrm, I see, yes that seems conclusive enough. Yuck.
>
> In which case, I think we should try to forget that v1 ever existed.
> I don't think anyone ever generated v1 trees other than kernels which
> also consumed them,
I believe this to be true, unless you count telling dtc to do so.
> and I doubt current kernels will correctly deal
> with v1 trees in this form.
I'm quite certain of that.
> In any case, this is all rather beside the point. My basic point is
> that this bootwrapper stuff should not attempt to be a general
> backwards compatibility layer for every broken early dt format that
> ever existed.
The only broken format was v1; I was submitting v2 :-). Version 16 was
"... to support a more compact representation, for use by embedded
systems mostly"
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
a=commitdiff;h=34153fa3af45d84f3221d9b67ba2ab7e8a220d28
> In general we should try to make sure nothing ever uses
> <v16 trees. We want, here, to do the minimum we can get away with to
> support the specific v2 trees produced by kexec-tools, as an interim
> measure
As I stated, that by itself isn't sufficient for my usage, as I have
other v2 trees I need to deal with, at least until that generator gets
updated.
> while kexec-tools itself is fixed to produce v17 trees (say,
> by replacing fs2dt with dtc plus a libfdt based post-processing
> program).
If you thought there were complaints trying to require an external
utility to build zImage, just wait until you try to make kexec-tools
not be self-contained. Currently kexec doesn't even use a data
directory, instead it builds the purgatory and other trampoline
binaries into the kexec program. Incorporating the post-processing and
generation using libfdt (with a copy of the library in the source)
could fly, if people don't care about kexec into kernels from 2.6.10 to
2.6.14 when v16 was merged (about 1 year).
Actually, there is another approach: put this converter in kexec's
purgatory or even the kexec program. It can then run conditionally
under command line flags to keep compatibility with the old kernels.
If and when its is decided to only support >=v16 in kexec-tools it can
be removed and we don't have this interim support code in the kernel
forever (I'll handle my other usage out of tree).
milton
^ permalink raw reply
* Fwd: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Kumar Gala @ 2007-09-28 15:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-ppc-embedded ((((E-Mail))))
In-Reply-To: <46F7F0B7.2090205@scram.de>
Begin forwarded message:
> From: Jochen Friedrich <jochen@scram.de>
> Date: September 24, 2007 12:15:35 PM CDT
> To: linuxppc-embedded@ozlabs.org
> Cc: linux-kernel@vger.kernel.org, Marcelo Tosatti <marcelo@kvack.org>
> Subject: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
Jeff,
Please pick up for 2.6.23 if you don't mind.
- k
>
>
> Add #include <asm/cacheflush.h> for flush_dcache_range
> to make the driver compile again.
>
> CC arch/ppc/8xx_io/enet.o
> arch/ppc/8xx_io/enet.c: In function 'scc_enet_start_xmit':
> arch/ppc/8xx_io/enet.c:240: error: implicit declaration of function
> 'flush_dcache_range'
> make[1]: *** [arch/ppc/8xx_io/enet.o] Error 1
> make: *** [arch/ppc/8xx_io] Error 2
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> arch/ppc/8xx_io/enet.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c
> index 703d47e..eace3bc 100644
> --- a/arch/ppc/8xx_io/enet.c
> +++ b/arch/ppc/8xx_io/enet.c
> @@ -44,6 +44,7 @@
> #include <asm/mpc8xx.h>
> #include <asm/uaccess.h>
> #include <asm/commproc.h>
> +#include <asm/cacheflush.h>
>
> /*
> * Theory of Operation
>
^ permalink raw reply
* Please pull from 'for-2.6.23' branch
From: Kumar Gala @ 2007-09-28 15:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds
Please pull from 'for-2.6.23' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.23
to receive the following updates:
arch/powerpc/boot/dts/mpc8349emitx.dts | 1 +
arch/powerpc/platforms/83xx/usb.c | 4 ++--
arch/powerpc/sysdev/commproc.c | 2 +-
arch/ppc/8xx_io/commproc.c | 2 +-
drivers/serial/cpm_uart/cpm_uart_cpm1.h | 2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
Jochen Friedrich (3):
[POWERPC] Fix copy'n'paste typo in commproc.c
[PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
[POWERPC] Fix cpm_uart driver for cpm1 machines
jacmet@sunsite.dk (2):
[POWERPC] Fix mpc834x USB-MPH configuration.
[POWERPC] mpc8349emitx.dts: Setup USB-DR for peripheral mode.
commit f93c7c5aab8d5efaf99c88c8452d9303baabc89b
Author: jacmet@sunsite.dk <jacmet@sunsite.dk>
Date: Fri Sep 28 16:21:15 2007 +0200
[POWERPC] mpc8349emitx.dts: Setup USB-DR for peripheral mode.
Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make
much sense for the mini-AB connector on the ITX board.
Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet
properly support it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 39db0fd9db6caea8887f61fee4a0e53c6f8fec5e
Author: jacmet@sunsite.dk <jacmet@sunsite.dk>
Date: Fri Sep 28 16:21:14 2007 +0200
[POWERPC] Fix mpc834x USB-MPH configuration.
mpc834x USB-MPH configuration got broken by commit
6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit d214602804a85e5da68b745ae69d9beaa5bedc93
Author: Jochen Friedrich <jochen@scram.de>
Date: Mon Sep 24 19:15:43 2007 +0200
[POWERPC] Fix cpm_uart driver for cpm1 machines
in cpm_uart_cpm1.h, DPRAM_BASE is assigned an address derived from cpmp.
On ARC=ppc, this is a physical address with 1:1 DMA mapping which can't
be used for arithmetric compare operations with virtual addresses
returned by cpm_dpram_addr. This patch changes the assignment to use
cpm_dpram_addr as well, like in cpm_uart_cpm2.h.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit bc63818931ea55c54d6e59b7d38bff8f295dc8c1
Author: Jochen Friedrich <jochen@scram.de>
Date: Mon Sep 24 19:14:57 2007 +0200
[PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
cpm_dpram_addr returns physical memory of the DP RAM instead of
iomapped virtual memory. As there usually is a 1:1 MMU map of
the IMMR area, this is often not noticed. However, cpm_dpram_phys
assumes this iomapped virtual memory and returns garbage on the
1:1 mapped memory causing CPM1 uart console to fail.
This patch fixes the problem (copied from the powerpc tree).
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 83af919e0f239e87bc644a2c932b9cebf5771380
Author: Jochen Friedrich <jochen@scram.de>
Date: Mon Sep 24 19:13:46 2007 +0200
[POWERPC] Fix copy'n'paste typo in commproc.c
The powerpc version of commproc.c exports cpm_dpram_addr twice
and cpm_dpram_phys not at all due to a typo. This patch fixes this
problem.
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kcrctab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kcrctab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 502f47c..44c065a 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -99,6 +99,7 @@
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <26 8>;
+ dr_mode = "peripheral";
phy_type = "ulpi";
};
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
index e7fdf01..eafe760 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -76,14 +76,14 @@ int mpc834x_usb_cfg(void)
if (port0_is_dr)
printk(KERN_WARNING
"834x USB port0 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB0;
+ sicrl &= ~MPC834X_SICRL_USB0;
}
prop = of_get_property(np, "port1", NULL);
if (prop) {
if (port1_is_dr)
printk(KERN_WARNING
"834x USB port1 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB1;
+ sicrl &= ~MPC834X_SICRL_USB1;
}
of_node_put(np);
}
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 4f67b89..dd5417a 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 7088428..9da880b 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL(cpm_dpdump);
void *cpm_dpram_addr(unsigned long offset)
{
- return ((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem + offset;
+ return (void *)(dpram_vbase + offset);
}
EXPORT_SYMBOL(cpm_dpram_addr);
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.h b/drivers/serial/cpm_uart/cpm_uart_cpm1.h
index a99e45e..2a64778 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.h
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.h
@@ -37,6 +37,6 @@ static inline void cpm_set_smc_fcr(volatile smc_uart_t * up)
up->smc_tfcr = SMC_EB;
}
-#define DPRAM_BASE ((unsigned char *)&cpmp->cp_dpmem[0])
+#define DPRAM_BASE ((unsigned char *)cpm_dpram_addr(0))
#endif
^ permalink raw reply related
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Jon Smirl @ 2007-09-28 15:38 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281707.45030.jbe@pengutronix.de>
On 9/28/07, Juergen Beisert <jbe@pengutronix.de> wrote:
> But I can't run it a second time, as the network on target's side doesn't
> respond. Any idea?
Do the stress tests complete on a non-rt kernel?
That will narrow down the type of bug being looked for.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Fwd: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Jeff Garzik @ 2007-09-28 15:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, linux-ppc-embedded ((((E-Mail))))
In-Reply-To: <7F0D5001-BDDC-48A3-A414-2D3C1CE1574B@kernel.crashing.org>
Kumar Gala wrote:
> Begin forwarded message:
>
>> From: Jochen Friedrich <jochen@scram.de>
>> Date: September 24, 2007 12:15:35 PM CDT
>> To: linuxppc-embedded@ozlabs.org
>> Cc: linux-kernel@vger.kernel.org, Marcelo Tosatti <marcelo@kvack.org>
>> Subject: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
>
> Jeff,
>
> Please pick up for 2.6.23 if you don't mind.
Please send an apply-able patch...
Jeff, off to bed
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Scott Wood @ 2007-09-28 15:40 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281112.18480.jbe@pengutronix.de>
Juergen Beisert wrote:
> I tried with in_atomic(). The BUG report is gone, but the problem still
> exists.
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
> PHY: f0003000:00 - Link is Down
> PHY: f0003000:00 - Link is Up - 100/Full
>
> The link is up again, but any connection is dead (no answers to ping etc.).
> But the serial console is still working. I'm not sure if the RT-Preempt patch
> *causes* this behavior or only *discover* it. Any idea?
I'd try looking at the driver's locking to make sure that it's correct.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox