Tejun Heo wrote: > 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? OSDL bz#10884 seems to suffer similar problem. The patch fixes it. http://bugzilla.kernel.org/show_bug.cgi?id=10884 We definitely need to do something about it. -- 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
