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. =Kevin 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). -- Kevin Hickey Alchemy Solutions RMI Corporation khickey@xxxxxxxxxxx P: 512.691.8044
