* [PATCH] cpm_load_patch() - declartion conflict
From: Kamalesh Babulal @ 2007-11-05 10:41 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, paulus, akpm, torvalds
Hi,
The build fails with following error
CC arch/powerpc/sysdev/micropatch.o
arch/powerpc/sysdev/micropatch.c:625: error: conflicting types for ‘cpm_load_patch’
include/asm/commproc.h:94: error: previous declaration of ‘cpm_load_patch’ was here
arch/powerpc/sysdev/micropatch.c: In function ‘cpm_load_patch’:
arch/powerpc/sysdev/micropatch.c:630: warning: unused variable ‘smp’
arch/powerpc/sysdev/micropatch.c:629: warning: unused variable ‘spp’
arch/powerpc/sysdev/micropatch.c:628: warning: unused variable ‘iip’
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
The commit f2a0bd3753dad7ea4605ebd5435716b39e9f92bb defines the function
with void cpm_load_patch(cpm8xx_t *cp) prtotype and is declared as
extern void cpm_load_patch(volatile immap_t *immr) in the header file.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
diff --git a/include/asm-powerpc/commproc.h b/include/asm-powerpc/commproc.h
index 0307c84..a2328b8 100644
--- a/include/asm-powerpc/commproc.h
+++ b/include/asm-powerpc/commproc.h
@@ -91,7 +91,7 @@ extern uint m8xx_cpm_hostalloc(uint size);
extern int m8xx_cpm_hostfree(uint start);
extern void m8xx_cpm_hostdump(void);
-extern void cpm_load_patch(volatile immap_t *immr);
+extern void cpm_load_patch(cpm8xx_t *cp);
/* Buffer descriptors used by many of the CPM protocols.
*/
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply related
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Stefan Roese @ 2007-11-05 9:19 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, netdev, linuxppc-dev
In-Reply-To: <1194147479.6511.11.camel@pasglop>
On Sunday 04 November 2007, Benjamin Herrenschmidt wrote:
> > Isn't this the case where there should really be device tree properties
> > instead? If you had an "ibm,emac-has-axon-stacr" property in the device
> > node, then you don't have to modify the driver for every new board out
> > there. Same for the other device properties, of course.
> >
> > I thought this was what having the device tree was all about. :(
>
> Somewhat yeah. There are subtle variations here or there we haven't
> totally indenfified... It might be a better option in our case here to
> add "has-mdio" to the rgmii nodes indeed.
So how exactly do you want me to handle this (I'm still new to this device
tree stuff, so please bear with me)? Like this?
RGMII0: emac-rgmii@ef601000 {
device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
};
Or add this to the compatible property?
RGMII0: emac-rgmii@ef601000 {
device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii", "ibm,has-mdio";
reg = <ef601000 8>;
};
> Part of the problem with those cells is that the chip folks keep
> changing things subtly from one rev to another though, it's not even
> totally clear to me yet whether the RGMII registers are totally
> compatible betwee axon and 405ex, which is why I've pretty much stuck to
> "compatible" properties to identify the variants.
>
> The device-tree can do both. It's still better than no device-tree since
> at least you know what cell variant is in there.
>
> As for the STACR, Axon isn't the first one to have that bit flipped, I
> think we should name the property differently, something like
> "stacr-oc-inverted".
It's not only the OC bit-flip on AXON, but also the different STACR register
layout for read/write op-codes (STAOPC). This seems to be the same on all new
EMAC core's like on AXON, 440EPx/GRx and 405EX. So "stacr-oc-inverted" is not
enough here. This is what is needed for 440SPe, which "only" has the bit-flip
and the "old" STAOPC layout.
So perhaps most flexible would be to add individual properties,
like "stacr-oc-inverted" and "stacr-staopc-19-20". What do you think? And
again the additional question: Should the be added as an new property or
added to the compatible property?
Please advise. Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: GDB bdi2000 and mpc85xx
From: Stuart Hodgson @ 2007-11-05 8:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <394123578.13658@eyou.net>
Wang,
I had a closer look at all the configuration file options to see what we
had set up. We were missing
REGLIST E500
in the [TARGET] Section.
Thanks again
Stuart
Adding this solved the translation problem
Wang, Baojun wrote:
> On Saturday 03 November 2007 01:17:48, Stuart Hodgson wrote:
>
>> Hi,
>>
>> I am attempting to get Kernel debugging working on our mpc8541 based
>> board via a BDI2000. The various components in use are
>>
>> kernel - 2.6.19.2
>> BDI firmware - 1.08
>> U-Boot - 1.2.0
>> ppc_85xx-gdb - from eldk4.1 (6.3.0.0-1.21_3rh)
>>
>>
>> Kernel is configured with `-g` in CFLAGS and not with CONFIG_BDI_SWITCH,
>> from the information I have read around the subject this seem to be
>> correct. I also have `MMU XLAT`, and `PTBASE 0xF0` set in by BDI
>> configuration file. The default value for XLAT of `0xc0000000` matches
>> the kernel our kernel config.
>>
>> Steps that I done so far
>>
>> 1. Power on BDI
>> 2. Power on the board
>> 3. BDI> reset run
>> 4. Enter u-boot environment to stop linux booting immediately.
>> 5. BDI> HALT
>> 6. BDI> BREAK HARD
>> 7. BDI> BI 0xc025a51c (this is the address of start_kernel for my build)
>> 8. BDI> GO
>> 9. From U-boot prompt `bootm`, kernel is copied from flash and loading
>> begins
>> 10. Kernel does not halt at start_kernel and continues to the login
>>
>> If I attempt to break at an address later in the boot sequence, such as
>> qmx19_ata_input_data (this is the area that I am trying to investigate)
>> I get
>>
>> - TARGET: core #0 has entered debug mode
>>
>> So from here I attempt to connect to the BDI from gdb
>>
>> linux> cd ~/linux-2.6.19.2
>> linux> ppc_85xx-gdb vmlimux
>>
> Most of the operation could be done within gdb
>
> BDI> reset
>
> powerpc-unknown-linux-gnu-gdb vmlinux
> (gdb) target remote bdi:2001
> (gdb) ^C
> (gdb) b *0x12345678
> (gdb) c
> ...
>
>> "
>> GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you
>> are welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
>> The target architecture is set automatically (currently powerpc:603)
>> "
>>
>> I noticed here that the last line does not match the e500 core I am
>> using, but there does not seem to a change if I change this using `set
>> architecture powerpc:e500`
>>
>>
>> (gdb) tar rem <bdi_ip>:2001
>> Remote debugging using <bdi_ip>:2001
>> 0x00000000 in ?? ()
>>
>
> Which configuration file do you use for mpc85xx? probably is the config file
> problem?
>
>
>> What I don't understand here is why 0x00000000 is shown as the address,
>> further on the BDI the following error is shown then the connection is made
>>
>> "
>> *** MMU: address translation for 0x00000000 failed
>>
>
>
>> Stuart Hodgson
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
> Wang
>
>
^ permalink raw reply
* libfdt: Fix sw_tree1 testcase
From: David Gibson @ 2007-11-05 5:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
There is a bug in the sw_tree1 testcase / utility which puts two
"compatible" properties in one node in the output tree. This patch
fixes the bug, and also adds a new test checking that the sw_tree1
output is equal to test_tree1.dtb as its supposed to be, which should
catch future errors of this type.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-11-05 16:33:05.000000000 +1100
+++ dtc/tests/run_tests.sh 2007-11-05 16:33:37.000000000 +1100
@@ -71,6 +71,7 @@ libfdt_tests () {
run_test sw_tree1
tree1_tests sw_tree1.test.dtb
tree1_tests unfinished_tree1.test.dtb
+ run_test dtbs_equal_ordered test_tree1.dtb sw_tree1.test.dtb
# fdt_move tests
for tree in test_tree1.dtb sw_tree1.test.dtb unfinished_tree1.test.dtb; do
@@ -112,6 +113,7 @@ libfdt_tests () {
run_test rw_tree1
tree1_tests rw_tree1.test.dtb
tree1_tests_rw rw_tree1.test.dtb
+ run_test dtbs_equal_ordered test_tree1.dtb rw_tree1.test.dtb
# Tests for behaviour on various sorts of corrupted trees
run_test truncated_property
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-11-05 16:33:57.000000000 +1100
+++ dtc/tests/sw_tree1.c 2007-11-05 16:34:03.000000000 +1100
@@ -64,7 +64,6 @@ int main(int argc, char *argv[])
CHECK(fdt_begin_node(fdt, "subsubnode"));
CHECK(fdt_property(fdt, "compatible", "subsubnode1\0subsubnode",
23));
- CHECK(fdt_property_string(fdt, "compatible", "subsubnode1\0"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
--
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 3/6]] POWERPC: fix memset size error
From: Benjamin Herrenschmidt @ 2007-11-05 5:35 UTC (permalink / raw)
To: Li Zefan; +Cc: linuxppc-dev, Andrew Morton, paulus, LKML
In-Reply-To: <472E7E44.6000807@cn.fujitsu.com>
On Mon, 2007-11-05 at 10:21 +0800, Li Zefan wrote:
> The size passing to memset is wrong.
>
> Signed-off-by Li Zefan <lizf@cn.fujitsu.com>
Good catch, looks like a remain of when path was an array on the stack.
Thanks !
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
> arch/powerpc/kernel/prom_init.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 1db10f7..1add6ef 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1244,7 +1244,7 @@ static void __init prom_initialize_tce_table(void)
> local_alloc_bottom = base;
>
> /* It seems OF doesn't null-terminate the path :-( */
> - memset(path, 0, sizeof(path));
> + memset(path, 0, PROM_SCRATCH_SIZE);
> /* Call OF to setup the TCE hardware */
> if (call_prom("package-to-path", 3, 1, node,
> path, PROM_SCRATCH_SIZE-1) == PROM_ERROR) {
^ permalink raw reply
* [PATCH 3/6]] POWERPC: fix memset size error
From: Li Zefan @ 2007-11-05 2:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, paulus, LKML
The size passing to memset is wrong.
Signed-off-by Li Zefan <lizf@cn.fujitsu.com>
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1db10f7..1add6ef 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1244,7 +1244,7 @@ static void __init prom_initialize_tce_table(void)
local_alloc_bottom = base;
/* It seems OF doesn't null-terminate the path :-( */
- memset(path, 0, sizeof(path));
+ memset(path, 0, PROM_SCRATCH_SIZE);
/* Call OF to setup the TCE hardware */
if (call_prom("package-to-path", 3, 1, node,
path, PROM_SCRATCH_SIZE-1) == PROM_ERROR) {
--
1.5.3.rc7
^ permalink raw reply related
* libfdt: Add more documentation (patch the fourth)
From: David Gibson @ 2007-11-05 3:29 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch documents a few more functions in libfdt.h. It also makes
a slight update to the description of the FDT_ERR_INTERNAL error code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-11-05 14:08:10.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-11-05 14:23:17.000000000 +1100
@@ -110,7 +110,8 @@
/* "Can't happen" error indicating a bug in libfdt */
#define FDT_ERR_INTERNAL 12
/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
- * Indicates a bug in libfdt itself. */
+ * Should never be returned, if it is, it indicates a bug in
+ * libfdt itself. */
#define FDT_ERR_MAX 12
@@ -437,9 +438,81 @@ static inline void *fdt_getprop_w(void *
*/
int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+/**
+ * fdt_supernode_atdepth_offset - find a specific ancestor of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ * @supernodedepth: depth of the ancestor to find
+ * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_supernode_atdepth_offset() finds an ancestor of the given node
+ * at a specific depth from the root (where the root itself has depth
+ * 0, its immediate subnodes depth 1 and so forth). So
+ * fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
+ * will always return 0, the offset of the root node. If the node at
+ * nodeoffset has depth D, then:
+ * fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
+ * will return nodeoffset itself.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+
+ * structure block offset of the node at node offset's ancestor
+ * of depth supernodedepth (>=0), on success
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+* -FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
int supernodedepth, int *nodedepth);
+
+/**
+ * fdt_node_depth - find the depth of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_node_depth() finds the depth of a given node. The root node
+ * has depth 0, its immediate subnodes depth 1 and so forth.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ * depth of the node at nodeoffset (>=0), on success
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
int fdt_node_depth(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_parent_offset - find the parent of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_parent_offset() locates the parent node of a given node (that
+ * is, it finds the offset of the node which contains the node at
+ * nodeoffset as a subnode).
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset, *twice*.
+ *
+ * returns:
+ * stucture block offset of the parent of the node at nodeoffset
+ * (>=0), on success
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
int fdt_parent_offset(const void *fdt, int nodeoffset);
int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
--
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: libfdt: Add more documentation (patch the third)
From: David Gibson @ 2007-11-05 3:29 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20071102044716.GK19839@localhost.localdomain>
libfdt: Add more documentation (patch the third)
This patch adds documentation in libfdt.h for a few more libfdt
functions. It also makes a slight update to the documentation of
fdt_get_name().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Just the same as before, but now with S-o-b line.
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-11-02 15:44:58.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-11-02 15:46:37.000000000 +1100
@@ -319,28 +319,54 @@ int fdt_path_offset(const void *fdt, con
* fdt_get_name - retreive the name of a given node
* @fdt: pointer to the device tree blob
* @nodeoffset: structure block offset of the starting node
- * @len: pointer to an intger variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
*
* fdt_get_name() retrieves the name (including unit address) of the
- * device tree node at structure block offset nodeoffset. If len is
+ * device tree node at structure block offset nodeoffset. If lenp is
* non-NULL, the length of this name is also returned, in the integer
- * pointed to by len.
+ * pointed to by lenp.
*
* returns:
* pointer to the node's name, on success
- * *len contains the length of that name (>=0)
+ * If lenp is non-NULL, *lenp contains the length of that name (>=0)
* NULL, on error
- * *len contains an error code (<0):
+ * if lenp is non-NULL *lenp contains an error code (<0):
* -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
* -FDT_ERR_BADMAGIC,
* -FDT_ERR_BADVERSION,
* -FDT_ERR_BADSTATE, standard meanings
*/
-const char *fdt_get_name(const void *fdt, int nodeoffset, int *len);
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset. If lenp is
+ * non-NULL, the length of the property value also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ * pointer to the structure representing the property
+ * if lenp is non-NULL, *lenp contains the length of the property
+ * value (>=0)
+ * NULL, on error
+ * if lenp is non-NULL, *lenp contains an error code (<0):
+ * -FDT_ERR_NOTFOUND, node does not have named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
const char *name, int *lenp);
-
static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
const char *name,
int *lenp)
@@ -349,6 +375,33 @@ static inline struct fdt_property *fdt_g
name, lenp);
}
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ * pointer to the property's value
+ * if lenp is non-NULL, *lenp contains the length of the property
+ * value (>=0)
+ * NULL, on error
+ * if lenp is non-NULL, *lenp contains an error code (<0):
+ * -FDT_ERR_NOTFOUND, node does not have named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
const void *fdt_getprop(const void *fdt, int nodeoffset,
const char *name, int *lenp);
static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
@@ -357,6 +410,31 @@ static inline void *fdt_getprop_w(void *
return (void *)fdt_getprop(fdt, nodeoffset, name, lenp);
}
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ * 0, on success
+ * buf contains the absolute path of the node at
+ * nodeoffset, as a NUL-terminated string.
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * -FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ * characters and will not fit in the given buffer.
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
--
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
* [PATCH] [POWERPC] pasemi: Broaden specific references to 1682M
From: Olof Johansson @ 2007-11-05 3:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Doug Thompson
[POWERPC] pasemi: Broaden specific references to 1682M
There will be more product numbers in the future than just PA6T-1682M,
but they will share much of the features. Remove some of the explicit
references and compatibility checks with 1682M, and replace most of them
with the more generic term "PWRficient".
Signed-off-by: Olof Johansson <olof@lixom.net>
---
This one touches drivers/char/hw_random and drivers/edac, but I'd prefer
to just merge it up through the powerpc merge path since the changes
are trivial.
(Michael, Doug, if you disagree let me know and I can submit separate
patches. This is 2.6.25 material anyway).
-Olof
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index 735e153..2f4dd6e 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -17,7 +17,7 @@ config PPC_PASEMI_IOMMU
bool "PA Semi IOMMU support"
depends on PPC_PASEMI
help
- IOMMU support for PA6T-1682M
+ IOMMU support for PA Semi PWRficient
config PPC_PASEMI_IOMMU_DMA_FORCE
bool "Force DMA engine to use IOMMU"
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c b/arch/powerpc/platforms/pasemi/cpufreq.c
index 1cfb8b0..8caa166 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -147,7 +147,10 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
if (!cpu)
goto out;
- dn = of_find_compatible_node(NULL, "sdc", "1682m-sdc");
+ dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
+ if (!dn)
+ dn = of_find_compatible_node(NULL, NULL,
+ "pasemi,pwrficient-sdc");
if (!dn)
goto out;
err = of_address_to_resource(dn, 0, &res);
@@ -160,7 +163,10 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
goto out;
}
- dn = of_find_compatible_node(NULL, "gizmo", "1682m-gizmo");
+ dn = of_find_compatible_node(NULL, NULL, "1682m-gizmo");
+ if (!dn)
+ dn = of_find_compatible_node(NULL, NULL,
+ "pasemi,pwrficient-gizmo");
if (!dn) {
err = -ENODEV;
goto out_unmap_sdcasr;
@@ -292,7 +298,8 @@ static struct cpufreq_driver pas_cpufreq_driver = {
static int __init pas_cpufreq_init(void)
{
- if (!machine_is_compatible("PA6T-1682M"))
+ if (!machine_is_compatible("PA6T-1682M") &&
+ !machine_is_compatible("pasemi,pwrficient"))
return -ENODEV;
return cpufreq_register_driver(&pas_cpufreq_driver);
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index 95d0c78..b029804 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -333,7 +333,10 @@ int gpio_mdio_init(void)
{
struct device_node *np;
- np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
+ np = of_find_compatible_node(NULL, NULL, "1682m-gpio");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL,
+ "pasemi,pwrficient-gpio");
if (!np)
return -ENODEV;
gpio_regs = of_iomap(np, 0);
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 3a5d112..aeafe98 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -362,8 +362,11 @@ static inline void pasemi_pcmcia_init(void)
static struct of_device_id pasemi_bus_ids[] = {
+ /* Unfortunately needed for legacy firmwares */
{ .type = "localbus", },
{ .type = "sdc", },
+ { .compatible = "pasemi,localbus", },
+ { .compatible = "pasemi,sdc", },
{},
};
@@ -389,7 +392,8 @@ static int __init pas_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (!of_flat_dt_is_compatible(root, "PA6T-1682M"))
+ if (!of_flat_dt_is_compatible(root, "PA6T-1682M") &&
+ !of_flat_dt_is_compatible(root, "pasemi,pwrficient"))
return 0;
hpte_init_native();
@@ -400,7 +404,7 @@ static int __init pas_probe(void)
}
define_machine(pasemi) {
- .name = "PA Semi PA6T-1682M",
+ .name = "PA Semi PWRficient",
.probe = pas_probe,
.setup_arch = pas_setup_arch,
.init_early = pas_init_early,
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 2d7cd48..6bbd4fa 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -98,7 +98,7 @@ config HW_RANDOM_PASEMI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
- Generator hardware found on PA6T-1682M processor.
+ Generator hardware found on PA Semi PWRficient SoCs.
To compile this driver as a module, choose M here: the
module will be called pasemi-rng.
diff --git a/drivers/char/hw_random/pasemi-rng.c b/drivers/char/hw_random/pasemi-rng.c
index fa6040b..24ae307 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -126,10 +126,9 @@ static int __devexit rng_remove(struct of_device *dev)
}
static struct of_device_id rng_match[] = {
- {
- .compatible = "1682m-rng",
- },
- {},
+ { .compatible = "1682m-rng", },
+ { .compatible = "pasemi,pwrficient-rng", },
+ { },
};
static struct of_platform_driver rng_driver = {
diff --git a/drivers/edac/pasemi_edac.c b/drivers/edac/pasemi_edac.c
index 9007d06..9032091 100644
--- a/drivers/edac/pasemi_edac.c
+++ b/drivers/edac/pasemi_edac.c
@@ -225,7 +225,7 @@ static int __devinit pasemi_edac_probe(struct pci_dev *pdev,
EDAC_FLAG_NONE;
mci->mod_name = MODULE_NAME;
mci->dev_name = pci_name(pdev);
- mci->ctl_name = "pasemi,1682m-mc";
+ mci->ctl_name = "pasemi,pwrficient-mc";
mci->edac_check = pasemi_edac_check;
mci->ctl_page_to_phys = NULL;
pci_read_config_dword(pdev, MCCFG_SCRUB, &scrub);
@@ -297,4 +297,4 @@ module_exit(pasemi_edac_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Egor Martovetsky <egor@pasemi.com>");
-MODULE_DESCRIPTION("MC support for PA Semi PA6T-1682M memory controller");
+MODULE_DESCRIPTION("MC support for PA Semi PWRficient memory controller");
^ permalink raw reply related
* Re: [PATCH v2 01/12] [POWERPC] Add 'model: ...' line to common show_cpuinfo()
From: Olof Johansson @ 2007-11-05 1:40 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235216.31906.62666.stgit@hekate.izotz.org>
On Sun, Nov 04, 2007 at 12:52:16AM +0100, Marian Balakowicz wrote:
> Print out 'model' property of '/' node as a machine name
> in generic show_cpuinfo() routine.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: Olof Johansson <olof@lixom.net>
(just as the previous posting of it)
-Olof
^ permalink raw reply
* Re: [PATCH] pasemi: clean up gpio_mdio init
From: Olof Johansson @ 2007-11-05 1:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Roel Kluin
In-Reply-To: <20071105112307.13d4b8bb.sfr@canb.auug.org.au>
Hi,
On Mon, Nov 05, 2007 at 11:23:07AM +1100, Stephen Rothwell wrote:
> Just a couple of small things ...
Thanks! Unless someone finds something bigger, I'll update this before
I push it out through git, but I won't repost.
> On Sun, 4 Nov 2007 15:37:09 -0600 Olof Johansson <olof@lixom.net> wrote:
> >
> > + ip = of_get_property(phy_dn, "interrupts", NULL);
> > + regp = of_get_property(phy_dn, "reg", NULL);
> > + if (!ip || !regp)
> > + continue;
> > + new_bus->irq[*regp] = irq_create_mapping(NULL, *ip);
>
> Paranoid me says to check that *regp is in range.
Yeah, good point.
>
> > int gpio_mdio_init(void)
> > {
> > + struct device_node *np;
> > +
> > + np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
> > + if (!np)
> > + return -ENODEV;
> > + gpio_regs = of_iomap(np, 0);
>
> of_node_put(np); ?
Yup.
Thanks for the review,
-Olof
^ permalink raw reply
* Re: [PATCH v2 11/12] [POWERPC] Promess Motion-PRO DTS
From: David Gibson @ 2007-11-05 0:56 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235317.31906.46911.stgit@hekate.izotz.org>
On Sun, Nov 04, 2007 at 12:53:17AM +0100, Marian Balakowicz wrote:
> Add device tree source file for Motion-PRO board.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Same comments as for the other two device trees, plus those below:
[snip]
> + motionpro-statusled@660 { // Motion-PRO status LED
> + compatible = "promess,motionpro-statusled";
> + cell-index = <6>;
> + reg = <660 10>;
> + interrupts = <1 f 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + blink-delay = <64>; // 100 msec
> + };
> +
> + motionpro-readyled@670 { // Motion-PRO ready LED
> + compatible = "promess,motionpro-readyled";
> + cell-index = <7>;
These cell-index values for the LEDs look very strange. How are they
used?
> + reg = <670 10>;
> + interrupts = <1 10 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + rtc@800 { // Real time clock
> + compatible = "mpc5200b-rtc","mpc5200-rtc";
> + device_type = "rtc";
> + reg = <800 100>;
> + interrupts = <1 5 0 1 6 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + mscan@980 {
> + compatible = "mpc5200b-mscan","mpc5200-mscan";
> + cell-index = <1>;
As for serial and gpt, is cell-index really suitable here?
> + interrupts = <2 12 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + reg = <980 80>;
> + };
[snip]
> + spi@f00 {
> + device_type = "spi";
> + compatible = "mpc5200b-spi","mpc5200-spi";
> + reg = <f00 20>;
> + interrupts = <2 d 0 2 e 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
[snip]
> + // PSC2 in spi master mode
> + spi@2200 { // PSC2
> + device_type = "spi";
> + compatible = "mpc5200b-psc-spi","mpc5200-psc-spi";
> + cell-index = <1>;
cell-index present for one spi, but not the other makes be even more
suspicious about it's applicability here...
> + reg = <2200 100>;
> + interrupts = <2 2 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
[snip]
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
Is lpb another one of these chipselect/offset configurable bus bridge
things? If so, you should use a 2-cell addressing convention for the
subnodes like fsl localbus and 4xx EBC.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <50000000 50000000 00030000
> + ff000000 ff000000 01000000>;
> +
> + // 8-bit DualPort SRAM on LocalPlus Bus CS1
> + kollmorgen@50000000 {
> + compatible = "promess,motionpro-kollmorgen";
> + reg = <50000000 ffff>;
> + interrupts = <1 1 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + // 8-bit board CPLD on LocalPlus Bus CS2
> + cpld@50010000 {
> + compatible = "promess,motionpro-cpld";
> + reg = <50010000 ffff>;
> + };
> +
> + // 8-bit custom Anybus Module on LocalPlus Bus CS3
> + anybus50020000 {
Missing '@'.
> + compatible = "promess,motionpro-anybus";
> + reg = <50020000 ffff>;
> + };
> + pro_module_general@50020000 {
> + compatible = "promess,pro_module_general";
> + reg = <50020000 3>;
> + };
> + pro_module_dio@50020800 {
> + compatible = "promess,pro_module_dio";
> + reg = <50020800 2>;
> + };
> + };
--
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 v2 08/12] [POWERPC] CM5200 DTS
From: David Gibson @ 2007-11-05 0:50 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235259.31906.54116.stgit@hekate.izotz.org>
On Sun, Nov 04, 2007 at 12:52:59AM +0100, Marian Balakowicz wrote:
> Add device tree source file for CM5200 board.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Same comments as the TQM device tree, plus those below.
[snip]
> + rtc@800 { // Real time clock
> + compatible = "mpc5200b-rtc","mpc5200-rtc";
> + device_type = "rtc";
No device_type here.
[snip]
> + spi@f00 {
> + device_type = "spi";
Definitely no device_type here.
> + compatible = "mpc5200b-spi","mpc5200-spi";
> + reg = <f00 20>;
> + interrupts = <2 d 0 2 e 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
[snip]
> + i2c@3d40 {
> + device_type = "i2c";
No device_type here.
> + compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
> + reg = <3d40 40>;
> + interrupts = <2 10 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + fsl5200-clocking;
> + };
> +
> + sram@8000 {
> + compatible = "mpc5200b-sram","mpc5200-sram","sram";
> + reg = <8000 4000>;
> + };
> + };
> +};
--
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 v2 06/12] [POWERPC] TQM5200 DTS
From: David Gibson @ 2007-11-05 0:47 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235247.31906.76777.stgit@hekate.izotz.org>
On Sun, Nov 04, 2007 at 12:52:47AM +0100, Marian Balakowicz wrote:
> Add device tree source file for TQM5200 board.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
[snip]
> + soc5200@f0000000 {
soc@address is the new convention, I believe, but I guess you need
compatibility with older bootstraps.
> + model = "fsl,mpc5200";
> + compatible = "mpc5200";
This compatible looks bogus; it should have the "fsl," at least.
[snip]
> + mpc5200_pic: pic@500 {
> + // 5200 interrupts are encoded into two levels;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + device_type = "interrupt-controller";
No device_type here.
> + compatible = "mpc5200-pic";
> + reg = <500 80>;
> + };
> +
> + gpt@600 { // General Purpose Timer
> + compatible = "fsl,mpc5200-gpt";
> + cell-index = <0>;
Ok, is this actually a suitable usage for cell-index? It should only
be used when the cell-index number is used to program some soc-global
register. It should not be used just for ordering or logical-indexing
purposes.
[snip]
> + serial@2000 { // PSC1
> + device_type = "serial";
> + compatible = "mpc5200-psc-uart";
> + port-number = <0>; // Logical port assignment
> + cell-index = <0>;
Ditto w.r.t. cell-index.
port-number also looks bogus - the device tree should not generally
contain logical numbering information in this manner. How and what
uses the port-number property?
> + sram@8000 {
> + compatible = "mpc5200-sram","sram";
Uh.. is there an "sram" binding? "sram" doesn't look specific enough
for a compatible property.
--
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] pasemi: clean up gpio_mdio init
From: Stephen Rothwell @ 2007-11-05 0:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Roel Kluin
In-Reply-To: <20071104213709.GA13266@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
Hi Olof,
Just a couple of small things ...
On Sun, 4 Nov 2007 15:37:09 -0600 Olof Johansson <olof@lixom.net> wrote:
>
> + ip = of_get_property(phy_dn, "interrupts", NULL);
> + regp = of_get_property(phy_dn, "reg", NULL);
> + if (!ip || !regp)
> + continue;
> + new_bus->irq[*regp] = irq_create_mapping(NULL, *ip);
Paranoid me says to check that *regp is in range.
> int gpio_mdio_init(void)
> {
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
> + if (!np)
> + return -ENODEV;
> + gpio_regs = of_iomap(np, 0);
of_node_put(np); ?
> + if (!gpio_regs)
> + return -ENODEV;
> +
> return of_register_platform_driver(&gpio_mdio_driver);
> }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [U-Boot-Users] use of aliases in device trees
From: Grant Likely @ 2007-11-04 23:32 UTC (permalink / raw)
To: Grant Likely, Kumar Gala, linux-ppc list, U-Boot Users List
In-Reply-To: <20071104224256.GC15444@localhost.localdomain>
On 11/4/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sat, Nov 03, 2007 at 09:29:48PM -0600, Grant Likely wrote:
> > Maybe something like:
> > aliases {
> > enet0,phandle = <&enet0>;
> > enet1,phandle = <&enet1>;
> > ...
> > };
>
> The fairly small advantages of using phandles here are not worth the
> hassle of defining a new alias format, when the OF one with full paths
> already exists.
>
> I would, however, like to extend dtc so that we can do something like:
> aliases {
> enet0 = &enet0;
> };
> and the reference in non-cell context will expand to the full path.
> That could be used for things like linux,stdout-path in /chosen, too.
>
> I'd also like to extend dtc so that the label can be tagged somehow, say:
> *enet0: { ... };
> and as well as creating a normal dtc label, an alias will also be
> automatically added to /aliases.
Yeah, okay! I like both of those ideas. That certainly addresses my
ease of maintenance concerns.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [U-Boot-Users] use of aliases in device trees
From: David Gibson @ 2007-11-04 22:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list, U-Boot Users List
In-Reply-To: <fa686aa40711032029x3871b76m5b44a6e93d8d7217@mail.gmail.com>
On Sat, Nov 03, 2007 at 09:29:48PM -0600, Grant Likely wrote:
> On 11/3/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> > In some discussion on the u-boot dev list it became clear that having
> > aliases in the device tree might be useful as a common way to deal
> > with finding specific nodes that need fixing up by the firmware.
> > This problem also exists in the kernel bootwrappers.
> >
> > The common example is how to associate a given MAC address with the
> > proper ethernet node. In u-boot an explicit path is hard coded into
> > the u-boot build for each ethernet device. In the bootwrapper we use
> > "linux,network-index = <N>" in the given ethernet node.
> >
> > One common solution would be having a top level aliases like the pmac
> > tree's have:
> >
> > aliases {
> > enet0 = "...";
> > enet1 = "...";
> > pci0 = "...";
> > pci1 = "...";
> > };
>
> One question to ask is do we use full paths or phandles to point at nodes?
>
> OF, of course, uses full paths, but that does require more memory and
> processing power, but it might not be significant enough to worry
> about.
>
> If we use phandles, then we should use names that don't conflict with
> full path alias names. It would also be desirable to be able to
> generate a phandle alias from the full path alias in order to maintain
> some level of compatibility with OF. It also think it will make
> maintaining aliases in .dts files simpler because trivial changes to
> node paths won't break the phandle alias.
>
> Maybe something like:
> aliases {
> enet0,phandle = <&enet0>;
> enet1,phandle = <&enet1>;
> ...
> };
The fairly small advantages of using phandles here are not worth the
hassle of defining a new alias format, when the OF one with full paths
already exists.
I would, however, like to extend dtc so that we can do something like:
aliases {
enet0 = &enet0;
};
and the reference in non-cell context will expand to the full path.
That could be used for things like linux,stdout-path in /chosen, too.
I'd also like to extend dtc so that the label can be tagged somehow, say:
*enet0: { ... };
and as well as creating a normal dtc label, an alias will also be
automatically added to /aliases.
--
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 v2 02/12] [POWERPC] Add 'fsl, lpb' bus type for MPC5200 LocalPlus Bus
From: David Gibson @ 2007-11-04 22:18 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235222.31906.44523.stgit@hekate.izotz.org>
On Sun, Nov 04, 2007 at 12:52:22AM +0100, Marian Balakowicz wrote:
> Define MPC52xx specific device id list, add new
> 'fsl,lpb' compatible id for LocalPlus Bus.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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 v2 01/12] [POWERPC] Add 'model: ...' line to common show_cpuinfo()
From: David Gibson @ 2007-11-04 22:17 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071103235216.31906.62666.stgit@hekate.izotz.org>
On Sun, Nov 04, 2007 at 12:52:16AM +0100, Marian Balakowicz wrote:
> Print out 'model' property of '/' node as a machine name
> in generic show_cpuinfo() routine.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
* [PATCH] pasemi: clean up gpio_mdio init
From: Olof Johansson @ 2007-11-04 21:37 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <472E0569.7070601@tiscali.nl>
pasemi: clean up mdio_gpio driver init
Misc cleanups of mdio_gpio:
* Better error handling/unrolling in case of init/alloc failures
* Go through child nodes and get their interrupts instead of using
hardcoded values
* Remap the GPIO registers at module load/driver init instead of during probe
* Coding style and other misc cleanups
Signed-off-by: Olof Johansson <olof@lixom.net>
---
On Sun, Nov 04, 2007 at 06:46:17PM +0100, Roel Kluin wrote:
> Olof Johansson wrote:
> > On Sun, Nov 04, 2007 at 05:53:40PM +0100, Roel Kluin wrote:
> >> I think this is how it should be done, but
> >> please review: it was not tested.
> >
> > Hi,
> >
> > Thanks for the bug report. The mdio driver needs a set of other cleanups
> > as well. I have a more comprehensive patch that I'll post tomorrow after
> > I have a chance to test them.
>
> Ok, that's fine with me,
This is what I'll queue up for 2.6.25.
-Olof
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index dae9f65..2254091 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -218,45 +218,27 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
struct device *dev = &ofdev->dev;
- struct device_node *np = ofdev->node;
- struct device_node *gpio_np;
+ struct device_node *phy_dn, *np = ofdev->node;
struct mii_bus *new_bus;
- struct resource res;
struct gpio_priv *priv;
const unsigned int *prop;
- int err = 0;
+ int err;
int i;
- gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
-
- if (!gpio_np)
- return -ENODEV;
-
- err = of_address_to_resource(gpio_np, 0, &res);
- of_node_put(gpio_np);
-
- if (err)
- return -EINVAL;
-
- if (!gpio_regs)
- gpio_regs = ioremap(res.start, 0x100);
-
- if (!gpio_regs)
- return -EPERM;
-
+ err = -ENOMEM;
priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
- if (priv == NULL)
- return -ENOMEM;
+ if (!priv)
+ goto out;
new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
- if (new_bus == NULL)
- return -ENOMEM;
+ if (!new_bus)
+ goto out_free_priv;
- new_bus->name = "pasemi gpio mdio bus",
- new_bus->read = &gpio_mdio_read,
- new_bus->write = &gpio_mdio_write,
- new_bus->reset = &gpio_mdio_reset,
+ new_bus->name = "pasemi gpio mdio bus";
+ new_bus->read = &gpio_mdio_read;
+ new_bus->write = &gpio_mdio_write;
+ new_bus->reset = &gpio_mdio_reset;
prop = of_get_property(np, "reg", NULL);
new_bus->id = *prop;
@@ -265,9 +247,24 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
new_bus->phy_mask = 0;
new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
- for(i = 0; i < PHY_MAX_ADDR; ++i)
- new_bus->irq[i] = irq_create_mapping(NULL, 10);
+ if (!new_bus->irq)
+ goto out_free_bus;
+
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ new_bus->irq[i] = NO_IRQ;
+
+ for (phy_dn = of_get_next_child(np, NULL);
+ phy_dn != NULL;
+ phy_dn = of_get_next_child(np, phy_dn)) {
+ const int *ip, *regp;
+
+ ip = of_get_property(phy_dn, "interrupts", NULL);
+ regp = of_get_property(phy_dn, "reg", NULL);
+ if (!ip || !regp)
+ continue;
+ new_bus->irq[*regp] = irq_create_mapping(NULL, *ip);
+ }
prop = of_get_property(np, "mdc-pin", NULL);
priv->mdc_pin = *prop;
@@ -280,17 +277,21 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
err = mdiobus_register(new_bus);
- if (0 != err) {
+ if (err != 0) {
printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
new_bus->name, err);
- goto bus_register_fail;
+ goto out_free_irq;
}
return 0;
-bus_register_fail:
+out_free_irq:
+ kfree(new_bus->irq);
+out_free_bus:
kfree(new_bus);
-
+out_free_priv:
+ kfree(priv);
+out:
return err;
}
@@ -330,12 +331,23 @@ static struct of_platform_driver gpio_mdio_driver =
int gpio_mdio_init(void)
{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
+ if (!np)
+ return -ENODEV;
+ gpio_regs = of_iomap(np, 0);
+ if (!gpio_regs)
+ return -ENODEV;
+
return of_register_platform_driver(&gpio_mdio_driver);
}
+module_init(gpio_mdio_init);
void gpio_mdio_exit(void)
{
of_unregister_platform_driver(&gpio_mdio_driver);
+ if (gpio_regs)
+ iounmap(gpio_regs);
}
-device_initcall(gpio_mdio_init);
-
+module_exit(gpio_mdio_exit);
^ permalink raw reply related
* Re: [PATCH 0/3] Add device-tree aware NDFC driver
From: Thomas Gleixner @ 2007-11-04 20:48 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <47273BF4.80001@ru.mvista.com>
Valentine,
On Tue, 30 Oct 2007, Valentine Barshak wrote:
> Thomas Gleixner wrote:
> > On Mon, 29 Oct 2007, Valentine Barshak wrote:
> >
> > > This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
> > > The code is based on the original NDFC driver by Thomas Gleixner, but
> > > since it's been changed much and has initialization/clean-up completely
> > > reworked it's been put into a separate ndfc_of.c file. This version
> > > supports both separate mtd devices on each chip attached to NDFC banks and
> > > single mtd device spread across identical chips (not using mtdconcat) as
> > > well.
> > > The choice is selected with device tree settings. This has been tested
> > > on PowerPC 440EPx Sequoia board.
> > > Any comments are greatly appreciated.
> >
> > Did I express myself not clear enough in my first reply or is this
> > just a repeated epiphany in my inbox ?
> > You got plenty of comments to your patches, but you decided to ignore
> > them silently.
> >
> > Darn, fix it the right way once and forever and please don't try to
> > tell me another heartrending "why I did it my way" story.
> >
> > This all can be done with a nice series of incremental patches
> > including a fixup to the existing users.
> >
> > We have enough dump and run shit in the kernel already.
> >
> > No thanks,
> >
> > tglx
>
> You know, you're really too tense Thomas. I'm not sure of the reason why
> you're being a complete nerve, but I'm feeling sorry for you.
You have a perception problem. I'm not tense, I'm grumpy.
Rest assured, that my nerves are completely fine despite of the fact
that you try to rack them.
> I'm not saying my approach is the best, but I was hoping for a discussion.
> I've reworked the patches according to the comments to the previous version
> and used my arguments to explain why I don't see much reason to mess with the
> code we currently have and added a separate _of version.
This is the exact point. You were asked to fix up the existing driver
instead of replacing it and to do it with a series of incremental
patches. You copied the old code anyway and modified it, so we want to
have this documented in the history. This is not my obsession, it's
common kernel coding practise. The fact that you do not see much
reason to do it does not change this at all.
> I'm sure you'd find some time to do it yourself "the right way once and
> forever" with a "nice series of incremental patches" to fix what we currently
> have (call it a "dump" or anything you like) and even maybe add new device
> tree support.
It might be time for you to try to understand how OSS development
works.
> I'm sorry if for some reason I've made you feel bad.
What do you expect, after you abused my Signed-off-by in a way which
might have tricked David into pulling your code as is? This was
pointed out to you and you did not even bother to apologize.
> This is the last time I disturb you with my e-mail, so please, forget it.
Interesting. I thought you wanted to get the patch in, so you probably
should ask yourself whether it is a good idea _not_ to talk to the
responsible maintainer.
If you gave up on that, it just makes it more obvious that you do not
want to work with the community and just wanted to dump your patch and
move along.
tglx
^ permalink raw reply
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Roel Kluin @ 2007-11-04 17:46 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071104174701.GB10191@lixom.net>
Olof Johansson wrote:
> On Sun, Nov 04, 2007 at 05:53:40PM +0100, Roel Kluin wrote:
>> I think this is how it should be done, but
>> please review: it was not tested.
>
> Hi,
>
> Thanks for the bug report. The mdio driver needs a set of other cleanups
> as well. I have a more comprehensive patch that I'll post tomorrow after
> I have a chance to test them.
Ok, that's fine with me,
Roel
^ permalink raw reply
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Roel Kluin @ 2007-11-04 17:44 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20071104171814.GI9695@localdomain>
Nathan Lynch wrote:
> Hi,
I moved res to the wrong function, that's fixed as well as the unlikely's and
the extra new lines.
Thanks for your quick response. Here is an updated version:
--
Upon errors gpio_regs was not iounmapped, and later priv nor new_bus->irq was
freed. Testing succes of the allocation of new_bus->irq was missing as well.
This patch creates a new function __gpio_mdio_register_bus to allow the
iounmapping after an ioremap.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index dae9f65..af5b241 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -208,68 +208,50 @@ static int gpio_mdio_write(struct mii_bus *bus, int phy_id, int location, u16 va
}
static int gpio_mdio_reset(struct mii_bus *bus)
{
/*nothing here - dunno how to reset it*/
return 0;
}
-
-static int __devinit gpio_mdio_probe(struct of_device *ofdev,
- const struct of_device_id *match)
+static int __devinit __gpio_mdio_register_bus(struct of_device *ofdev,
+ const struct of_device_id *match)
{
struct device *dev = &ofdev->dev;
struct device_node *np = ofdev->node;
- struct device_node *gpio_np;
struct mii_bus *new_bus;
- struct resource res;
struct gpio_priv *priv;
const unsigned int *prop;
- int err = 0;
int i;
- gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
-
- if (!gpio_np)
- return -ENODEV;
-
- err = of_address_to_resource(gpio_np, 0, &res);
- of_node_put(gpio_np);
-
- if (err)
- return -EINVAL;
-
- if (!gpio_regs)
- gpio_regs = ioremap(res.start, 0x100);
-
- if (!gpio_regs)
- return -EPERM;
-
priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
if (priv == NULL)
return -ENOMEM;
new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
if (new_bus == NULL)
- return -ENOMEM;
+ goto free_priv;
new_bus->name = "pasemi gpio mdio bus",
new_bus->read = &gpio_mdio_read,
new_bus->write = &gpio_mdio_write,
new_bus->reset = &gpio_mdio_reset,
prop = of_get_property(np, "reg", NULL);
new_bus->id = *prop;
new_bus->priv = priv;
new_bus->phy_mask = 0;
new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
+ if (new_bus->irq == NULL)
+ goto free_new_bus;
+
for(i = 0; i < PHY_MAX_ADDR; ++i)
new_bus->irq[i] = irq_create_mapping(NULL, 10);
prop = of_get_property(np, "mdc-pin", NULL);
priv->mdc_pin = *prop;
prop = of_get_property(np, "mdio-pin", NULL);
@@ -284,17 +266,54 @@ static int __devinit gpio_mdio_probe(struct of_device *ofdev,
printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
new_bus->name, err);
goto bus_register_fail;
}
return 0;
bus_register_fail:
+ kfree(new_bus->irq);
+free_new_bus:
kfree(new_bus);
+free_priv:
+ kfree(priv);
+
+ return -ENOMEM;
+}
+
+
+static int __devinit gpio_mdio_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *gpio_np;
+ struct resource res;
+ int err;
+
+ gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
+
+ if (!gpio_np)
+ return -ENODEV;
+
+ err = of_address_to_resource(gpio_np, 0, &res);
+ of_node_put(gpio_np);
+
+ if (err)
+ return -EINVAL;
+
+ if (!gpio_regs) {
+ gpio_regs = ioremap(res.start, 0x100);
+ if (unlikely(!gpio_regs))
+ return -EPERM;
+
+ err = __gpio_mdio_register_bus(ofdev, match);
+ if (err < 0)
+ iounmap(gpio_regs);
+ } else
+ err = __gpio_mdio_register_bus(ofdev, match);
return err;
}
static int gpio_mdio_remove(struct of_device *dev)
{
struct mii_bus *bus = dev_get_drvdata(&dev->dev);
^ permalink raw reply related
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Olof Johansson @ 2007-11-04 17:47 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <472DF914.7020601@tiscali.nl>
On Sun, Nov 04, 2007 at 05:53:40PM +0100, Roel Kluin wrote:
> I think this is how it should be done, but
> please review: it was not tested.
Hi,
Thanks for the bug report. The mdio driver needs a set of other cleanups
as well. I have a more comprehensive patch that I'll post tomorrow after
I have a chance to test them.
-Olof
^ permalink raw reply
* Re: [PATCH] Balance alloc/free and ioremap/iounmap in gpio_mdio_probe (powerpc/platforms/pasemi/gpio_mdio.c)
From: Nathan Lynch @ 2007-11-04 17:18 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <472DF914.7020601@tiscali.nl>
Hi,
Roel Kluin wrote:
> I think this is how it should be done, but
> please review: it was not tested.
> --
> Balance alloc/free and ioremap/iounmap
It would be more helpful if your changelog identified the objects
which could be leaked. More comments below.
> -static int __devinit gpio_mdio_probe(struct of_device *ofdev,
> - const struct of_device_id *match)
> +static int __devinit __gpio_mdio_register_bus(struct of_device *ofdev,
> + const struct of_device_id *match)
> {
> struct device *dev = &ofdev->dev;
> struct device_node *np = ofdev->node;
> - struct device_node *gpio_np;
> struct mii_bus *new_bus;
> struct resource res;
> struct gpio_priv *priv;
> const unsigned int *prop;
> - int err = 0;
> int i;
>
> - gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
> -
> - if (!gpio_np)
> - return -ENODEV;
> -
> - err = of_address_to_resource(gpio_np, 0, &res);
> - of_node_put(gpio_np);
> -
> - if (err)
> - return -EINVAL;
> -
> - if (!gpio_regs)
> - gpio_regs = ioremap(res.start, 0x100);
> -
> - if (!gpio_regs)
> - return -EPERM;
> -
> priv = kzalloc(sizeof(struct gpio_priv), GFP_KERNEL);
> - if (priv == NULL)
> + if (unlikely(priv == NULL))
> return -ENOMEM;
Please don't add likely/unlikely to non-hot paths such as this.
> new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
>
> - if (new_bus == NULL)
> - return -ENOMEM;
> + if (unlikely(new_bus == NULL))
> + goto free_priv;
again
>
> new_bus->name = "pasemi gpio mdio bus",
> new_bus->read = &gpio_mdio_read,
> new_bus->write = &gpio_mdio_write,
> new_bus->reset = &gpio_mdio_reset,
>
> prop = of_get_property(np, "reg", NULL);
> new_bus->id = *prop;
> new_bus->priv = priv;
>
> new_bus->phy_mask = 0;
>
> new_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
> + if (unlikely(new_bus->irq == NULL))
> + goto free_new_bus;
> +
again
> for(i = 0; i < PHY_MAX_ADDR; ++i)
> new_bus->irq[i] = irq_create_mapping(NULL, 10);
>
>
> prop = of_get_property(np, "mdc-pin", NULL);
> priv->mdc_pin = *prop;
>
> prop = of_get_property(np, "mdio-pin", NULL);
> priv->mdio_pin = *prop;
>
> new_bus->dev = dev;
> dev_set_drvdata(dev, new_bus);
>
> err = mdiobus_register(new_bus);
>
> - if (0 != err) {
> + if (unlikely(0 != err)) {
again
> printk(KERN_ERR "%s: Cannot register as MDIO bus, err %d\n",
> new_bus->name, err);
> goto bus_register_fail;
> }
>
> return 0;
>
> bus_register_fail:
> + kfree(new_bus->irq);
> +free_new_bus:
> kfree(new_bus);
> +free_priv:
> + kfree(priv);
> +
> + return -ENOMEM;
> +}
> +
> +
> +static int __devinit gpio_mdio_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct device_node *gpio_np;
> + int err;
> +
> + gpio_np = of_find_compatible_node(NULL, "gpio", "1682m-gpio");
> +
> + if (!gpio_np)
> + return -ENODEV;
> +
> + err = of_address_to_resource(gpio_np, 0, &res);
Hmm, where is "res" defined?
> + of_node_put(gpio_np);
> +
> + if (err)
> + return -EINVAL;
> +
> + if (!gpio_regs) {
> +
Unneeded newline
> + gpio_regs = ioremap(res.start, 0x100);
> + if (unlikely(!gpio_regs))
> + return -EPERM;
> +
> + err = __gpio_mdio_register_bus(ofdev, match);
> + if (err < 0)
> + iounmap(gpio_regs);
> + } else
> + err = __gpio_mdio_register_bus(ofdev, match);
>
> return err;
> +
again
> }
>
>
> static int gpio_mdio_remove(struct of_device *dev)
> {
> struct mii_bus *bus = dev_get_drvdata(&dev->dev);
>
> mdiobus_unregister(bus);
>
^ 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