Re: [PATCH] Intel Alder IOAPIC fix

[Linus Torvalds]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/