On Tue, Sep 18, 2018 at 02:13:15PM +0100, Phil Elwell wrote: > I could add a limit on the number of iterations, but if the limit is ever hit, > leading to an early exit, the port is basically dead because it will never > receive another interrupt. Especially if you print something like: "<driver name>: Too many iterations with work-to-do bailing out" while bailing out, then hanging just one driver/piece of hardware as opposed to the whole system when somehow the hardware never indicates "all work done" would be preferable. Under normal circumstances you never expect to hit that number of iterations. But if the card keeps hitting the driver with "more work to do" then you'd hang the system. Better try and recover, and provide debug info for the user who knows where to look. Best would be to ignore the driver for say a second and start handling interrupts again a while later. Should the system be overloaded with work, (and a slow CPU?) then you can recover and just make things slow down a bit without hanging the system. Getting edge-triggered interrupts right is VERY difficult. In general I'd advise against them. It looks like a nice solution, but in reality the chances for difficult-to-debug race conditions is enormous. In those race conditions the card will get "new work to do" and (re-)assert the interrupt line when the driver is already on the "no more work to do" path. Roger. -- ** R.E.Wolff@xxxxxxxxxxxx ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.
