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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
