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

[Sergei Shtylyov]

Hello.

Gabriel Paubert wrote:

>>On Mon, 2006-12-04 at 14:22 +0000, Alan wrote:

>>>The discussion I was having was about sl82cxx and handling unassigned
>>>resources. The zero address isn't relevant to that.

>>Well, actually, it's unclear to me wether the resource is unassigned or
>>has been assigned to 0 :-) And in the later case, why claim'ing it
>>fails.

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

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

> <Device> will continue to decode for 
> register accesses using the value "zero" written to the PCI_BS register 
> as the base address for decoding.""

    I'd say it's absolutely valid bahavior.

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

> Now the fun with this device is that the I/O region occupies 4kB, so 

    That's a crappy device indeed, I/O alloction limit is 256 bytes (that's 
due to PC-specific limitation actually). Such regions may (and should) be left 
unassigned by f/w (and I/O decoder disabled).

> it leads to serious conflicts since there is also an ISA bridge in
> the system (no 8259 anymore, serial console dead, etc...). The best
> way to make this bug harmless is to write all ones to said base
> register (it has 32 bit). This moves it to an address which cannot 
> be generated by the host bridge (unless you program it in a really 
> weird way).

    You may also completely disable the I/O decoder for this device.

> Whatever a specification says, you'll always find some device that
> has a bug in this area.

    Yeah. I've already encountered such one...

WBR, Sergei