[U-Boot] [PATCH] Add information about return values of xxx_eth_register() in documentation

[U-Boot] [PATCH] Add information about return values of xxx_eth_register() in documentation

[Ben Warren]

As discussed on mailing list, <0 indicates failure, >=0 indicates number
of interfaces found.

Also added blurb about private data

Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
---
 doc/README.drivers.eth |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth
index 7f21909..e06d3ad 100644
--- a/doc/README.drivers.eth
+++ b/doc/README.drivers.eth
@@ -25,9 +25,9 @@ system handling, but ultimately they will call the driver-specific register
 function which in turn takes care of initializing that particular instance.
 
 Keep in mind that you should code the driver to avoid storing state in global
-data as someone might want to hook up two of the same devices to one board.  If
-the state is maintained as global data, it makes using both of those devices
-impossible.
+data as someone might want to hook up two of the same devices to one board.
+Any such information that is specific to an interface should be stored in a
+private, driver-defined data structure and pointed to by eth->priv (see below).
 
 So the call graph at this stage would look something like:
 board_init()
@@ -77,15 +77,20 @@ int ape_register(bd_t *bis, int iobase)
 	miiphy_register(dev->name, ape_mii_read, ape_mii_write);
 #endif
 
-	return 0;
+	return 1;
 }
 
 The exact arguments needed to initialize your device are up to you.  If you
 need to pass more/less arguments, that's fine.  You should also add the
-prototype for your new register function to include/netdev.h.  You might notice
-that many drivers seem to use xxx_initialize() rather than xxx_register().
-This is the old naming convention and should be avoided as it causes confusion
-with the driver-specific init function.
+prototype for your new register function to include/netdev.h.
+
+The return value for this function should be as follows:
+< 0 - failure (hardware failure, not probe failure)
+>=0 - number of interfaces detected
+
+You might notice that many drivers seem to use xxx_initialize() rather than 
+xxx_register().  This is the old naming convention and should be avoided as it
+causes confusion with the driver-specific init function.
 
 Other than locating the MAC address in dedicated hardware storage, you should
 not touch the hardware in anyway.  That step is handled in the driver-specific
-- 
1.6.0.4

[U-Boot] [PATCH] Add information about return values of xxx_eth_register() in documentation

[Ben Warren]

Mike,

Ben Warren wrote:
> As discussed on mailing list, <0 indicates failure, >=0 indicates number
> of interfaces found.
>
> Also added blurb about private data
>   
I'm going to go ahead and put this in the net repo.  If you don't like 
it, let me know and we'll back it out.

regards,
Ben

[U-Boot] [PATCH] Add information about return values of xxx_eth_register() in documentation

[Mike Frysinger]

On Monday 05 October 2009 03:09:23 Ben Warren wrote:
> Ben Warren wrote:
> > As discussed on mailing list, <0 indicates failure, >=0 indicates number
> > of interfaces found.
> >
> > Also added blurb about private data
> 
> I'm going to go ahead and put this in the net repo.  If you don't like
> it, let me know and we'll back it out.

makes sense to me, thanks
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091005/f273f494/attachment.pgp