On Thu, 25 May 2000, Jason R Thorpe wrote:

> Is that really true about the `first' PHY being at offset 1?

  Yep.  In any case, the code should not assume that PHYs begin at 0
unless they must do so, which is not currently the case.  In earlier
versions of the code it caused a null pointer dereference due to the PHY
data structure being only partially set up and later code not being
paranoid enough.

  How about allowing mii_attach to be called with both phyloc and offloc
specified?  This should allow the driver to DTRT.

> The DM9102A has both HomePNA and 10/100 interfaces.  You select the
> HomePNA PHY by clearing OPMODE_PS, and the 10/100 interface by setting
> OPMODE_PS (on older DM9102 chips, you must always set OPMODE_PS).
> 
> So, it's quite likely that some of those bogus GPR bits are actually
> a description of the HomePNA portion, and that the HomePNA PHY is
> actually offset 0.

  Sounds like a good theory.  I guess the GPR data should only be skipped
on major version < 3 (the manual for the 9102A says it has major version
3.  I guess 2 was never used).

> I planned on handling this board by punting on the ISV SROM parsing
> (since there is no GPIO stuff to deal with, and you always have MII),
> and special casing the DM9102A HomePNA PHY.

  The docs say that it wants the usual GPIO reset sequence anyway.

>  >    Also, the receive process does not want to stop in tlp_idle while
>  >  waiting for a packet.  This doesn't seem to be a big problem since
>  >  switching between auto (at 100baseTX) and 10baseT still works while it is
>  >  running (but between 10baseT and 100baseTX does not).
> 
> Hm.  Interesting.  I wonder why the halt fails.  That's kind of annoying,
> since you're supposed to halt the receive process to load a new receive
> filter.  Oh well.  I guess I could suppress the warning on the DM9102.

  I guess the filter should be set to reinit instead of idle, which should
take care of that.  Maybe the same thing should be done for the media
switch.  The docs do say that the receive process only stops when there is
no receive buffer available.

  Note that the status bits on the 9102 are different from the standard
tulip status bits, which is why the current code reports CHECK (it is
actually WAITING).  The FreeBSD code seems to only check that the transmit
OR receive processes stopped, which is why it works (the transmit process
does stop).  Probably a thinko in the FreeBSD code.  Also, if you happen
to receive something while trying to get it to stop, it will idle
correctly. 

> Just doing S/F mode at the beginning seems reasonable, esp. since we
> can't use MRL/MRM on that chip.

  Ok. 


Matthew Orgass
darkstar@pgh.net