[lkml]   [2003]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2.5] PCI: allow alternative methods for probing the BARs
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 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.

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: 2005-03-22 13:32    [W:0.087 / U:10.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site