Messages in this thread | | | Date | Mon, 15 Nov 2004 09:33:05 +0100 | From | Andi Kleen <> | Subject | Re: [PATCH] pci-mmconfig fix for 2.6.9 |
| |
On Sun, Nov 14, 2004 at 11:00:21PM -0700, Grant Grundler wrote: > > writes to handle Michael's power management issue properly. > > That would be definitely the safer approach. > > hrm...are you suggesting another entry point in the struct raw_pci_ops?
Yes.
> > There are two tests in arch/i386/pci/mmconfig.c:pci_mmcfg_init() before > the raw_pci_ops is set to &pci_mmcfg. Perhaps some additional crude tests > could select a different set of pci_raw_ops to deal with posted writes > to mmconfig space. Someone more familiar with those chipsets might > find a more elegant solution.
I cannot think of a generic good way to detect posting from the software side.
> > > > That means someone has to introduce a new method to access > > > mmconfig if they implement postable writes. > > > > > > Problem is that it adds silently a very subtle bug and there > > is no way I know of for ACPI to tell the firmware it shouldn't use > > posting. > > Uhm, ACPI needs to tell the firmware? > I would expect firmware to be platform/chip specific and "just know".
x86-64 always uses direct hardware access, x86 can use the 32bit PCI BIOS, but it's now discouraged.
> > If you meant OS, we already embed knowledge about specific chipsets > for bug workarounds (e.g. tg3 driver). I think that's an option here too. > I mean tweaking mmconfig.c to install a (possibly) chip specific > method (raw_pci_ops) to flush posted mmconfig writes.
Possibly yes. One issue is that we have a subtle bug until we notice though.
-Andi - 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/
| |