From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 18:45:06 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 CC816106564A for ; Wed, 20 Jul 2011 18:45:06 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm18.bullet.mail.bf1.yahoo.com (nm18.bullet.mail.bf1.yahoo.com [98.139.212.177]) by mx1.freebsd.org (Postfix) with SMTP id 80E628FC08 for ; Wed, 20 Jul 2011 18:45:06 +0000 (UTC) Received: from [98.139.212.153] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jul 2011 18:31:32 -0000 Received: from [98.139.211.203] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jul 2011 18:31:32 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 20 Jul 2011 18:31:32 -0000 X-Yahoo-Newman-Id: 484071.21266.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _5eE9HgVM1kCOojTkqnObothbVR2fZZlRrZP4Qn46bUcNT2 SZWCTSoNgRE2gknmONIqX2fp.HeEe1HRMCVO5ElncmvpB5gA59m.t1EFYHLe eoKsUupx02EYrUvHMWArmxxIkUnBNLnVcXBc79OVfc_pIynp4wkq458tl4dQ usqnxpGSMENfiFHUTyJ1T2WRC_zMaPVv9CGTzSvBUI8rvw3YMaNu68dNsuVS IxkRWumE5YFgzbZWvdLLTeEJhXqzjMJ068oIECyezt9Aj3Gk7SyVC6zeKLh3 hz7fXTnYq8zpHg0NhnOQ9NvbzvJcsCpaZWAtPM4yMQextk2_MezA_6z_Q_6U 69nC9t6q9JDLPyZ_G826ixXi6_g-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.152.255 with plain) by smtp212.mail.bf1.yahoo.com with SMTP; 20 Jul 2011 11:31:30 -0700 PDT Message-ID: <4E271EFF.7060109@freebsd.org> Date: Wed, 20 Jul 2011 20:31:27 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Long 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> <2D778497-B02A-439B-8897-B484CCD799C8@samsco.org> In-Reply-To: <2D778497-B02A-439B-8897-B484CCD799C8@samsco.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 18:45:06 -0000 Am 20.07.2011 18:11, schrieb Scott Long: > On Jul 20, 2011, at 3:54 AM, Stefan Esser wrote: >> >> This is a very good idea, IMHO. >> >> 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. >> >> I'd want to suggest another slightly different format: >> >> 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 >> >> 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. >> >> 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 ...) >> >> 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.) > > 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. Dependency on the revision is bad, if it is a required criterion for the selection of a driver. This used to be the case for the Symbios 53c810 vs. 53c860 (where the latter could take advantage of the "sym" driver, while the prior lacked support of features originally required by the sym driver and only worked with "ncr"). The subvendor/subdevice ID is not well suited to select a driver in that case, since it was not used in general (PCI 1.0, on-board controllers) and even if it was used, the list of subvendor/subdevice tuples is hard to maintain if there are many vendors using a certain PCI(e) chip. >> 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. > > 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). Hmm, then how about a new option (e.g. "-t" for tabular output, or "-L" for an alternate list format). For the current format, "-l" can be combined with "-b", "-c" and/or "-v" to print BARs, CAPs and/or decoded vendor and device information. The new tabular format suggested above does not mix well with these extended list options, and thus I think we should introduce a new list option that is incompatible with -b, -c and -v. The old option would produce unchanged output and thus there is no need for PCICONF_COMPAT. Regards, STefan