[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <476AC48D.6000103@redhat.com>
Date: Thu, 20 Dec 2007 14:37:49 -0500
From: Tony Camuso <tcamuso@...hat.com>
To: Matthew Wilcox <matthew@....cx>
CC: Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]
Matthew Wilcox wrote:
> Bad deduction. What's happening is that the write to the BAR is causing
> it to overlap the decode for mmconfig space. So the mmconfig write to
> set the BAR back never gets through.
>
> I have a different idea to fix this problem. Instead of writing
> 0xffffffff, we could look for an unused bit of space in the E820 map and
> write, say, 0xdfffffff to the low 32-bits of a BAR. Then it wouldn't
> overlap, and we could find its size using MMCONFIG.
>
Let me see if I understand this correctly.
Writing this BAR with 0xffffffff causes it to decode all further mmconfig
references based at addr 0xfxxxxxxx as its own?
If I've got that right, then why don't any of the other BARs do that? Is
it because this one's a 64-bit BAR?
AFIK, there are no devices out there that require 32-bits of address
space, so using 0xdfffffff in the low register would certainly work.
However, the PCI spec says that we should be able to write 0xffffffff
to the BAR, buggy BIOS and hardware notwithstanding.
Does anybody see that change as being within the purview of the patch-set
I am proposing? Or is that another patch for another time?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists