From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
Date: Fri, 04 Sep 2015 19:38:29 -0700 [thread overview]
Message-ID: <55EA55A5.3030606@gmail.com> (raw)
In-Reply-To: <55EA480C.6090306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 9/4/2015 6:40 PM, David Daney wrote:
> On 09/04/2015 06:14 PM, Frank Rowand wrote:
>> On 9/4/2015 12:12 PM, David Daney wrote:
>>> From: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>>
>>> It is perfectly legitimate for a PCI device to have an
>>> PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
>>> use interrupts, or on PCIe devices, where only MSI/MSI-X are
>>> supported.
>>>
>>> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
>>> messages by making them conditional on !-ENODEV (which can only be
>>> produced in the PCI_INTERRUPT_PIN == 0 case).
>>>
>>> Signed-off-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>> ---
>>> drivers/of/of_pci_irq.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
>>> index 1710d9d..33d242a 100644
>>> --- a/drivers/of/of_pci_irq.c
>>> +++ b/drivers/of/of_pci_irq.c
>>> @@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
>>>
>>> ret = of_irq_parse_pci(dev, &oirq);
>>> if (ret) {
>>> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", ret);
>>> + if (ret != -ENODEV)
>>> + dev_err(&dev->dev,
>>> + "of_irq_parse_pci() failed with rc=%d\n", ret);
>>> return 0; /* Proper return code 0 == NO_IRQ */
>>> }
>>>
>>>
>>
>> It is not safe to assume that the functions that of_irq_parse_pci() calls
>> will never be modified to return -ENODEV, thus resulting in of_irq_parse_pci()
>> returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
>>
>
> Since the current implementation *only ever* returns -ENODEV for PCI_INTERRUPT_PIN == 0, we could just document that behavior, and not hack up the APIs by adding a second return channel from the function.
And for each function that of_irq_parse_pci() calls and returns status from the
function call you would need to document that behavior, and so on recursively.
For example, you would need to document of_irq_parse_one(). And that returns status
from more function calls, so you would need to document of_irq_parse_oldworld(),
of_parse_phandle_with_args(), of_irq_parse_raw(), and then anything they call.
>
> The additional change on top of my patch would be to add a comment describing this behavior.
>
> David Daney.
< snip >
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list@gmail.com>
To: David Daney <ddaney.cavm@gmail.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Grant Likely <grant.likely@linaro.org>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
Date: Fri, 04 Sep 2015 19:38:29 -0700 [thread overview]
Message-ID: <55EA55A5.3030606@gmail.com> (raw)
In-Reply-To: <55EA480C.6090306@gmail.com>
On 9/4/2015 6:40 PM, David Daney wrote:
> On 09/04/2015 06:14 PM, Frank Rowand wrote:
>> On 9/4/2015 12:12 PM, David Daney wrote:
>>> From: David Daney <david.daney@cavium.com>
>>>
>>> It is perfectly legitimate for a PCI device to have an
>>> PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
>>> use interrupts, or on PCIe devices, where only MSI/MSI-X are
>>> supported.
>>>
>>> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
>>> messages by making them conditional on !-ENODEV (which can only be
>>> produced in the PCI_INTERRUPT_PIN == 0 case).
>>>
>>> Signed-off-by: David Daney <david.daney@cavium.com>
>>> ---
>>> drivers/of/of_pci_irq.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
>>> index 1710d9d..33d242a 100644
>>> --- a/drivers/of/of_pci_irq.c
>>> +++ b/drivers/of/of_pci_irq.c
>>> @@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
>>>
>>> ret = of_irq_parse_pci(dev, &oirq);
>>> if (ret) {
>>> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", ret);
>>> + if (ret != -ENODEV)
>>> + dev_err(&dev->dev,
>>> + "of_irq_parse_pci() failed with rc=%d\n", ret);
>>> return 0; /* Proper return code 0 == NO_IRQ */
>>> }
>>>
>>>
>>
>> It is not safe to assume that the functions that of_irq_parse_pci() calls
>> will never be modified to return -ENODEV, thus resulting in of_irq_parse_pci()
>> returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
>>
>
> Since the current implementation *only ever* returns -ENODEV for PCI_INTERRUPT_PIN == 0, we could just document that behavior, and not hack up the APIs by adding a second return channel from the function.
And for each function that of_irq_parse_pci() calls and returns status from the
function call you would need to document that behavior, and so on recursively.
For example, you would need to document of_irq_parse_one(). And that returns status
from more function calls, so you would need to document of_irq_parse_oldworld(),
of_parse_phandle_with_args(), of_irq_parse_raw(), and then anything they call.
>
> The additional change on top of my patch would be to add a comment describing this behavior.
>
> David Daney.
< snip >
-Frank
next prev parent reply other threads:[~2015-09-05 2:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 19:12 [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages David Daney
[not found] ` <1441393926-23225-1-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-09-05 1:14 ` Frank Rowand
2015-09-05 1:14 ` Frank Rowand
[not found] ` <55EA41E3.5010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-09-05 1:40 ` David Daney
2015-09-05 1:40 ` David Daney
[not found] ` <55EA480C.6090306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-09-05 2:38 ` Frank Rowand [this message]
2015-09-05 2:38 ` Frank Rowand
2015-09-06 20:46 ` Rob Herring
2015-09-06 20:46 ` Rob Herring
[not found] ` <CAL_JsqK0uW4F7HAcUMSQ-2wCvp_i3a5MTxsyW3XerHAxBrW=SQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-07 2:16 ` Frank Rowand
2015-09-07 2:16 ` Frank Rowand
2015-09-07 3:50 ` Frank Rowand
2015-09-07 23:44 ` Frank Rowand
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=55EA55A5.3030606@gmail.com \
--to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org \
--cc=ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.