On Mon, Mar 14, 2005 at 10:46:02AM -0500, Alan Stern wrote:
...
> Very helpful, thanks.  It appears that the main problem with disabling 
> PCI devices as they are discovered lies with devices that are already in 
> use (before their drivers have initialized!).

Yes - e.g. firmware is used to talk to the device and we really
have no clue (yet) which device it is.

> Obviously this can include the console.
> Any other examples you can point out?  Network devices maybe?

LAN drivers normally fall in the "were in use but not quiesced".
Ie they are good candidates for disabling during buswalk normally.

One hypothetical exception would be a remote LAN debugger might have
it's own driver to poking the LAN device and not use the OS driver at all.
I'm pretty sure Linux does not do this today. But it's a possibility
I don't want to preclude if I don't have to. I assume such an
implementation would need additional OS hooks and/or firmware help.

> What do you think of the idea of setting up a list of devices that the
> kernel starts to use early in the boot procedure (without the benefit
> of normal drivers)?

Hrm...not easy since we only have a "handle" that firmware gave us.
We don't necessarily know which device it is or which bus it's under.
That's for parisc. ia64 probably has a richer firmware interface.
No clue about ACPI and/or BIOS on x86.

>   The PCI scanning routine could check newly discovered
> devices against this list and disable them only if they aren't on it.  
> Possibly other buses could make use of such a list as well.

Yes - but this doesn't solve the "Programmed by firmware and
transperent to the OS" type of devices.

> > call disable_irq(pci_dev->irq).
> > But that may only work for line based IRQs.
> > May need to do something difference for MSI/MSI-X.
> > Off hand, I'm not sure.
> 
> Worse than that, it will disable the entire IRQ line, thus affecting other
> devices that may be sharing it.  That's not what I want; I need a way to
> prevent a generic PCI device from issuing interrupt requests without
> affecting other devices sharing the same IRQ.

True. I'm not aware of any generic mechanism to prevent a PCI device from
asserting IRQ Line.

> The idea is that when another device sharing the IRQ is initialized and 
> the IRQ is enabled, we won't start getting spurious unhandled interrupt 
> requests from the device whose driver isn't initialized yet.

This is another reason Shared IRQs just suck.
We just can't fix this corner case though.
HW Vendors mostly no longer share IRQ Lines and MSI-X should avoid
the issue all together is the only hope I can offer.

grant


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to