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=-9.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable 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 7D4C2C48BE0 for ; Fri, 11 Jun 2021 03:05:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5FE20613AE for ; Fri, 11 Jun 2021 03:05:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231276AbhFKDHD (ORCPT ); Thu, 10 Jun 2021 23:07:03 -0400 Received: from m12-15.163.com ([220.181.12.15]:59915 "EHLO m12-15.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230205AbhFKDHC (ORCPT ); Thu, 10 Jun 2021 23:07:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:Message-ID:MIME-Version; bh=0Ym6k /3DmPhpmY+UFOFonjPWD4GzBEfsl7y9mwmxEh4=; b=Pho3XBuvvbSLEQR0iqLrn yS9VrGM/Ogb+8vKHyvyES5m4YJaBFJrgidP8QIXPhoYmEXzyYeBX1AuCT/vyZ6fq w/OWXu+IBgJJ7E3+Us+aD8+ilsCCWv9WVViyL6DbABAl65+OwYctZnNOcozaToSF v0sl39o3Nabifl9BKGr6UI= Received: from localhost (unknown [218.17.89.92]) by smtp11 (Coremail) with SMTP id D8CowAAXa9C00sJgL3t8AA--.2S2; Fri, 11 Jun 2021 11:04:28 +0800 (CST) Date: Fri, 11 Jun 2021 11:04:19 +0800 From: Zhongjun Tan To: Alex Elder Cc: David Miller , elder@kernel.org, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, tanzhongjun@yulong.com Subject: Re: [PATCH] soc: qcom: ipa: Remove superfluous error message around platform_get_irq() Message-ID: <20210611110419.00003810.hbut_tan@163.com> In-Reply-To: References: <20210610140118.1437-1-hbut_tan@163.com> <20210610.141142.1384244468678097702.davem@davemloft.net> Organization: Yulong X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=GB18030 Content-Transfer-Encoding: 8bit X-CM-TRANSID: D8CowAAXa9C00sJgL3t8AA--.2S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7Ww4fGr1kAw1xCr4xGw1kuFg_yoW8Ar18pr s0kayayr95ta1xG3W8Ja4ruFy5ur18tFW3Kw1Yg3WruFW5Xr90qr1rtFWF9rn5ur48C3W5 XF4j9ws5CFyFva7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jDPE-UUUUU= X-Originating-IP: [218.17.89.92] X-CM-SenderInfo: xkex3sxwdqqiywtou0bp/1tbiKB2uxl7WF+SVIwAAsQ Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Jun 2021 16:38:43 -0500 Alex Elder wrote: > On 6/10/21 4:11 PM, David Miller wrote: > > From:  Zhongjun Tan > > Date: Thu, 10 Jun 2021 22:01:18 +0800 > > > >> diff --git a/drivers/net/ipa/ipa_smp2p.c > >> b/drivers/net/ipa/ipa_smp2p.c index 34b68dc43886..93270e50b6b3 > >> 100644 --- a/drivers/net/ipa/ipa_smp2p.c > >> +++ b/drivers/net/ipa/ipa_smp2p.c > >> @@ -177,11 +177,8 @@ static int ipa_smp2p_irq_init(struct > >> ipa_smp2p *smp2p, const char *name, int ret; > >> > >> ret = platform_get_irq_byname(smp2p->ipa->pdev, name); > >> - if (ret <= 0) { > >> - dev_err(dev, "DT error %d getting \"%s\" IRQ > >> property\n", > >> - ret, name); > >> + if (ret <= 0) > > Applied, but this code still rejects an irq of zero which is a > > valid irq number. > > It rejects IRQ 0 intentionally. And if 0 is returned, there > will now be no message printed by the platform code. > > As I recall, I looked for a *long* time to see whether IRQ 0 > was a valid IRQ number in Linux. One reason I even questioned > it is that NO_IRQ is defined with value 0 on some architectures > (though not for Arm). I even asked Rob Herring about privately > it a few years back and he suggested I shouldn't allow 0. > > Yes, it *looked* like IRQ 0 could be a valid return. But I > decided it was safer to just reject it, on the assumption > that it's unlikely to be returned (I don't believe it is > or ever will be used as the IRQ for SMP2P). > > If you are certain it's valid, and should be allowed, I > have no objection to changing that "<=" to be "<". > > -Alex > > PS A quick search found this oldie: > https://yarchive.net/comp/linux/no_irq.html I think so , It is better to change "<=" to be "<".