Alan Cox wrote: >> circumstances, during resume SRST, the drive would raise the IRQ line >> regardless of NIEN and will stay that way for several seconds, thus >> triggering nobody cared. Other than detecting and clearing the >> spurious IRQ, there just isn't much driver can do to work around >> problems like this. > > There is. It also means your patch isn't sufficient - if that IRQ had > been level triggered you'd have hung the box solid. Right, the attached patch fixed it so it must have been the controller latching the IRQ. > The old IDE code makes use of disable_irq/enable_irq (and really ought to > make use of on chip private IRQ mask bits as first choice but doesn't). > > Sounds to me like there are two things we can do to help > > Make the nIEN masking via a helper that can on suitable chips also mask > on chip. > > Make use of disable_irq_nosync() in the case of devices that ignore nIEN > in the IRQ handler, setting a flag then re-enable it when the driver > path completes the reset and the bit goes clear. > > We need to start using enable/disable_irq and/or local chip IRQ masking > for PIO in some places anyway. Agreed. I think we should use disable/enable_irq for all controller which don't have proper IRQ masking mechanism (NIEN doesn't count) for both reliability and so that we move PIO out of irq handler. Jeff, this has come up quite a few times now, what do you think? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
