[lkml]   [2004]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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))
if (!pci_resource_len(dev, i))
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").

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.078 / U:6.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site