From owner-freebsd-current@FreeBSD.ORG Wed Sep 23 21:40:59 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 826AD106568D for ; Wed, 23 Sep 2009 21:40:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 354AB8FC16 for ; Wed, 23 Sep 2009 21:40:58 +0000 (UTC) Received: by qyk6 with SMTP id 6so300061qyk.3 for ; Wed, 23 Sep 2009 14:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=R2JKir6lMgbiEuKhEXIIRNlAF+n81W8+jxPc00OMFC0=; b=GHd0NJfiNcHCbDEDU/KeFNrZlKXGmLF7RbhYy6KoKSt1gw4GPVr0MgIWUIqzqupVBo QIi5zeqaPXrvycAX2fN+nN4oX6XJNvjSlOBovwQ5+2jiX/swVQexu723iyOlddne4VfF F7TEKLkz/rwtmhdjmLghY4aqIToHhbvj9LGQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tPvFZVlK0d8rq8dkjLKmHVkXTN8n3m93U3mkJimMlsbP72vPt2oUD8W8s9tYY1vcQB NJ4QPdchGztiJo/sU7mtFP5J79aAAT3x+y1cNgdw1+3X4WFur78R3x8Jq0Es7zFonW3z swa6gVLiaSSAsLnFqedJsB/rj5bpclZsQD1TE= Received: by 10.224.109.141 with SMTP id j13mr2510088qap.84.1253742058516; Wed, 23 Sep 2009 14:40:58 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 2sm5382qwi.30.2009.09.23.14.40.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Sep 2009 14:40:57 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 23 Sep 2009 14:40:11 -0700 From: Pyun YongHyeon Date: Wed, 23 Sep 2009 14:40:11 -0700 To: Kristof Provost Message-ID: <20090923214011.GE1099@michelle.cdnetworks.com> References: <20090922211012.GE19069@nereid> <20090922235350.GB1520@michelle.cdnetworks.com> <20090923184149.GF19069@nereid> <20090923202448.GD1099@michelle.cdnetworks.com> <20090923205535.GG19069@nereid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090923205535.GG19069@nereid> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: mge, mii/e1000phy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 21:40:59 -0000 On Wed, Sep 23, 2009 at 10:55:35PM +0200, Kristof Provost wrote: > On 2009-09-23 13:24:48 (-0700), Pyun YongHyeon wrote: > > I'm pretty sure the device id for 88E1116 PHY is 0x21. Do you see > > printed model number 88E1118 on your hardware? If so I have no idea > > why Marvell use the same device id. Do you have access to 88E1118 > > HY data sheet? > > > I've just double checked. The documentation from TS claims it's an > 88E1118 and that's what I see on the chip itself as well. > I don't have access to the data sheet, that would make this exercise far > too easy. > > > I wanted to know advertised PHY capabilities as mge(4) explicitly > > disabled 1000baseT/half-duplex mode in driver layer. But MV88F5182 > > data sheet said it supports 1000baseT/half-duplex mode. > > > I'll try to find out tomorrow. I'm not sure if it'll matter though, as > the switch I'm using right now is a 10/100 model. > 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'm not author of mge(4) so I'm not familiar with mge(4). But it > > > > seems that mge(4) lacks link state change handler. Normally NICs > > > > are required to reprogram MAC to match resolved speed/duplex/ > > > > flow-control of link when it know it established a valid link which > > > > is notified from mii(4). > > > > > > > If that's the case I'd expect the driver not to work on my Sheevaplug > > > either. The only difference I see is the PHY. > > > > > > > Could be, but if you manually set media it reinitializes PHY and it > > will call mge_ifmedia_upd() which in turn reinitializes the > > controller. I guess this is workaround in mge(4). > > > Do you mean setting the media through an ioctl by 'manually set media'? Yes. > If so, that doesn't really apply for either the TS-7800 or the > Sheevaplug as both need the network to work before userspace can do > anything. > Correct. Hmm, I have to read mge(4) again if time permits. > Kristof >