Hi Chris, On 6 June 2014 16:35, Chris Packham <judge.pack...@gmail.com> wrote: > Signed-off-by: Chris Packham <judge.pack...@gmail.com> > --- > On 07/06/14 08:48, Simon Glass wrote:> Hi Chris, >> >> On 5 June 2014 21:24, Chris Packham <judge.pack...@gmail.com> wrote: >>> Hi, >>> >>> (Joe, Simon, I'm not sure if this counts as "networking" or "driver >>> model" but figured it was close enough to warrant an Cc). >>> >>> We're looking at a new board design and are planning on using a >>> BCM5718 to provide a couple of Ethernet ports. The chipset is >>> supported in Linux using the tg3.c driver. I was planning on creating >>> an equivalent driver in u-boot using e1000.c as a guide and probably >>> borrowing heavily from the Linux driver. >>> >>> Is anyone else actively looking at Broadcom based chipset/NICs? Any >>> tips as for where to start or pitfalls to expect? >> >> I'm not aware of anything myself, but it sounds like a good idea. If >> you feel able to convert 'eth' over to driver model that would be >> great too. There are only a small number of operations. >> >> Regards, >> Simon > > Yeah it doesn't look as thought it'd be too hard to do 'eth' (or is it > 'netdev'?). I think I'll concentrate on doing the BCM5718 driver the current > way first then have a think about converting 'eth'.
I think it is actually struct eth_device that you need to do, in terms of writing the uclass. Also you can follow the GPIO approach of using CONFIG_DM_ETH to control whether driver model is used for networking (which it would be for any board using your driver). > > In the meantime I spotted a few typos when reading the driver-model docs. Thanks, will add these. > > doc/driver-model/README.txt | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt > index dcecb9a..a5035be 100644 > --- a/doc/driver-model/README.txt > +++ b/doc/driver-model/README.txt > @@ -20,7 +20,7 @@ Terminology > ----------- > > Uclass - a group of devices which operate in the same way. A uclass provides > - a way of accessing invidual devices within the group, but always > + a way of accessing individual devices within the group, but always > using the same interface. For example a GPIO uclass provides > operations for get/set value. An I2C uclass may have 10 I2C ports, > 4 with one driver, and 6 with another. > @@ -120,7 +120,7 @@ What is going on? > ----------------- > > Let's start at the top. The demo command is in common/cmd_demo.c. It does > -the usual command procesing and then: > +the usual command processing and then: > > struct udevice *demo_dev; > > @@ -228,7 +228,7 @@ The data can be interpreted by the drivers however they > like - it is > basically a communication scheme between the board-specific code and > the generic drivers, which are intended to work on any board. > > -Drivers can acceess their data via dev->info->platdata. Here is > +Drivers can access their data via dev->info->platdata. Here is > the declaration for the platform data, which would normally appear > in the board file. > > @@ -272,7 +272,7 @@ method reads the information out of the device tree and > puts it in > dev->platdata. Then the probe method is called to set up the device. > > Note that both methods are optional. If you provide an ofdata_to_platdata > -method then it wlil be called first (after bind). If you provide a probe > +method then it will be called first (after bind). If you provide a probe > method it will be called next. > > If you don't want to have the platdata automatically allocated then you > @@ -310,7 +310,7 @@ Changes since v1 > For the record, this implementation uses a very similar approach to the > original patches, but makes at least the following changes: > > -- Tried to agressively remove boilerplate, so that for most drivers there > +- Tried to aggressively remove boilerplate, so that for most drivers there > is little or no 'driver model' code to write. > - Moved some data from code into data structure - e.g. store a pointer to > the driver operations structure in the driver, rather than passing it > -- > 2.0.0.153.g79dcccc > Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot