From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 14:22:22 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8230A106566C; Fri, 22 Apr 2011 14:22:22 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7E48FC0C; Fri, 22 Apr 2011 14:22:22 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 07:10:21 -0700 From: Ben Hutchings To: Marius Strobl In-Reply-To: <20110422120909.GO38455@alchemy.franken.de> References: <20110421203304.GA91381@alchemy.franken.de> <20110422120909.GO38455@alchemy.franken.de> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Date: Fri, 22 Apr 2011 15:10:14 +0100 Message-ID: <1303481415.4129.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2011 14:10:21.0905 (UTC) FILETIME=[047BDC10:01CC00F7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18088.005 X-TM-AS-Result: No--20.306500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Bjoern A. Zeeb" , net@freebsd.org, arch@freebsd.org Subject: Re: RFC further mii(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:22:22 -0000 On Fri, 2011-04-22 at 14:09 +0200, Marius Strobl wrote: > On Fri, Apr 22, 2011 at 10:07:11AM +0000, Bjoern A. Zeeb wrote: [...] > > One thing I am still pondering is whether we would be able to reserve enough spares (wherever needed) to be able to eventually allow to query-through and gather a lot more information than we currently expose via ifconfig. It would be really great to be able to ask for all the bits. Not sure how linux for example handles that for mii-tool/ethtool or how those things work, but .. well you get it. > > > > Providing functionality akin mii-tool/ethtool is also something I'd > like to see. Unfortunately, I currently lack the time to work on that, > maybe next year as a GSoC or some such, in case someone is willing to > mentor this time :) However, I think when going a route similar to > pci(4)/pciconf(8) (without repeating their mistakes) it should be > possible to implement that without breaking the ABI. mii-tool uses the MDIO ioctls, wherease ethtool uses the relatively high-level ethtool API. Note that mii-tool itself is unmaintained and needs some unofficial patches to support even 1G PHYs. The MDIO ioctls all use struct ifreq with an instance of struct mii_ioctl_data in the ifr_ifru field. See and . SIOCGMIIPHY: Set the phy_id field to the address of the PHY that the net device is using. (It is not specified what to do if the device is not using an MDIO-manageable PHY.) SIOCGMIIREG: Read the register at the address specified by phy_id and reg_num. Set val_out to the register value. SIOCSMIIREG: Write the register at the addres specified by phy_id and reg_num, with the value from val_in. For clause 45 MDIO (as used by 10G and some other PHYs), the phy_id for SIOC{G,S}MIIREG (but not SIOCGMIIPHY) provides both PRT and DEV addresses, as specified in . Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.