From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 16:11:39 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94DCC106566B; Wed, 20 Jul 2011 16:11:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 37A418FC1A; Wed, 20 Jul 2011 16:11:38 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id p6KGBY8b072629; Wed, 20 Jul 2011 10:11:35 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4E26A5BE.4000909@freebsd.org> Date: Wed, 20 Jul 2011 10:11:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2D778497-B02A-439B-8897-B484CCD799C8@samsco.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> <4E26A5BE.4000909@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-stable@FreeBSD.org Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:11:39 -0000 On Jul 20, 2011, at 3:54 AM, Stefan Esser wrote: >=20 > This is a very good idea, IMHO. >=20 > When I committed pciconf back in 1996 (it had been contributed by > gwollman) for PCI 1.0 (at a time when their was no standard for PCI to > PCI brigdes, yet ;-) ), the current format seemed sensible, but the > tabular form suggested by Artem is much better to parse. >=20 > I'd want to suggest another slightly different format: >=20 > Driver Handle Class Vnd Dev SubVnd SubDev Rev Hdr > hostb0 0:0:0:0 0x060000 0x8086 0x0100 0x8086 0x2010 0x09 0x00 > pcib1 0:0:1:0 0x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 > pcib2 0:0:1:1 0x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 > none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 > em0 0:0:25:0 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 > dummy0 65535:255:31:7 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 >=20 > I.e., print only one header line (no "---"), make the "Handle" column > wide enough to hold the longest possible value, use only white space = to > separate columns and print 0x as a prefix for all hex numbers. >=20 > Instead of "pci0:0:0:0" for the PCI handle, just "0:0:0:0" could be > printed, IMHO. (But this is bikeshed material, I guess ...) >=20 > The "Rev" column is required for of devices that are not uniquely > identified by their Vnd/Dev-IDs. (These used to exist, e.g. the = Symbios > SCSI controllers, though I'm not aware of any device that needed a > different driver depending on the PCI revision number.) >=20 Actually, a few drivers (amr in particular) look at this rev field = during probe, though they should be looking at the subdev/ven ids = instead. I think that this behavior has actually caused recent = headaches for LSI with other drivers. But as Kostik points out, the rev = field is still moderately useful for informational purposes. > I'd be happy to modify pciconf to print the new format in -CURRENT > (having been the maintainer of the PCI code for quite some time), if > consensus is reached on a format and if this change is accepted by RE. >=20 I'm pretty sure that we scrape the current format at Yahoo and use it in = our tools. Implementing a switch of some sort to fall back to the old = format is something that will have to happen at some point, whether it's = done now or not. I'd probably implement it as an env variable such as = "PCICONF_COMPAT", similar to what is used by expr(1). Scott