From owner-freebsd-current@FreeBSD.ORG Thu Sep 24 20:39:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E3F31065670 for ; Thu, 24 Sep 2009 20:39:23 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from jacques.telenet-ops.be (jacques.telenet-ops.be [195.130.132.50]) by mx1.freebsd.org (Postfix) with ESMTP id EF9AF8FC31 for ; Thu, 24 Sep 2009 20:39:22 +0000 (UTC) Received: from triton.sigsegv.be ([213.119.96.179]) by jacques.telenet-ops.be with bizsmtp id kkfM1c0033sCccd0JkfMSo; Thu, 24 Sep 2009 22:39:21 +0200 Received: from nereid (nereid.neptune.sigsegv.be [IPv6:2001:470:c8f4:0:200:ff:fe00:8]) by triton.sigsegv.be (Postfix) with SMTP id 65C481C1E1; Fri, 25 Sep 2009 00:40:30 +0200 (CEST) Received: by nereid (sSMTP sendmail emulation); Thu, 24 Sep 2009 22:39:20 +0200 Date: Thu, 24 Sep 2009 22:39:18 +0200 From: Kristof Provost To: Pyun YongHyeon Message-ID: <20090924203918.GI19069@nereid> References: <20090922211012.GE19069@nereid> <20090922235350.GB1520@michelle.cdnetworks.com> <20090923184149.GF19069@nereid> <20090923202448.GD1099@michelle.cdnetworks.com> <20090923205535.GG19069@nereid> <20090923214011.GE1099@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090923214011.GE1099@michelle.cdnetworks.com> X-PGP-Fingerprint: 6B6E 5EED 8ECF FAE7 1F61 7458 5046 7D0E 11B0 0EE8 User-Agent: Mutt/1.5.14 (2007-03-31) Cc: current@freebsd.org Subject: Re: mge, mii/e1000phy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 20:39:23 -0000 On 2009-09-23 14:40:11 (-0700), Pyun YongHyeon wrote: > Oh, this question may not be related with your link issue. I wanted > to know why mge(4) had to check media type in its ioctl handler. > The advertised capability has nothing to do with link partner's > capability. The advertised capability is used in auto-negotiation > process and the PHY will choose the highest common denominator > capability. So if we want to disable 1000baseT/half-duplex for > whatever reason, it can be achieved by not advertising 1000baseT/ > half-duplex capability to mii layer. > I think it's advertising the following: 10baseT 10baseT-FDX 100baseTX 100baseTX-FDX 1000baseT 1000baseT-FDX auto In any case, the values used during mii_phy_add_media are sc->mii_capabilities 0x7949 and sc->mii_extcapabilities 0x3000. Regards, Kristof