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