[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.021 / U:6.256 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site