From owner-freebsd-net@FreeBSD.ORG  Tue Jul 29 20:20:03 2008
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 67AD81065678
	for <freebsd-net@hub.freebsd.org>; Tue, 29 Jul 2008 20:20:03 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 4B4B28FC1C
	for <freebsd-net@hub.freebsd.org>; Tue, 29 Jul 2008 20:20:03 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6TKK371041852
	for <freebsd-net@freefall.freebsd.org>; Tue, 29 Jul 2008 20:20:03 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6TKK39c041851;
	Tue, 29 Jul 2008 20:20:03 GMT (envelope-from gnats)
Date: Tue, 29 Jul 2008 20:20:03 GMT
Message-Id: <200807292020.m6TKK39c041851@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: John Baldwin <jhb@freebsd.org>
Cc: 
Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D
	autonegotiate failure
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: John Baldwin <jhb@freebsd.org>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jul 2008 20:20:03 -0000

The following reply was made to PR kern/112179; it has been noted by GNATS.

From: John Baldwin <jhb@freebsd.org>
To: bug-followup@freebsd.org, mark@hydrus.org.uk
Cc: phk@freebsd.org
Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D autonegotiate failure
Date: Tue, 29 Jul 2008 11:56:38 -0400

 How about the patch below.  This makes the driver match the behavior of the 
 Linux driver (and also fixes a harmless weirdness phk@ introduced.. I think 
 because he thought SIS_SETBIT was CSR_WRITE_4 rather than a RMW op).
 
 Index: if_sis.c
 ===================================================================
 --- if_sis.c	(revision 180877)
 +++ if_sis.c	(working copy)
 @@ -1904,14 +1904,15 @@
  	if (sc->sis_type == SIS_TYPE_83815 && sc->sis_srr <= NS_SRR_15D) {
  		CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
  		CSR_WRITE_4(sc, NS_PHY_CR, 0x189C);
 -		if (sc->sis_srr == NS_SRR_15C) {
 -			/* set val for c2 */
 -			CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000);
 +		/* set val for c2 */
 +		CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000);
 +		if (sc->sis_srr <= NS_SRR_15C)
  			/* load/kill c2 */
  			CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040);
 -			/* rais SD off, from 4 to c */
 -			CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C);
 -		}
 +		else
 +			SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x1000);
 +		/* rais SD off, from 4 to c */
 +		CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C);
  		CSR_WRITE_4(sc, NS_PHY_PAGE, 0);
  	}
  
 @@ -2011,12 +2012,11 @@
  		CSR_WRITE_4(sc, NS_PHY_DSPCFG, reg | 0x1000);
  		DELAY(100000);
  		reg = CSR_READ_4(sc, NS_PHY_TDATA) & 0xff;
 -		if ((reg & 0x0080) == 0 || (reg > 0xd8 && reg <= 0xff)) {
 +		if ((reg & 0x0080) == 0 || (reg >= 0xd8 && reg <= 0xff)) {
  			device_printf(sc->sis_dev,
  			    "Applying short cable fix (reg=%x)\n", reg);
  			CSR_WRITE_4(sc, NS_PHY_TDATA, 0x00e8);
 -			reg = CSR_READ_4(sc, NS_PHY_DSPCFG);
 -			SIS_SETBIT(sc, NS_PHY_DSPCFG, reg | 0x20);
 +			SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x20);
  		}
  		CSR_WRITE_4(sc, NS_PHY_PAGE, 0);
  	}
 
 One other thing the Linux driver does differently than the FreeBSD driver is 
 that it 1) doesn't set 0x1000 in DSPCFG when locking the coeffecient (since 
 it sets it earlier) and 2), it locks the coefficient every time link is 
 established and unlocks it when link is lost.  Doing 2) would require pushing 
 some logic down into the phy driver I think.
 
 -- 
 John Baldwin