Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

  Dan Malek wrote:

>
> Dean Matsen wrote:
>
>> Yes, I see we have no pullup on that line. We do dedicated HVAC
>> applications, so we
>> don't need to do this search.
>
>
> But.......the hardware is broken.  The MDIO is supposed to be
> an open-drain with a pullup.  I guess you may be lucky the
> ends of the connection are driving the line proplerly, but it
> could be luck that will run out someday.
>
>
>     -- Dan

Actually, it turns out that this is not quite true.  The MDIO line
is classified as an I/O line (on the same page where other lines
are classified as open drain).  There are tons of application notes from
Motorola and Intel and none of them show a pullup.  I think
this issue has more to do with talking to a device at the wrong address
and  having the line float only in that case.

The actual problem I have is that the kernel panics before it even gets
to address 1 (which is where my PHY chip is in the first place).  This
happens whenever it reads a value other than FFFF from the first word
of the ID.  I see now that my first patch adds detection for the value
0000, but other people may have varying results (especially if they
follow the app notes and don't have a pullup, like we do).

I think the search should be made smarter (especially, keep going to
the next address until it has gone through ALL address w/o finding a
valid ID).  The kernel could still panic if it can't find any PHY chip,
but not the first time it reads the floating line and can't find the
answer in its table.  The odds of reading a valid PHY ID from the
floating line is phenominally low.  I'd submit a proposed patch for
this, but it doesn't sound like anyone else thinks this is important
enough to warrant a change.

Those maintaining the official kernel repositories should consider whether
or not it's friendly to require the addition of a pullup resistor just so
the automatic PHY search will work.  Unless the pullup is required for
non-search applications (which I assert it isn't), then I think the code
should be fixed, not the hardware.

Regards,

Dean


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/