From: David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: frowand.list-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 18:40:28 -0700 [thread overview]
Message-ID: <55EA480C.6090306@gmail.com> (raw)
In-Reply-To: <55EA41E3.5010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.
The additional change on top of my patch would be to add a comment
describing this behavior.
David Daney.
> A more robust solution would be something like:
>
>
> (1) Change of_irq_parse_pci() to _of_irq_parse_pci(), adding an argument and
> use it to report the case of PCI_INTERRUPT_PIN == 0.
>
> static int _of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq, int *no_pin)
> {
>
> ...
> *no_pin = 0;
> ...
> /* No pin, exit */
> if (pin == 0) {
> *no_pin = 1;
> return -ENODEV;
> }
> ...
>
>
> int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
> {
> int no_pin;
> return _of_irq_parse_pci(pdev, out_irq, &no_pin)
> }
>
>
> (2) Then the fix to of_irq_parse_and_map_pci() would be:
>
> + int no_pin;
>> ret = of_irq_parse_pci(dev, &oirq, &no_pin);
>> if (ret) {
>> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", ret);
>> + if (!no_pin)
>> + dev_err(&dev->dev,
>> + "of_irq_parse_pci() failed with rc=%d\n", ret);
>> return 0; /* Proper return code 0 == NO_IRQ */
>> }
>
>
> I'm not sure I like my solution, there might be a better way.
>
> I also noticed another bug while looking at of_irq_parse_pci(). It returns
> the non-zero return value from pci_read_config_byte(). But that value is
> one of the PCI function error values from include/linux/pci.h, such as:
>
> #define PCIBIOS_BAD_REGISTER_NUMBER 0x87
>
> instead of a negative errno.
>
>
> -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: David Daney <ddaney.cavm@gmail.com>
To: frowand.list@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 18:40:28 -0700 [thread overview]
Message-ID: <55EA480C.6090306@gmail.com> (raw)
In-Reply-To: <55EA41E3.5010103@gmail.com>
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.
The additional change on top of my patch would be to add a comment
describing this behavior.
David Daney.
> A more robust solution would be something like:
>
>
> (1) Change of_irq_parse_pci() to _of_irq_parse_pci(), adding an argument and
> use it to report the case of PCI_INTERRUPT_PIN == 0.
>
> static int _of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq, int *no_pin)
> {
>
> ...
> *no_pin = 0;
> ...
> /* No pin, exit */
> if (pin == 0) {
> *no_pin = 1;
> return -ENODEV;
> }
> ...
>
>
> int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
> {
> int no_pin;
> return _of_irq_parse_pci(pdev, out_irq, &no_pin)
> }
>
>
> (2) Then the fix to of_irq_parse_and_map_pci() would be:
>
> + int no_pin;
>> ret = of_irq_parse_pci(dev, &oirq, &no_pin);
>> if (ret) {
>> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", ret);
>> + if (!no_pin)
>> + dev_err(&dev->dev,
>> + "of_irq_parse_pci() failed with rc=%d\n", ret);
>> return 0; /* Proper return code 0 == NO_IRQ */
>> }
>
>
> I'm not sure I like my solution, there might be a better way.
>
> I also noticed another bug while looking at of_irq_parse_pci(). It returns
> the non-zero return value from pci_read_config_byte(). But that value is
> one of the PCI function error values from include/linux/pci.h, such as:
>
> #define PCIBIOS_BAD_REGISTER_NUMBER 0x87
>
> instead of a negative errno.
>
>
> -Frank
>
next prev parent reply other threads:[~2015-09-05 1:40 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 [this message]
2015-09-05 1:40 ` David Daney
[not found] ` <55EA480C.6090306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-09-05 2:38 ` Frank Rowand
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=55EA480C.6090306@gmail.com \
--to=ddaney.cavm-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@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.