What is the correct way to indicate an unassigned PCI resource ?

[Sergei Shtylyov]

Hello.

Grant Grundler wrote:

>>>Well, I don't have the PCI specification, but I have a device with the 

>>   Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)

> I think you meant pci21.pdf/pci22.pdf/pci23.pdf.

> And if you find them, trust me when I say whoever is hosting those files
> can expect a cease-and-desist letter in the mail shortly there after.

> Better to just ask someone with proper access to lookup the parts
> you need to know (i.e. ask here). Member companies are listed at:
> 	http://www.pcisig.com/membership/about_us/membership_roster/

> if you want to approach someone offlist.

    That's not fun. :-)

>>>following gem in its errata (name edited and changed to <Device>):

>>>""The <Device> contains two PCI base registers to allow for both greater 
>>>flexibility in tightly constrained I/O space as well as the "on the fly" 
>>>option to access the <Device> registers from either I/O or memory space. 
>>>Both PCI base registers contained in the <Device> will accept the value 
>>>of "zero" as a valid and decodable address. This differs from the PCI 2.1 
>>>specification, where a zero value being written to the PCI base register 
>>>should disable the register space.

>>   I haven't found such words in PCI 2.1 -- it only said that 0 is not a 
>>valid address (those words are gone from 2.2).

> AFAIK, zero is a valid address for IO Port space on several architectures.
> But PCI generic code should never use it. See usage of PCIBIOS_MIN_IO
> and PCIBIOS_MIN_MEM in the various asm-*/pci.h files.

    That'd be all good if bootloaders also folllowed this rule... Not all of 
them do, hence the thread. :-/

>>>which makes me suspect that a base address of zero really should mean
>>>unassigned and is a way to disable base registers on a region by region
>>>basis.

>>   AFAIR, there's never been a provision to enable/disable BARs on an 
>>individual basis in PCI (except the expansion ROM BAR). The decoders are
>>only controlled via 2 command register bits for I/O and memory space.

> One can "disable" a BAR by pointing it at an address that is NOT routed
> by the upstream bridge. Ie CPU physical addresses that can never reach
> that secondary bus. But I'm not aware of any code to do that currently

    Yeah, that's the trick that Gabriel has already described...

> and it certainly won't work with all "PCI-like" (think integrated south
> bridges) devices.

    Well, those are using subtractive decoders, so will only get the R/W 
cycles that nobody else cared about. If using I/O ports higher than 0xffff the 
trick will still work on x86 even in presence of ISA bridges...

> hth,
> grant

WBR, Sergei