I am still concerned about this patch. Just last week we encountered
similar behavior that turned out to be a board design error. I had a
similar patch in that kernel that allowed me to run without error. Our
Windows CE developer, however, did not and ended up finding the board
bug. Fixing the board improved performance and system stability - had
we not been running CE we probably would not have found the issue until
much later and with greater effort.
Your example below is similar - debouncing the switch in hardware seems
a better solution (albeit likely an expensive one) than patching the
mainline kernel. And I reiterate: some devices send a lot of interrupts
by design; we should honor their requests, not mask them out.
On Wed, 2009-01-21 at 07:48 +0100, Manuel Lauss wrote:
> Hi Kevin,
> > Have you actually seen this happen (outside of inducing it manually)? I
> > have some concern that by doing this we may either miss interrupts on
> > devices that send a lot (by design) or miss a design bug in a system
> > because we are masking out some interrupts. I know that system
> > stability is important, but I don't like hiding problems.
> Yes, in a customer project. A simple pushbutton which connects a pulled-up
> gpio pin to ground. Push it, instant hang (handler called over and over
> again) when it is not debounced. With a single edge and a much lower
> edge-frequency it obviously works fine (see timer).
> (And, handle_edge_irq() _does_ call mask_ack() after all).