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=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 DD650C31E57 for ; Mon, 17 Jun 2019 13:22:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A4E25206B7 for ; Mon, 17 Jun 2019 13:22:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="jMkkk91r"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="jMkkk91r" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726427AbfFQNWc (ORCPT ); Mon, 17 Jun 2019 09:22:32 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:47530 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbfFQNWc (ORCPT ); Mon, 17 Jun 2019 09:22:32 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 8324260254; Mon, 17 Jun 2019 13:22:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1560777750; bh=ew/xbajXtVboXMA/g2sJySnJBP6r87Wf7tJKswJnaqs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jMkkk91rJHyKHUc8qdhdkxnNyBUBpMgikXZ9N35782cqteuJ+Xwi7CzdeQq7Zqcqk flbAmjU4UdQ4glqfRCTixYWtV1KlJviVUyr+YJnj98lDnOLJj+7ZfdtkZXfJdRe4RI wQGHzC1Cs36FFO0PNWaxdndHTc96p4IIiOPWSAMM= Received: from [10.204.78.89] (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: neeraju@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 7624B60265; Mon, 17 Jun 2019 13:22:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1560777750; bh=ew/xbajXtVboXMA/g2sJySnJBP6r87Wf7tJKswJnaqs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jMkkk91rJHyKHUc8qdhdkxnNyBUBpMgikXZ9N35782cqteuJ+Xwi7CzdeQq7Zqcqk flbAmjU4UdQ4glqfRCTixYWtV1KlJviVUyr+YJnj98lDnOLJj+7ZfdtkZXfJdRe4RI wQGHzC1Cs36FFO0PNWaxdndHTc96p4IIiOPWSAMM= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 7624B60265 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=neeraju@codeaurora.org Subject: Re: Fwd: Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask To: Linus Walleij , Hans Verkuil Cc: Stephen Boyd , Tengfei Fan , Bjorn Andersson , LKML , "open list:GPIO SUBSYSTEM" , MSM , sramana@codeaurora.org References: <20190611185102.368ED21744@mail.kernel.org> <671f87d6-f4a4-6d2c-967b-e1aa0677d83e@codeaurora.org> From: Neeraj Upadhyay Message-ID: Date: Mon, 17 Jun 2019 18:52:24 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Thanks for the review, Linus. On 6/17/19 5:20 PM, Linus Walleij wrote: > On Mon, Jun 17, 2019 at 12:35 PM Neeraj Upadhyay wrote: > >> Hi Stephen, there is one use case with is not covered by commit >> b55326dc969e ( >> >> "pinctrl: msm: Really mask level interrupts to prevent latching"). That >> happens when >> >> gpio line is toggled between i/o mode and interrupt mode : >> >> 1. GPIO is configured as irq line. Peripheral raises interrupt. >> >> 2. IRQ handler runs and disables the irq line (through wq work). >> >> 3. GPIO is configured for input and and data is received from the >> peripheral. > There is no distinction between using a GPIO line as input > and using it for IRQ. All input GPIOs can be used for IRQs, > if the hardware supports it (has an irqchip). Ok > >> 4. Now, when GPIO is re-enabled as irq, we see spurious irq, and there >> isn't >> >> any data received on the gpio line, when it is read back after >> configuring as input. > That's an interesting usecase. Hans Verkuil reworked the > GPIO irq support very elegantly exactly to support this type > of usecase (irq switch on and off dynamically), where he > was even switching the line into output mode between > the IRQ trains. (one-wire transcactions for CEC). > >> Patch https://lkml.org/lkml/2019/6/17/226 tries to cover this use case. >> Can you please provide your comments? > What this patch does is clear all pending IRQs at irq > unmask. This is usually safe, unless there may be cases > where you *want* to catch any pending IRQs. I guess > normally you don't so it should be safe? We want to clear pending status at irq enable. Afaik, no, we don't normally track these pending irqs. So, should be fine here. > > The corner case is when you start some transaction > or whatever that gets ACKed by an IRQ and you actually > get the IRQ back before you had time to execute the code > enabling the IRQ. > > That would be racy and bad code, as you should clearly > enable the IRQ first, then start the transaction. So I think > this patch is safe. > > But let's see what Bjorn says. > > Yours, > Linus Walleij -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation