From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932241AbcHIJWm (ORCPT ); Tue, 9 Aug 2016 05:22:42 -0400 Received: from fieber.vanmierlo.com ([84.243.197.177]:50553 "EHLO kerio9.vanmierlo.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752420AbcHIJWk (ORCPT ); Tue, 9 Aug 2016 05:22:40 -0400 X-Greylist: delayed 1803 seconds by postgrey-1.27 at vger.kernel.org; Tue, 09 Aug 2016 05:22:40 EDT X-Footer: dmFubWllcmxvLmNvbQ== MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Aug 2016 10:52:17 +0200 From: m.brock@vanmierlo.com To: linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] sc16is7xx: Do not handle irqs in endless loop In-Reply-To: <1470663136-26269-1-git-send-email-dirk.eibach@gdsys.cc> References: <1470663136-26269-1-git-send-email-dirk.eibach@gdsys.cc> Message-ID: User-Agent: Roundcube Webmail/1.2.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-08-08 15:32, dirk.eibach@gdsys.cc wrote: > From: Dirk Eibach > > sc16is7xx_port_irq() is laid out as an endless loop. It will exit only > when there is no more interrupt left to service. This not common > practice. > In our case it lead to some strange hangup situation when there was an > unexpected XOFF-interrupt that could not be handled. > So let's service interrupts only once and report XOFF-interrupts that > should never happen since they are never enabled. The reason for such an endless loop in an interrupt handler usually means that multiple sources can generate an interrupt and the interrupt controller is configured for edge. During handling the interrupt of one source (e.g. data received) but before it is cleared, another interrupt can trigger (e.g. transmit done). This will not generate a new edge as the interrupt line is still active! Thus re-reading the interrupt status is required. And with interrupt sharing this problem gets even worse. The fact that the sc16is7xx uses an indirect interface like i2c or spi doesn't help either. When configured for level interrupts the interrupt will automatically re-trigger. But the risk of interrupt storm when the hardware is broken (interrupt line stuck active) seems to keep developers away from setting level interrupt. IMHO an interrupt storm should be detectable by the interrupt handler so nobody needs to fear using level sensitive interrupts. Maarten