From: Grant Likely <hidden> Date: 2010-07-26 22:04:59
of_node_to_nid() is only relevant in a few architectures. Don't force
everyone to implement it anyway. This patch also adds asm-generic/of.h
which will be used to contain other overrideable symbols.
Signed-off-by: Grant Likely <redacted>
---
Changes in v3: don't use asm-generic, just keep macros in of.h
Changes in v2: address comments from sfr, add asm-generic/of.h
arch/microblaze/include/asm/topology.h | 10 ----------
arch/powerpc/include/asm/prom.h | 5 +++++
arch/powerpc/include/asm/topology.h | 7 -------
arch/sparc/include/asm/prom.h | 1 +
include/linux/of.h | 5 +++++
5 files changed, 11 insertions(+), 17 deletions(-)
From: Grant Likely <hidden> Date: 2010-07-26 22:06:20
On Mon, Jul 26, 2010 at 4:04 PM, Grant Likely [off-list ref] w=
rote:
of_node_to_nid() is only relevant in a few architectures. =A0Don't force
everyone to implement it anyway. =A0This patch also adds asm-generic/of.h
which will be used to contain other overrideable symbols.
Signed-off-by: Grant Likely <redacted>
Oops. The patch subject I will change before mergine.
g.
=A0/* Get the MAC address */
=A0extern const void *of_get_mac_address(struct device_node *np);
+#ifdef CONFIG_NUMA
+extern int of_node_to_nid(struct device_node *device);
+#define of_node_to_nid of_node_to_nid
+#endif
+
=A0/**
=A0* of_irq_map_pci - Resolve the interrupt for a PCI device
=A0* @pdev: =A0 =A0 =A0the device whose interrupt is to be resolved
From: Sam Ravnborg <hidden> Date: 2010-07-26 22:26:30
On Mon, Jul 26, 2010 at 04:04:55PM -0600, Grant Likely wrote:
of_node_to_nid() is only relevant in a few architectures. Don't force
everyone to implement it anyway. This patch also adds asm-generic/of.h
which will be used to contain other overrideable symbols.
Signed-off-by: Grant Likely <redacted>
---
Changes in v3: don't use asm-generic, just keep macros in of.h
Changes in v2: address comments from sfr, add asm-generic/of.h
The use of asm-generic makes perfect sense.
This is how we usually deal with arch specific stuff.
With v3 of your patch we have a different result depending
on if we do:
#include <linux/of.h>
or we do:
#include <asm/prom.h>
This is undesireable.
I suggest to go back to v2 of your patch where you use asm-generic/of.h.
linux/of.h shall include asm/of.h
Then all archs shall have a of.h that may
include the asm-generic variant.
One patch to introduce of.h all over.
And a second patch to do the of_node_to_nid stuff would be appropriate.
@@ -103,6 +103,11 @@ struct device_node *of_find_next_cache_node(struct device_node *np);/* Get the MAC address */externconstvoid*of_get_mac_address(structdevice_node*np);
This shall go in asm/of.h
+#ifdef CONFIG_NUMA
+extern int of_node_to_nid(struct device_node *device);
+#define of_node_to_nid of_node_to_nid
This define is used to tell asm-generic/of.h that the arch has
a local definition - OK.
+#endif
+
/**
* of_irq_map_pci - Resolve the interrupt for a PCI device
* @pdev: the device whose interrupt is to be resolved
From: Grant Likely <hidden> Date: 2010-07-26 22:42:42
On Mon, Jul 26, 2010 at 4:26 PM, Sam Ravnborg [off-list ref] wrote:
On Mon, Jul 26, 2010 at 04:04:55PM -0600, Grant Likely wrote:
quoted
of_node_to_nid() is only relevant in a few architectures. =A0Don't force
everyone to implement it anyway. =A0This patch also adds asm-generic/of.=
h
quoted
which will be used to contain other overrideable symbols.
Signed-off-by: Grant Likely <redacted>
---
Changes in v3: don't use asm-generic, just keep macros in of.h
Changes in v2: address comments from sfr, add asm-generic/of.h
The use of asm-generic makes perfect sense.
This is how we usually deal with arch specific stuff.
With v3 of your patch we have a different result depending
on if we do:
#include <linux/of.h>
or we do:
#include <asm/prom.h>
This is undesireable.
The patch does maintain consistency. Including only asm/prom.h may
mean that of_node_to_nid is undefined, but it will never result in a
different definition. linux/of.h includes asm/prom.h before doing the
#ifdef test.
I suggest to go back to v2 of your patch where you use asm-generic/of.h.
Stephen suggested dropping asm-generic/of.h. I'm happy to do it either way=
.
linux/of.h shall include asm/of.h
Then all archs shall have a of.h that may
include the asm-generic variant.
One patch to introduce of.h all over.
And a second patch to do the of_node_to_nid stuff would be appropriate.
It protects against some later include file doing a #define
of_node_to_nid and thus resulting in an inconsistent definition. If
some code tries to do this then the preprocessor will complain. This
is the pattern that Stephen suggested.
g.
It protects against some later include file doing a #define
of_node_to_nid and thus resulting in an inconsistent definition. If
some code tries to do this then the preprocessor will complain. This
is the pattern that Stephen suggested.
Also, it would be nice to unravel the "0" vs. "-1" default
inconsistency.
It protects against some later include file doing a #define
of_node_to_nid and thus resulting in an inconsistent definition. =A0If
some code tries to do this then the preprocessor will complain. =A0This
is the pattern that Stephen suggested.
Also, it would be nice to unravel the "0" vs. "-1" default
inconsistency.
Indeed. I looked at it briefly, but it wasn't immediately clear what
the impact would be to switch powerpc over to -1, and it looked to me
like sparc depends on -1 to signify no node association.
g.
Indeed. I looked at it briefly, but it wasn't immediately clear what
the impact would be to switch powerpc over to -1, and it looked to me
like sparc depends on -1 to signify no node association.
Kernel wide, NUMA interfaces tend to take "-1" to mean "any node."
I had looked over the powerpc cases, and besides 1 or 2 strange
locations the powerpc call sites were ready to handle -1.
Indeed. =A0I looked at it briefly, but it wasn't immediately clear what
the impact would be to switch powerpc over to -1, and it looked to me
like sparc depends on -1 to signify no node association.
Kernel wide, NUMA interfaces tend to take "-1" to mean "any node."
I had looked over the powerpc cases, and besides 1 or 2 strange
locations the powerpc call sites were ready to handle -1.
Okay, well let me rework the patch to make -1 the default and let
powerpc override it. A follow-on patch can fix up the powerpc usage
of 0.
g.
I suggest to go back to v2 of your patch where you use asm-generic/of.h.
Stephen suggested dropping asm-generic/of.h. I'm happy to do it either way.
I don't mind adding stuff to asm-generic, but I think in this case it would
be easier to keep this in linux/of.h because there is nothing wrong with
all architectures including it.
Most files in asm-generic are there only for historical reasons, where some
architectures use them but others don't. IMHO we should use the include/linux
headers preferred for new stuff though.
Arnd
From: Sam Ravnborg <hidden> Date: 2010-07-27 16:52:54
On Tue, Jul 27, 2010 at 03:34:01PM +0200, Arnd Bergmann wrote:
On Tuesday 27 July 2010, Grant Likely wrote:
quoted
quoted
I suggest to go back to v2 of your patch where you use asm-generic/of.h.
Stephen suggested dropping asm-generic/of.h. I'm happy to do it either way.
I don't mind adding stuff to asm-generic, but I think in this case it would
be easier to keep this in linux/of.h because there is nothing wrong with
all architectures including it.
Most files in asm-generic are there only for historical reasons, where some
architectures use them but others don't. IMHO we should use the include/linux
headers preferred for new stuff though.
Hi Arnd.
Thanks for this explanation. Obviously my previous post
about asm-generic was wrong (as Grant already indicated).
Sam