On Tue, Dec 05, 2006 at 03:41:19PM +1100, Benjamin Herrenschmidt 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 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. <Device> will continue to decode for register accesses using the value "zero" written to the PCI_BS register as the base address for decoding."" 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. Now the fun with this device is that the I/O region occupies 4kB, so 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). Whatever a specification says, you'll always find some device that has a bug in this area. Regards, Gabriel - 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
