From owner-svn-src-head@FreeBSD.ORG Mon Feb 2 20:55:11 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8685D106580E; Mon, 2 Feb 2009 20:55:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AF7918FC21; Mon, 2 Feb 2009 20:55:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 2C54946B2E; Mon, 2 Feb 2009 15:55:08 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n12Kt1V1043547; Mon, 2 Feb 2009 15:55:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: src-committers@freebsd.org Date: Mon, 2 Feb 2009 15:54:55 -0500 User-Agent: KMail/1.9.7 References: <200902021954.n12JsGT2005768@svn.freebsd.org> In-Reply-To: <200902021954.n12JsGT2005768@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902021554.55644.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Feb 2009 15:55:02 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8942/Mon Feb 2 13:56:43 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r188018 - in head: sys/dev/pci usr.sbin/pciconf X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 20:55:34 -0000 On Monday 02 February 2009 2:54:16 pm John Baldwin wrote: > Author: jhb > Date: Mon Feb 2 19:54:16 2009 > New Revision: 188018 > URL: http://svn.freebsd.org/changeset/base/188018 > > Log: > - Add a new ioctl to /dev/pci to fetch details on an individual BAR of a > device. The details include the current value of the BAR (including all > the flag bits and the current base address), its length, and whether or not > it is enabled. Since this operation is not invasive, non-root users are > allowed to use it (unlike manual config register access which requires > root). The intention is that userland apps (such as Xorg) will use this > interface rather than dangerously frobbing the BARs from userland to > obtain this information. > - Add a new sub-mode to the 'list' mode of pciconf. The -b flag when used > with -l will now list all the active BARs for each device. > > MFC after: 1 month As with the capability messages, I attempted to make the bar messages match the output of a verbose dmesg. An example: igb0@pci0:8:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xda020000, size 131072, enabled bar [14] = type Memory, range 32, base 0xda000000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x3000, size 32, enabled bar [1c] = type Memory, range 32, base 0xda080000, size 16384, enabled cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint There are a few caveats: 1) the ioctl will not report any status for a BAR that doesn't have allocated resources. We could fix this is if we stored details about the BARs we enumerate during pci_add_child() in the dinfo. 2) The ioctl will report status for BARs we add via quirks, but the pciconf doesn't know how to get to them. It may make sense for the IOCTL to work differently than it does now. Perhaps as an iterator where you request register 0 the first time, and then pass in the previous register on each update. It would then walk all the resources and signal end by setting the register to -1. The current mode does handle what Xorg expects I think, whereas the iterator approach would require more hacking on X. -- John Baldwin