All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] drivers: net: cpsw: fix error return code
Date: Sat, 26 Dec 2015 19:51:30 +0000	[thread overview]
Message-ID: <567EEFC2.4080800@cogentembedded.com> (raw)
In-Reply-To: <567ED36A.9000701@cogentembedded.com>

Hello.

On 12/26/2015 08:50 PM, Sergei Shtylyov wrote:

>>>> diff --git a/drivers/net/ethernet/ti/cpsw.c
>>>> b/drivers/net/ethernet/ti/cpsw.c
>>>> index 3409e80..6a76992 100644
>>>> --- a/drivers/net/ethernet/ti/cpsw.c
>>>> +++ b/drivers/net/ethernet/ti/cpsw.c
>>>> @@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev)
>>>>
>>>>        /* RX IRQ */
>>>>        irq = platform_get_irq(pdev, 1);
>>>> -    if (irq < 0)
>>>> +    if (irq < 0) {
>>>> +        ret = -ENOENT;
>>>
>>>     Why not just propagate an error returned by that function?
>>
>> OK, I did what was done a few lines before in the same function:
>>
>>          ndev->irq = platform_get_irq(pdev, 1);
>>          if (ndev->irq < 0) {
>>         dev_err(priv->dev, "error getting irq resource\n");
>>                  ret = -ENOENT;
>>                  goto clean_ale_ret;
>>          }
>>
>> Maybe they should all be changed?
>
>     Yeah, I'd vote for it. I'm seeing no sense in overriding an actual error.

    Hm, I decided to check drivers/base/dd.c and I think I maybe know the 
reason now: -ENXIO, usually returned by platform_get_irq(), is silently 
"swallowed" by really_probe(); to be precise, -ENODEV and -ENXIO are only 
reported with pr_debug(), while -ENOENT causes printk(KERN_WARNING, ...)...

> [...]
>
>> julia

MBR, Sergei


WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] drivers: net: cpsw: fix error return code
Date: Sat, 26 Dec 2015 22:51:30 +0300	[thread overview]
Message-ID: <567EEFC2.4080800@cogentembedded.com> (raw)
In-Reply-To: <567ED36A.9000701@cogentembedded.com>

Hello.

On 12/26/2015 08:50 PM, Sergei Shtylyov wrote:

>>>> diff --git a/drivers/net/ethernet/ti/cpsw.c
>>>> b/drivers/net/ethernet/ti/cpsw.c
>>>> index 3409e80..6a76992 100644
>>>> --- a/drivers/net/ethernet/ti/cpsw.c
>>>> +++ b/drivers/net/ethernet/ti/cpsw.c
>>>> @@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev)
>>>>
>>>>        /* RX IRQ */
>>>>        irq = platform_get_irq(pdev, 1);
>>>> -    if (irq < 0)
>>>> +    if (irq < 0) {
>>>> +        ret = -ENOENT;
>>>
>>>     Why not just propagate an error returned by that function?
>>
>> OK, I did what was done a few lines before in the same function:
>>
>>          ndev->irq = platform_get_irq(pdev, 1);
>>          if (ndev->irq < 0) {
>>         dev_err(priv->dev, "error getting irq resource\n");
>>                  ret = -ENOENT;
>>                  goto clean_ale_ret;
>>          }
>>
>> Maybe they should all be changed?
>
>     Yeah, I'd vote for it. I'm seeing no sense in overriding an actual error.

    Hm, I decided to check drivers/base/dd.c and I think I maybe know the 
reason now: -ENXIO, usually returned by platform_get_irq(), is silently 
"swallowed" by really_probe(); to be precise, -ENODEV and -ENXIO are only 
reported with pr_debug(), while -ENOENT causes printk(KERN_WARNING, ...)...

> [...]
>
>> julia

MBR, Sergei


  parent reply	other threads:[~2015-12-26 19:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-26 15:28 [PATCH 0/7] fix error return code Julia Lawall
2015-12-26 15:28 ` Julia Lawall
2015-12-26 15:28 ` Julia Lawall
2015-12-26 15:28 ` Julia Lawall
2015-12-26 15:28 ` [PATCH 1/7] umem: " Julia Lawall
2015-12-26 15:28   ` Julia Lawall
2015-12-26 15:28 ` [PATCH 2/7] gdrom: " Julia Lawall
2015-12-26 15:28   ` Julia Lawall
2015-12-26 15:28 ` [PATCH 3/7] omapfb: " Julia Lawall
2015-12-26 15:28   ` Julia Lawall
2015-12-29  9:06   ` Tomi Valkeinen
2015-12-29  9:06     ` Tomi Valkeinen
2015-12-29  9:06     ` Tomi Valkeinen
2015-12-26 15:28 ` [PATCH 4/7] usb: gadget: legacy: " Julia Lawall
2015-12-26 15:28   ` Julia Lawall
2015-12-26 15:28 ` [PATCH 5/7] rsxx: " Julia Lawall
2015-12-26 15:28   ` Julia Lawall
2015-12-26 15:28 ` [PATCH 6/7] drivers: net: cpsw: " Julia Lawall
2015-12-26 15:28   ` Julia Lawall
2015-12-26 17:36   ` Sergei Shtylyov
2015-12-26 17:36     ` Sergei Shtylyov
2015-12-26 17:40     ` Julia Lawall
2015-12-26 17:40       ` Julia Lawall
2015-12-26 17:50       ` Sergei Shtylyov
2015-12-26 17:50         ` Sergei Shtylyov
2015-12-26 19:12         ` [PATCH 6/7 v2] " Julia Lawall
2015-12-26 19:12           ` Julia Lawall
2015-12-26 19:51         ` Sergei Shtylyov [this message]
2015-12-26 19:51           ` [PATCH 6/7] " Sergei Shtylyov
2015-12-26 20:07           ` Julia Lawall
2015-12-26 20:07             ` Julia Lawall
2015-12-26 20:11             ` Sergei Shtylyov
2015-12-26 20:11               ` Sergei Shtylyov
2015-12-26 15:28 ` [PATCH 7/7] soc: ti: " Julia Lawall
2015-12-26 15:28   ` Julia Lawall
2015-12-26 15:28   ` Julia Lawall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=567EEFC2.4080800@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=julia.lawall@lip6.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.