From owner-cvs-all  Sun Aug  2 18:33:18 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id SAA08986
          for cvs-all-outgoing; Sun, 2 Aug 1998 18:33:18 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA08978;
          Sun, 2 Aug 1998 18:33:13 -0700 (PDT)
          (envelope-from wpaul@FreeBSD.org)
From: Bill Paul <wpaul@FreeBSD.ORG>
Received: (from wpaul@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id SAA13525;
	Sun, 2 Aug 1998 18:33:12 -0700 (PDT)
Date: Sun, 2 Aug 1998 18:33:12 -0700 (PDT)
Message-Id: <199808030133.SAA13525@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: cvs commit: src/sys/pci if_tl.c if_tlreg.h
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

wpaul       1998/08/02 18:33:12 PDT

  Modified files:
    sys/pci              if_tl.c if_tlreg.h 
  Log:
  Updates for the ThunderLAN driver:
  
  - probe for PHYs by checking the BMSR (phy status) register instead
    of the vendor ID register.
  
  - fix the autonegotiation routine so that it figures out the autonegotiated
    modes correctly.
  
  - add tweaks to support the Olicom OC-2326 now that I've actually had
    a chance to test one
  
  	o Olicom appears to encode the ethernet address in the EEPROM
  	  in 16-bit chunks in network byte order. If we detect an
  	  Olicom card (based on the PCI vendor ID), byte-swap the station
  	  address accordingly.
  
  	  XXX The Linux driver does not do this. I find this odd since
  	  the README from the Linux driver indicates that patches to
  	  support the Olicom cards came from somebody at Olicom; you'd
  	  think if anyone would get that right, it'd be them. Regardless,
  	  I accepted the word of the disgnoatic program that came bundled
  	  with the card as gospel and fixed the attach routine to make
  	  the station address match what it says.
  
  	o The version of the 2326 card that I got for testing is a
  	  strange beast: the card does not look like the picture on
  	  the box in which it was packed. For one thing, the picture
  	  shows what looks like an external NS 83840A PHY, but the
  	  actual card doesn't have one. The card has a TNETE100APCM
  	  chip, which appears to have not only the usual internal
  	  tlan 10Mbps PHY at MII address 32, but also a 10/100 PHY
  	  at MII address 0. Curiously, this PHY's vendor and device ID
  	  registers always return 0x0000. I suspect that this is
  	  a mutant version of the ThunderLAN chip with 100Mbps support.
  	  This combination behaves a little strangely and required the
  	  following changes:
  
  		- The internal PHY has to be enabled in tl_softreset().
  		- The internal PHY doesn't seem to come to life after
  		  detecting the 100Mbps PHY unless it's reset twice.
  		- If you want to use 100Mbps modes, you have to isolate
  		  the internal PHY.
  		- If you want to use 10Mbps modes, you have to un-isolate
  		  the internal PHY.
  
  	The latter two changes are handled at the end of tl_init(): if
  	the PHY vendor ID is 0x0000 (which should not be possible if we
  	have a real external PHY), then tl_init() forces the internal
  	PHY's BMCR register to the proper values.
  
  Revision  Changes    Path
  1.13      +135 -31   src/sys/pci/if_tl.c
  1.5       +1 -1      src/sys/pci/if_tlreg.h