[U-Boot] [PATCH 2/2] document network driver framework

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:04 Sat 18 Jul     , Mike Frysinger wrote:
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
> Ben: some things to note:
> 	- i adopted Jean's proposed naming scheme in the CONFIG section
> 	- i deprecated calling the driver-specific entry point
> 	  "xxx_initialization()" in favor of "xxx_register()" because the
> 	  former is way too confusing with everyone also having "xxx_init()"
> 
>  doc/README.drivers.eth |  199 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 199 insertions(+), 0 deletions(-)
>  create mode 100644 doc/README.drivers.eth
> 
> diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth
> new file mode 100644
> index 0000000..00b4eb1
> --- /dev/null
> +++ b/doc/README.drivers.eth
> @@ -0,0 +1,199 @@
> +-----------------------
> + Ethernet Driver Guide
> +-----------------------
> +
> +The networking stack in Das U-Boot is designed for multiple network devices
> +to be easily added and controlled at runtime.  This guide is meant for people
> +who wish to review the net driver stack with an eye towards implementing your
> +own ethernet device driver.  Here we will describe a new pseudo 'APE' driver.
> +
> +----------------
> + CONFIG Options
> +----------------
> +
> +The common config defines your device should respect (if applicable):
> +	CONFIG_MII  - configure in MII mode
> +	CONFIG_RMII - configure in RMII mode
how will you deal you on your board you have a MII and a RMII chip used
I think need to be configure via drivers specifc CONFIG if your driver can not
deal with 2 different instance config or via driver init param
> +
> +	CONFIG_CMD_MII - support the MII command
> +
> +If you want to add config options specific to your driver, you should use the
> +naming convention:
> +	CONFIG_NET_<DRIVERNAME>_<OPTION>
> +For example, if the APE driver could operate in either 16bit or 32bit mode,
> +there would probably be the option:
> +	CONFIG_NET_APE_32BIT - operate in 32bit mode rather than 16bit default
> +
> +And to control whether your driver is even enabled, you should use:
> +	CONFIG_SYS_NET_<DRIVERNAME>
In my proposition CONFIG_SYS_ will be not use for driver enabling but for
hardware specific information
> +So the APE driver would look like:
> +	CONFIG_SYS_NET_APE
so it will be
	CONFIG_NET_APE
> +
> +------------------
> + Driver Functions
> +------------------
> +
> +All functions you will be implementing in this document have the return value
> +meaning of 0 for success and non-zero for failure.
> +
<snip>
> +----------------
> + CONFIG_CMD_MII
> +----------------
> +
> +If your device supports banging arbitrary values on the MII bus (pretty much
> +every device does), you should add support for the mii command.  Doing so is
> +fairly trivial and makes debugging mii issues a lot easier at runtime.
> +
> +After you have called eth_register() in your driver's register function, add
> +a call to miiphy_register() like so:
> +#ifdef CONFIG_CMD_MII
> +	miiphy_register(dev->name, mii_read, mii_write);
> +#endif
> +
> +And then define the mii_read and mii_write functions if you haven't already.
> +Their syntax is straightforward:
> +	int mii_read(char *devname, uchar addr, uchar reg, ushort *val);
> +	int mii_write(char *devname, uchar addr, uchar reg, ushort val);
> +
> +The read function should read the register 'reg' from the phy at address 'addr'
> +and store the result in the pointer 'val'.  The implementation for the write
> +function should logically follow.
we will rewrite this api when we will push the phylib

Best Regards,
J.