Messages in this thread | | | Date | Mon, 12 Jan 2004 15:04:58 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH] Intel Alder IOAPIC fix |
| |
On Mon, 12 Jan 2004, James Bottomley wrote: > > So BAR0 is actually the location of the second I/O APIC's mapped address > range (which we've already covered with a fixmap from the MP TABLE). > I've no idea what the other four BARs all with addresses at 0xfffffc00 > are doing. > > The only way to prevent the current code (in arch/i386/pci/i386.c) from > reassigning this range seems to be to set the resource start to zero.
Ok. What I think we should do is to have a special quirk for chips like this that just _force_ the BAR values into the resource allocation table, and ignore things like the existing BIOS-marked allocations - because obviously the BIOS-marked ones are going to overlap.
This is where that "insert_resource()" thing comes in. Something like this might just work as a quirk:
adler_quirk(struct pci_dev *dev) { int i;
for (i = 0; i < 6; i++) { if (!pci_resource_start(dev, i)) continue; if (!pci_resource_len(dev, i)) continue; insert_resource(&iomem_resource, dev->resource + i); } }
and then make sure that the PCI layer doesn't try to re-allocate the resource some other way (I forget - maybe it already notices when the resource has already been inserted into the resource tree - otherwise you might need to add the code that says "if this resource is already inserted, don't try to reallocate it").
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |