Re: [patch 2.5] PCI: allow alternative methods for probing the BARs

[grundler@cup.hp.com (Grant Grundler)]

On Mon, Jan 06, 2003 at 03:19:09PM -0800, Linus Torvalds wrote:
> In particular, we can make the first phase disable DMA on the devices we 
> find, which means that we know they won't be generating PCI traffic during 
> the second phase - so now the second phase (which does the BAR sizing) can 
> do sizing and be safe in the knowledge that there should be no random PCI 
> activity ongoing at the same time.

Did you expect the PCI_COMMAND_MASTER disabled in the USB Controller
or something else in the controller turned off?

Turning off MASTER will also disable the controller from responding
to MMIO ...ie USB subsystem can't touch the USB controller until
it's re-enabled (no USB interrupts). That's ok if PCI will re-enable
USB controller in a later PCI setup phase. In general I expect a driver
to call pci_enable_device() but I don't know anything about USB intialization
when it's part of the "console" (HID).

BTW, I wasn't thinking of USB.  I'm just trying to understand if the "fix"
is exclusively in the PCI code or will require changes to other subsystems.

> It's fine to temporarily disable memory on the northbridge, as long as
> nothign else tries to _access_ that memory at the same time.

The implemention to enforce that is what I meant with "arch specific code".

I still have no idea which bridge implementations (vendor/model)
have this problem and thus no idea what the i386 code would need 
to look like. I was hoping Ivan (or someone) might know.

thanks,
grant