| Message ID | 20171209115203.pdtdfnmzwz6zpjqs@mwanda (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | cd430a244cd5d3ca0f4053718eabdf42bc12c517 |
| Headers | show |
Hi Dan, On Saturday 09 December 2017 05:22 PM, Dan Carpenter wrote: > The error handling doesn't work here because "nuc900_audio->irq_num" is > unsigned. Also we should be checking for < 0 and not <= 0 but I believe > that's harmless. The platform_get_irq() comments don't talk about the > return values... Sorry for this patch. I will fix it and send you updated patch. Thanks for point it. > Fixes: fa8cc38165c2 ("ASoC: nuc900: Fix platform_get_irq's error checking") > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > index 5e4fbd2d3479..71fce7c85c93 100644 > --- a/sound/soc/nuc900/nuc900-ac97.c > +++ b/sound/soc/nuc900/nuc900-ac97.c > @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) > goto out; > } > > - nuc900_audio->irq_num = platform_get_irq(pdev, 0); > - if (nuc900_audio->irq_num <= 0) { > - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; > + ret = platform_get_irq(pdev, 0); > + if (ret < 0) > goto out; > - } > + nuc900_audio->irq_num = ret; > > nuc900_ac97_data = nuc900_audio; > ~arvind
Arvind, This was v5 and it contains an error that was corrected between v1 and v2. For whatever reason, you reintroduced it between v4 and v5. This is wasting a lot of time. On 09/12/2017 at 19:03:56 +0530, arvindY wrote: > Hi Dan, > > On Saturday 09 December 2017 05:22 PM, Dan Carpenter wrote: > > The error handling doesn't work here because "nuc900_audio->irq_num" is > > unsigned. Also we should be checking for < 0 and not <= 0 but I believe > > that's harmless. The platform_get_irq() comments don't talk about the > > return values... > Sorry for this patch. I will fix it and send you updated patch. > Thanks for point it. > > Fixes: fa8cc38165c2 ("ASoC: nuc900: Fix platform_get_irq's error checking") > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > > index 5e4fbd2d3479..71fce7c85c93 100644 > > --- a/sound/soc/nuc900/nuc900-ac97.c > > +++ b/sound/soc/nuc900/nuc900-ac97.c > > @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) > > goto out; > > } > > - nuc900_audio->irq_num = platform_get_irq(pdev, 0); > > - if (nuc900_audio->irq_num <= 0) { > > - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; > > + ret = platform_get_irq(pdev, 0); > > + if (ret < 0) The <= 0 was ok, see: https://lkml.org/lkml/2017/11/18/41
Hi, On Saturday 09 December 2017 10:57 PM, Alexandre Belloni wrote: > Arvind, > > This was v5 and it contains an error that was corrected between v1 and > v2. For whatever reason, you reintroduced it between v4 and v5. > > This is wasting a lot of time. Yes, You are right. That is my mistake. Next time I will try to avoid These kind of error. > > On 09/12/2017 at 19:03:56 +0530, arvindY wrote: >> Hi Dan, >> >> On Saturday 09 December 2017 05:22 PM, Dan Carpenter wrote: >>> The error handling doesn't work here because "nuc900_audio->irq_num" is >>> unsigned. Also we should be checking for < 0 and not <= 0 but I believe >>> that's harmless. The platform_get_irq() comments don't talk about the >>> return values... >> Sorry for this patch. I will fix it and send you updated patch. >> Thanks for point it. Thanks for Fix. Please ignore my previous comment. >>> Fixes: fa8cc38165c2 ("ASoC: nuc900: Fix platform_get_irq's error checking") >>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Arvind Yadav <Arvind.yadav.cs@gmail.com> >>> >>> diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c >>> index 5e4fbd2d3479..71fce7c85c93 100644 >>> --- a/sound/soc/nuc900/nuc900-ac97.c >>> +++ b/sound/soc/nuc900/nuc900-ac97.c >>> @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) >>> goto out; >>> } >>> - nuc900_audio->irq_num = platform_get_irq(pdev, 0); >>> - if (nuc900_audio->irq_num <= 0) { >>> - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; >>> + ret = platform_get_irq(pdev, 0); >>> + if (ret < 0) > The <= 0 was ok, see: > https://lkml.org/lkml/2017/11/18/41 > > ~arvind
On Sat, Dec 09, 2017 at 06:27:32PM +0100, Alexandre Belloni wrote: > > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > > > index 5e4fbd2d3479..71fce7c85c93 100644 > > > --- a/sound/soc/nuc900/nuc900-ac97.c > > > +++ b/sound/soc/nuc900/nuc900-ac97.c > > > @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) > > > goto out; > > > } > > > - nuc900_audio->irq_num = platform_get_irq(pdev, 0); > > > - if (nuc900_audio->irq_num <= 0) { > > > - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; > > > + ret = platform_get_irq(pdev, 0); > > > + if (ret < 0) > > The <= 0 was ok, see: > https://lkml.org/lkml/2017/11/18/41 > Yeah, but is it ever going to return 0? That seems like a design error and also really crap commenting if so. regards, dan carpenter
On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: > On Sat, Dec 09, 2017 at 06:27:32PM +0100, Alexandre Belloni wrote: >>>> diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c >>>> index 5e4fbd2d3479..71fce7c85c93 100644 >>>> --- a/sound/soc/nuc900/nuc900-ac97.c >>>> +++ b/sound/soc/nuc900/nuc900-ac97.c >>>> @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) >>>> goto out; >>>> } >>>> - nuc900_audio->irq_num = platform_get_irq(pdev, 0); >>>> - if (nuc900_audio->irq_num <= 0) { >>>> - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; >>>> + ret = platform_get_irq(pdev, 0); >>>> + if (ret < 0) >> The <= 0 was ok, see: >> https://lkml.org/lkml/2017/11/18/41 >> > Yeah, but is it ever going to return 0? That seems like a design error > and also really crap commenting if so yes, It can return 0 on sprac platform and If you see the return of platform_get_irq() 'return r ? r->start : -ENXIO;'. It should be 'return r && r->start? r->start : -ENXIO;'. We can not add checks here, Because There's a bunch of platforms in the kernel they still use IRQ0 as valid. I have separate mails where few maintainer ask me to add check for 0 and few not. Adding check for 0 will never harm. > > regards, > dan carpenter > ~arvind
On Sun, Dec 10, 2017 at 08:10:26AM +0530, arvindY wrote: > > > On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: > > On Sat, Dec 09, 2017 at 06:27:32PM +0100, Alexandre Belloni wrote: > > > > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > > > > > index 5e4fbd2d3479..71fce7c85c93 100644 > > > > > --- a/sound/soc/nuc900/nuc900-ac97.c > > > > > +++ b/sound/soc/nuc900/nuc900-ac97.c > > > > > @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) > > > > > goto out; > > > > > } > > > > > - nuc900_audio->irq_num = platform_get_irq(pdev, 0); > > > > > - if (nuc900_audio->irq_num <= 0) { > > > > > - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; > > > > > + ret = platform_get_irq(pdev, 0); > > > > > + if (ret < 0) > > > The <= 0 was ok, see: > > > https://lkml.org/lkml/2017/11/18/41 > > > > > Yeah, but is it ever going to return 0? That seems like a design error > > and also really crap commenting if so > yes, It can return 0 on sprac platform and If you see the return of > platform_get_irq() 'return r ? r->start : -ENXIO;'. It should be > 'return r && r->start? r->start : -ENXIO;'. We can not add checks here, > Because There's a bunch of platforms in the kernel they still use IRQ0 as > valid. > I have separate mails where few maintainer ask me to add check for 0 and few > not. > Adding check for 0 will never harm. What you're saying doesn't make sense. You *can't* treat 0 as an error on Sparc because that's a valid IRQ. In fact, it seems like if you want to write portable code you should never treated zero as an error. It doesn't make sense that someone would register an IRQ resource with an invalid IRQ number. In other words, r->start is never going to be zero on a platform where that's invalid. So I'm pretty sure "if (ret < 0) " is the correct way to write code and "if (ret <= 0) " is incorrect but generally harmless except perhaps in limited situations on SPARC or other similar arches. regards, dan carpenter
Hi Dan, On Monday 11 December 2017 02:10 PM, Dan Carpenter wrote: > On Sun, Dec 10, 2017 at 08:10:26AM +0530, arvindY wrote: >> >> On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: >>> On Sat, Dec 09, 2017 at 06:27:32PM +0100, Alexandre Belloni wrote: >>>>>> diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c >>>>>> index 5e4fbd2d3479..71fce7c85c93 100644 >>>>>> --- a/sound/soc/nuc900/nuc900-ac97.c >>>>>> +++ b/sound/soc/nuc900/nuc900-ac97.c >>>>>> @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) >>>>>> goto out; >>>>>> } >>>>>> - nuc900_audio->irq_num = platform_get_irq(pdev, 0); >>>>>> - if (nuc900_audio->irq_num <= 0) { >>>>>> - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; >>>>>> + ret = platform_get_irq(pdev, 0); >>>>>> + if (ret < 0) >>>> The <= 0 was ok, see: >>>> https://lkml.org/lkml/2017/11/18/41 >>>> >>> Yeah, but is it ever going to return 0? That seems like a design error >>> and also really crap commenting if so >> yes, It can return 0 on sprac platform and If you see the return of >> platform_get_irq() 'return r ? r->start : -ENXIO;'. It should be >> 'return r && r->start? r->start : -ENXIO;'. We can not add checks here, >> Because There's a bunch of platforms in the kernel they still use IRQ0 as >> valid. >> I have separate mails where few maintainer ask me to add check for 0 and few >> not. >> Adding check for 0 will never harm. > What you're saying doesn't make sense. I am following a below link. Where they have point out irq 0 is not valid. https://lwn.net/Articles/470820/ > > You *can't* treat 0 as an error on Sparc because that's a valid IRQ. In > fact, it seems like if you want to write portable code you should never > treated zero as an error. > > It doesn't make sense that someone would register an IRQ resource with > an invalid IRQ number. In other words, r->start is never going to be > zero on a platform where that's invalid. > > So I'm pretty sure "if (ret < 0) " is the correct way to write code and > "if (ret <= 0) " is incorrect but generally harmless except perhaps in > limited situations on SPARC or other similar arches. > > regards, > dan carpenter > ~arvind
On Mon, Dec 11, 2017 at 02:37:22PM +0530, Arvind Yadav wrote: > Hi Dan, > > > On Monday 11 December 2017 02:10 PM, Dan Carpenter wrote: > > On Sun, Dec 10, 2017 at 08:10:26AM +0530, arvindY wrote: > > > > > > On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: > > > > On Sat, Dec 09, 2017 at 06:27:32PM +0100, Alexandre Belloni wrote: > > > > > > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > > > > > > > index 5e4fbd2d3479..71fce7c85c93 100644 > > > > > > > --- a/sound/soc/nuc900/nuc900-ac97.c > > > > > > > +++ b/sound/soc/nuc900/nuc900-ac97.c > > > > > > > @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) > > > > > > > goto out; > > > > > > > } > > > > > > > - nuc900_audio->irq_num = platform_get_irq(pdev, 0); > > > > > > > - if (nuc900_audio->irq_num <= 0) { > > > > > > > - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; > > > > > > > + ret = platform_get_irq(pdev, 0); > > > > > > > + if (ret < 0) > > > > > The <= 0 was ok, see: > > > > > https://lkml.org/lkml/2017/11/18/41 > > > > > > > > > Yeah, but is it ever going to return 0? That seems like a design error > > > > and also really crap commenting if so > > > yes, It can return 0 on sprac platform and If you see the return of > > > platform_get_irq() 'return r ? r->start : -ENXIO;'. It should be > > > 'return r && r->start? r->start : -ENXIO;'. We can not add checks here, > > > Because There's a bunch of platforms in the kernel they still use IRQ0 as > > > valid. > > > I have separate mails where few maintainer ask me to add check for 0 and few > > > not. > > > Adding check for 0 will never harm. > > What you're saying doesn't make sense. > I am following a below link. Where they have point out irq 0 is not valid. > https://lwn.net/Articles/470820/ That article is interesting and explains why this stuff is so messed up, but I think my email is correct. No one is going to tell the kernel, "There is an IRQ resource at 0, please store it in r->start. We can't use that IRQ, it's only there to make the kernel crash when people call platform_get_irq()! #geniusidea." There are other IRQ functions like irq_of_parse_and_map() which do return zero on error but platform_get_irq() pretty clearly returns negative error codes. regards, dan carpenter
On 11/12/2017 at 13:27:30 +0300, Dan Carpenter wrote: > On Mon, Dec 11, 2017 at 02:37:22PM +0530, Arvind Yadav wrote: > > Hi Dan, > > > > > > On Monday 11 December 2017 02:10 PM, Dan Carpenter wrote: > > > On Sun, Dec 10, 2017 at 08:10:26AM +0530, arvindY wrote: > > > > > > > > On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: > > > > > On Sat, Dec 09, 2017 at 06:27:32PM +0100, Alexandre Belloni wrote: > > > > > > > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > > > > > > > > index 5e4fbd2d3479..71fce7c85c93 100644 > > > > > > > > --- a/sound/soc/nuc900/nuc900-ac97.c > > > > > > > > +++ b/sound/soc/nuc900/nuc900-ac97.c > > > > > > > > @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) > > > > > > > > goto out; > > > > > > > > } > > > > > > > > - nuc900_audio->irq_num = platform_get_irq(pdev, 0); > > > > > > > > - if (nuc900_audio->irq_num <= 0) { > > > > > > > > - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; > > > > > > > > + ret = platform_get_irq(pdev, 0); > > > > > > > > + if (ret < 0) > > > > > > The <= 0 was ok, see: > > > > > > https://lkml.org/lkml/2017/11/18/41 > > > > > > > > > > > Yeah, but is it ever going to return 0? That seems like a design error > > > > > and also really crap commenting if so > > > > yes, It can return 0 on sprac platform and If you see the return of > > > > platform_get_irq() 'return r ? r->start : -ENXIO;'. It should be > > > > 'return r && r->start? r->start : -ENXIO;'. We can not add checks here, > > > > Because There's a bunch of platforms in the kernel they still use IRQ0 as > > > > valid. > > > > I have separate mails where few maintainer ask me to add check for 0 and few > > > > not. > > > > Adding check for 0 will never harm. > > > What you're saying doesn't make sense. > > I am following a below link. Where they have point out irq 0 is not valid. > > https://lwn.net/Articles/470820/ > > That article is interesting and explains why this stuff is so messed up, > but I think my email is correct. No one is going to tell the kernel, > "There is an IRQ resource at 0, please store it in r->start. We can't > use that IRQ, it's only there to make the kernel crash when people call > platform_get_irq()! #geniusidea." > > There are other IRQ functions like irq_of_parse_and_map() which do > return zero on error but platform_get_irq() pretty clearly returns > negative error codes. > > regards, > dan carpenter > Maybe the good thing to do is to actaully leave the nuc900 code alone instead of trying to change something that never failed and that doesn't seem to interest anyone anymore (else the platform would have been converted to DT).
On Mon, Dec 11, 2017 at 12:49:50PM +0100, Alexandre Belloni wrote: > Maybe the good thing to do is to actaully leave the nuc900 code alone > instead of trying to change something that never failed and that doesn't > seem to interest anyone anymore (else the platform would have been > converted to DT). > I don't know. The bug is less than a month old and this discussion has been useful for me as I review any platform_get_irq() changes sent to staging. regards, dan carpenter
On Mon, Dec 11, 2017 at 12:49:50PM +0100, Alexandre Belloni wrote: > Maybe the good thing to do is to actaully leave the nuc900 code alone > instead of trying to change something that never failed and that doesn't > seem to interest anyone anymore (else the platform would have been > converted to DT). Yes, this definitely seems like far more trouble than it's worth.
On 11/12/2017 at 15:01:29 +0300, Dan Carpenter wrote: > On Mon, Dec 11, 2017 at 12:49:50PM +0100, Alexandre Belloni wrote: > > Maybe the good thing to do is to actaully leave the nuc900 code alone > > instead of trying to change something that never failed and that doesn't > > seem to interest anyone anymore (else the platform would have been > > converted to DT). > > > > I don't know. The bug is less than a month old and this discussion has > been useful for me as I review any platform_get_irq() changes sent to > staging. > What I meant is that the original code before this "fix" was more that 7 years old and nobody ever had any issues. And that's because getting that IRQ on that platform will simply never fail. Also, I really doubt anybody is going to copy paste from the nuc900-ac97 driver so I'm really wondering whether it is worth fixing this non-issue.
diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c index 5e4fbd2d3479..71fce7c85c93 100644 --- a/sound/soc/nuc900/nuc900-ac97.c +++ b/sound/soc/nuc900/nuc900-ac97.c @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) goto out; } - nuc900_audio->irq_num = platform_get_irq(pdev, 0); - if (nuc900_audio->irq_num <= 0) { - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; + ret = platform_get_irq(pdev, 0); + if (ret < 0) goto out; - } + nuc900_audio->irq_num = ret; nuc900_ac97_data = nuc900_audio;
The error handling doesn't work here because "nuc900_audio->irq_num" is unsigned. Also we should be checking for < 0 and not <= 0 but I believe that's harmless. The platform_get_irq() comments don't talk about the return values... Fixes: fa8cc38165c2 ("ASoC: nuc900: Fix platform_get_irq's error checking") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>