[U-Boot] smc911x runtime detection (was: TI: OMAP3: Overo Tobi ethernet support)

[Ben Warren]

Steve,
Please keep list C-C'd,

On Sat, Sep 26, 2009 at 12:13 PM, Steve Sakoman <sakoman at gmail.com> wrote:

> On Sat, Sep 26, 2009 at 9:02 AM, Ben Warren <biggerbadderben at gmail.com>
> wrote:
> > Hi Olof,
> > On Sat, Sep 26, 2009 at 8:53 AM, Olof Johansson <olof at lixom.net> wrote:
> >>
> >> On Sep 26, 2009, at 1:13 AM, Dirk Behme wrote:
> >>
> >>> Olof Johansson wrote:
> >>>>
> >>>> Add setup for ethernet on Tobi, allowing kernel/ramdisk to be loaded
> >>>> over tftp.
> >>>> Based on the omap3 evm code. I added a new highlevel define for Tobi
> >>>> to avoid having it dependent on CMD_NET (which would seem backward in
> >>>> this case).
> >>>
> >>> First: This is only a request for comment for possible future
> >>> improvement. It doesn't ask for any changes in this patch or is any
> nack.
> >>> Now to the content ;)
> >>>
> >>> It seems that Steve found a way for runtime detection of smc911x making
> >>> CONFIG_OMAP3_OVERO_TOBI more or less obsolete (from [1]) :
> >>
> >> Looks like a good idea. I guess the risk is if there's ever another
> >> carrier board with something on the same chip select that happens to
> return
> >> something at that address, thus causing false detection. Is that a valid
> >> concern?
> >>
> > It is a good idea in principle, but just reading and expecting
> *something*
> > is a fatal flaw.  I don't know about these ones in particular, but
> > memory-mapped chips often have ID registers that are RO and have
> > well-documented contents.  If somebody can find something like that here,
> > let's do it.
>
> Agreed, I didn't have a spec at hand to investigate this, so that's
> why I didn't think that this was a good patch for all systems with
> smc911x.  I know it to work on Overo because reads to non-existent
> GPMC locations give all ones (hence the test for -1).
>
> I would definitely prefer a register with known contents.
>
> There was a question as to whether the code returned the proper value.
>  Returning a 0 from this routine when no chip is found results in a
> reasonable error message:
>
> Net:  No ethernet found.
>
> Yes, returning 0 is the correct value.  The undocumented API is that
Ethernet initialize() functions return the number of interfaces added, or -1
on error.  I wouldn't consider this an error condition.

regards,
Ben