[PATCH 06/18] Make ft_node_add() accept and return NULL.

[PATCH 06/18] Make ft_node_add() accept and return NULL.

[Scott Wood]

Currently, if ft_node_add() is passed NULL it will allocate an entry for
it and return a non-NULL phandle.  This patch makes it simply pass the
NULL through.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
 arch/powerpc/boot/flatdevtree.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/flatdevtree.c b/arch/powerpc/boot/flatdevtree.c
index 78e179f..55b6699 100644
--- a/arch/powerpc/boot/flatdevtree.c
+++ b/arch/powerpc/boot/flatdevtree.c
@@ -40,6 +40,9 @@ static void *ft_node_add(struct ft_cxt *
 {
 	unsigned int i;
 
+	if (!node)
+		return NULL;
+
 	for (i = 1; i < cxt->nodes_used; i++)	/* already there? */
 		if (cxt->node_tbl[i] == node)
 			return (void *)i;
-- 
1.4.4

Re: [PATCH 06/18] Make ft_node_add() accept and return NULL.

[Segher Boessenkool]

> Currently, if ft_node_add() is passed NULL it will allocate an  
> entry for
> it and return a non-NULL phandle.  This patch makes it simply pass the
> NULL through.

Hrm, is this a good thing?  Shouldn't you just BUG_ON()
instead?


Segher

Re: [PATCH 06/18] Make ft_node_add() accept and return NULL.

[Scott Wood]

Segher Boessenkool wrote:
>> Currently, if ft_node_add() is passed NULL it will allocate an  entry for
>> it and return a non-NULL phandle.  This patch makes it simply pass the
>> NULL through.
> 
> 
> Hrm, is this a good thing?  Shouldn't you just BUG_ON()
> instead?

There are times where NULL is normal -- such as at the end of an 
iteration to find every instance of a certain type of node, or to follow 
parentage to the root node.  Having ft_node_add() pass the NULL through 
keeps it from being a special case in all of the wrapper code that turns 
the internal node into a phandle before returning.

-Scott

Re: [PATCH 06/18] Make ft_node_add() accept and return NULL.

[Segher Boessenkool]

>>> Currently, if ft_node_add() is passed NULL it will allocate an   
>>> entry for
>>> it and return a non-NULL phandle.  This patch makes it simply  
>>> pass the
>>> NULL through.
>> Hrm, is this a good thing?  Shouldn't you just BUG_ON()
>> instead?
>
> There are times where NULL is normal -- such as at the end of an  
> iteration to find every instance of a certain type of node, or to  
> follow parentage to the root node.  Having ft_node_add() pass the  
> NULL through keeps it from being a special case in all of the  
> wrapper code that turns the internal node into a phandle before  
> returning.

But doesn't ft_add_node() add a node to the tree?  If so,
a NULL is most likely a program error. If not, some name
change is in order /me thinks ;-)


Segher

Re: [PATCH 06/18] Make ft_node_add() accept and return NULL.

[Scott Wood]

Segher Boessenkool wrote:
> But doesn't ft_add_node() add a node to the tree?  If so,
> a NULL is most likely a program error. If not, some name
> change is in order /me thinks ;-)

No, it adds the node to the phandle->internal pointer lookup table (or 
returns the existing phandle if it's already there).  And yes, it could 
use a better name -- how about ft_node_to_phandle()?

-Scott

Re: [PATCH 06/18] Make ft_node_add() accept and return NULL.

[Segher Boessenkool]

>> But doesn't ft_add_node() add a node to the tree?  If so,
>> a NULL is most likely a program error. If not, some name
>> change is in order /me thinks ;-)
>
> No, it adds the node to the phandle->internal pointer lookup table  
> (or returns the existing phandle if it's already there).  And yes,  
> it could use a better name -- how about ft_node_to_phandle()?

Well a node _is_ a phandle (at some abstraction level).  How
about ft_node_get()?


Segher