[alsa-devel] [PATCH 1/2] ASoC: nuc900: Fix platform_get_irq() error checking some more
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> 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;
We should be finishing the loop with timeout set to zero but because this is a post-op we finish with timeout == -1. Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> --- I sent this one in July but it was missed somehow. diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c index 71fce7c85c93..81b09d740ed9 100644 --- a/sound/soc/nuc900/nuc900-ac97.c +++ b/sound/soc/nuc900/nuc900-ac97.c @@ -67,7 +67,7 @@ static unsigned short nuc900_ac97_read(struct snd_ac97 *ac97, /* polling the AC_R_FINISH */ while (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_R_FINISH) - && timeout--) + && --timeout) mdelay(1); if (!timeout) { @@ -121,7 +121,7 @@ static void nuc900_ac97_write(struct snd_ac97 *ac97, unsigned short reg, /* polling the AC_W_FINISH */ while ((AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_W_FINISH) - && timeout--) + && --timeout) mdelay(1); if (!timeout)
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 -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
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 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
On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: 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 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
On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: 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 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
On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: 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 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
On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: 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 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
On Sunday 10 December 2017 07:22 AM, Dan Carpenter wrote: 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). -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
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 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. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
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.
The patch ASoC: nuc900: Fix platform_get_irq() error checking some more has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
From cd430a244cd5d3ca0f4053718eabdf42bc12c517 Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter@oracle.com> Date: Sat, 9 Dec 2017 14:52:03 +0300 Subject: [PATCH] ASoC: nuc900: Fix platform_get_irq() error checking some more
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> Signed-off-by: Mark Brown <broonie@kernel.org> --- sound/soc/nuc900/nuc900-ac97.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) 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; -- 2.15.1
participants (5)
-
Alexandre Belloni -
Arvind Yadav -
arvindY
-
Dan Carpenter -
Mark Brown