[U-Boot] [PATCH] docs: driver-model: Fix spelling

[Simon Glass]

Hi Chris,

On 6 June 2014 16:35, Chris Packham <judge.packham at gmail.com> wrote:
> Signed-off-by: Chris Packham <judge.packham at gmail.com>
> ---
> On 07/06/14 08:48, Simon Glass wrote:> Hi Chris,
>>
>> On 5 June 2014 21:24, Chris Packham <judge.packham at 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