disable 64-bit dma for one PCI slot only?

[Stefan Esser]

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