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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 828D8C43334 for ; Mon, 6 Jun 2022 08:52:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232438AbiFFIwU (ORCPT ); Mon, 6 Jun 2022 04:52:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232704AbiFFIwF (ORCPT ); Mon, 6 Jun 2022 04:52:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7E805044B; Mon, 6 Jun 2022 01:49:47 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8B90361251; Mon, 6 Jun 2022 08:49:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDD7DC3411F; Mon, 6 Jun 2022 08:49:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654505386; bh=14B/zX7li0hOyh4z+Cjf/cYsZsY3+4GGu6OY8K+7/7Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=p0Du64LW1GHof7k1nwU8AqvG9NbbmRhG67bNOI2aImTPkt/RJdJuPHb8lnbFsbYWw RIF0GEzLN+2NdYTvhC0Q3xz3pkpRpx/YI2/ncPEEuFSuQH9fbXC2CBOdWzvjnOMwIe XVCr5stqVLLv86CW8tGAKAHqtiRMJTdXlthZUQoKunJ09M5ya6n7RzON8Um4N/veX0 pTq4aASxa6qa13kVaO2tI3Rd3Ooe0YuA8RTS8bqzHPNN1WH/olLwVbyXyl49UoxxUo 3DK89lX/clB5/camkNap+PW5U185MxoAcMiwggXkbaJZ4lwi0m1CmAj2LWkNbtued1 cQ9wHUq1KNdqg== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ny8Qh-00Fq92-Je; Mon, 06 Jun 2022 09:49:43 +0100 Date: Mon, 06 Jun 2022 09:49:43 +0100 Message-ID: <8735gi5g7s.wl-maz@kernel.org> From: Marc Zyngier To: Manivannan Sadhasivam Cc: tglx@linutronix.de, bjorn.andersson@linaro.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH 3/3] genirq: Check for trigger type mismatch in __setup_irq() In-Reply-To: <20220530080842.37024-4-manivannan.sadhasivam@linaro.org> References: <20220530080842.37024-1-manivannan.sadhasivam@linaro.org> <20220530080842.37024-4-manivannan.sadhasivam@linaro.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: manivannan.sadhasivam@linaro.org, tglx@linutronix.de, bjorn.andersson@linaro.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Mon, 30 May 2022 09:08:42 +0100, Manivannan Sadhasivam wrote: > > Currently, if the trigger type defined by the platform like DT does not > match the driver requested trigger type, the below warning is shown > during platform_get_irq() but only during the second time of the drive > probe (due to probe deferral or module unload/load). > > irq: type mismatch, failed to map hwirq-9 for interrupt-controller@b220000! > > Consider a typical usecase of requesting an IRQ in a driver: > > ``` > /* Assume DT has set the trigger type to IRQF_TYPE_LEVEL_HIGH */ > > q6v5->wdog_irq = platform_get_irq_byname(pdev, "wdog"); > if (q6v5->wdog_irq <= 0) > return q6v5->wdog_irq; > > ret = devm_request_threaded_irq(&pdev->dev, q6v5->wdog_irq, > NULL, q6v5_wdog_interrupt, > IRQF_TRIGGER_RISING | IRQF_ONESHOT, > "q6v5 wdog", q6v5); > if (ret) { > dev_err(&pdev->dev, "failed to acquire wdog IRQ\n"); > return ret; > } > ``` > > For the first time probe of a driver, platform_get_irq_byname() does not > return an error and it sets the platform requested trigger type. Then, > request_irq() also does not check for the trigger type mismatch and sets > the driver requested trigger type. Later if the driver gets probed again, > platform_get_irq() throws the "type mismatch" warning and fails. > > Ideally, request_irq() should throw the error during the first time itself, > when it detects the trigger type mismatch. So let's add a check in > __setup_irq() for checking the trigger type mismatch. No, that's wrong. The whole point is to be able to *override* the default that is exposed by the device tree or ACPI. We have countless examples of that, and they cannot be broken. If the issue exists after an unload, then it is a unload time that the previous behaviour should be restored. Thanks, M. -- Without deviation from the norm, progress is not possible.