On Tue, Apr 26, 2005 at 12:04:00PM -0400, Alan Stern wrote: > > Sure there is. Every IRQ line goes to an IRQ controller. > > Arch specific code deals with programming the controller and can > > mask all interrupts (or not). Historically, they've been left unmasked > > for ISA IRQ discovery and debugging misrouted IRQ lines. > > This doesn't help. Consider what happens when two devices share an IRQ > line. Suppose device B is generating interrupt requests when the driver > for device A is probed. The driver registers its handler, which causes > the IRQ line to be unmasked. Then a multitude of IRQs arrive from B, none > of which can be handled by A's driver. So the kernel shuts the IRQ line > down permanently...
Agreed - but this is a different problem than "shutting down IRQs". My point was arch specific code knows how to mask all IRQs. irq_disable() is expected to work regardless of what state the driver is in. On kexec "reboot", kernel drivers can unmask IRQs as they normally would during initialization. No? grant ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
