lkml.org 
[lkml]   [2021]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] soc: qcom: ipa: Remove superfluous error message around platform_get_irq()
On Thu, 10 Jun 2021 16:38:43 -0500
Alex Elder <elder@ieee.org> wrote:

> On 6/10/21 4:11 PM, David Miller wrote:
> > From:  Zhongjun Tan <hbut_tan@163.com>
> > 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 "<".

\
 
 \ /
  Last update: 2021-06-11 05:07    [W:0.051 / U:1.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site