disable 64-bit dma for one PCI slot only?

[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.

> 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).

Scott