Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

On Tuesday, May 22, 2007, Robert Han*** wrote:
Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Han*** wrote:
Eww. I don't see where we disable the decode at all while we probe
the BARs on the device. That seems like a bad thing, especially with
the way we probe 64-bit BARs (do the low 32 bits first and then the
high 32 bits). This means the base address effectively gets set to
0xfffffff0 momentarily, which might cause some issues.

I'm a bit shocked that things work as well as they do without the
disabling...

I'd try adding some code inside pci_setup_device
(drivers/pci/probe.c) to disable PCI_COMMAND_IO and
PCI_COMMAND_MEMORY on the device when probing devices with the
standard header type and then restoring the previous command bits
afterwards, and see what effect that has. It'll be interesting if it
does, since obviously it seems to work as it is with non-MMCONFIG
access methods. Maybe the base address being set like that interferes
with MMCONFIG access itself somehow?

I tried that, and it seems to get past probing the graphics device at
least, but it hangs a bit later. It could be that the enable/disable
I added wasn't correct though, I didn't check to see which one I
should disable in the command word, which may be a problem (just
disabled them both every probe). I'll try again with more precise
enable/disable semantics.

It'd be interesting to see at what access it ran into trouble next, at
least if it's consistent. Could be that some device doesn't like having
the decode disabled..

I think it actually gets through the probing but hangs elsewhere, but I'll
have to test again to be sure.

Jesse
-
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/