On Mon, 16 May 2005 16:16:06 -0400 "Adam Belay" <ambx1@xxxxxxxxxx> wrote: > b.) You're assuming every device has its own interrupt. This may not > be the case. Let's say one device was sharing interrupts with a few > other devices. We don't want it's interrupt handler to mess up things > when it tries to read hardware registers from a physically "off" > device, as it may possibly generate errors. Almost every interrupt > handler assumes the device is "on", as it should. Each interrupt > handler has to ask its hardware if it generated the interrupt. I ran into this very problem a while back on 2.4. On my platform, the EHCI and OCHI host controllers share an interrupt. I was insmoding the EHCI module before the OHCI module, but it turned out that the OHCI controller was first on the bus, so it went down first during suspend, and up first on resume. Long story short, it starting firing interrupts which went to the EHCI driver first (since it was earlier on the interrupt handler chain), and the device faithfully hung waiting to read hardware that was still powered off. Now, granted that particular scenario is a corner case, and the PCI hardware should have been configured better, but it shows that you can't assume that any given interrupt handler will only be called with active hardware underneath. So either an "active" bit gets added to each and every driver to be checked in an interrupt routine, or we bail on the handler all together - I fancy the second. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group <www.amd.com/embeddedprocessors>
