From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC2ECC433DF for ; Sun, 17 May 2020 20:44:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9BC6420758 for ; Sun, 17 May 2020 20:44:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726426AbgEQUoN (ORCPT ); Sun, 17 May 2020 16:44:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbgEQUoN (ORCPT ); Sun, 17 May 2020 16:44:13 -0400 Received: from mail.bugwerft.de (mail.bugwerft.de [IPv6:2a03:6000:1011::59]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CB764C061A0C; Sun, 17 May 2020 13:44:12 -0700 (PDT) Received: from [192.168.178.106] (pD95EFBE7.dip0.t-ipconnect.de [217.94.251.231]) by mail.bugwerft.de (Postfix) with ESMTPSA id 70823409EB7; Sun, 17 May 2020 20:41:15 +0000 (UTC) Subject: Re: [PATCH 4/4] sc16is7xx: Use threaded IRQ To: Maarten Brock Cc: devicetree@vger.kernel.org, linux-serial@vger.kernel.org, gregkh@linuxfoundation.org, robh+dt@kernel.org, jslaby@suse.com, pascal.huerst@gmail.com, linux-serial-owner@vger.kernel.org References: <20200508143757.2609740-1-daniel@zonque.org> <20200508143757.2609740-5-daniel@zonque.org> <61fdcf12976c924fd86c5203aba673a7@vanmierlo.com> From: Daniel Mack Message-ID: <584de876-e675-0172-97ed-0c9534eb9526@zonque.org> Date: Sun, 17 May 2020 22:44:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <61fdcf12976c924fd86c5203aba673a7@vanmierlo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-serial-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org Hi Maarten, Thanks for your review! On 5/9/20 2:55 PM, Maarten Brock wrote: > On 2020-05-08 16:37, Daniel Mack wrote: >> Use a threaded IRQ handler to get rid of the irq_work kthread. >> This also allows for the driver to use interrupts generated by >> a threaded controller. >> >> Signed-off-by: Daniel Mack >> --- >>  drivers/tty/serial/sc16is7xx.c | 18 +++++------------- >>  1 file changed, 5 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/tty/serial/sc16is7xx.c >> b/drivers/tty/serial/sc16is7xx.c >> @@ -1317,8 +1308,9 @@ static int sc16is7xx_probe(struct device *dev, >>      } >> >>      /* Setup interrupt */ >> -    ret = devm_request_irq(dev, irq, sc16is7xx_irq, >> -                   IRQF_TRIGGER_FALLING, dev_name(dev), s); >> +    ret = devm_request_threaded_irq(dev, irq, NULL, sc16is7xx_irq, >> +                    IRQF_TRIGGER_FALLING | IRQF_ONESHOT, >> +                    dev_name(dev), s); >>      if (!ret) >>          return 0; > > Since UART0 is first handled completely in the for loop before UART1 is > handled, a new interrupt may arise on UART0 while UART1 is being handled. The code in the interrupt handling function loops forever until there is no more interrupt bits pending. So if there is a new IRQ happening for UART0 while UART1 is being served, it will be handled in the same loop. And just to be sure I understand correctly: this is unrelated to the switch to threaded IRQs, right? Falling edge triggers were always used for pdata probed devices. > The result is a missed interrupt since the IRQ line might not *FALL* again. It doesn't have to. We only exit the interrupt handler when there is nothing left to do, at which point the IRQ line ist back high. So it will fall again in case of new events. > Therefor I suggest to change IRQF_TRIGGER_FALLING to IRQF_TRIGGER_LOW. This > way the thread will be retriggered after IRQ_HANDLED is returned. This doesn't work in my setup unfortunately, as the interrupt controller is incapable of handling level IRQs. Thanks, Daniel