* [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. @ 2015-09-04 19:12 David Daney [not found] ` <1441393926-23225-1-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 8+ messages in thread From: David Daney @ 2015-09-04 19:12 UTC (permalink / raw) To: devicetree, linux-kernel, Rob Herring, Frank Rowand, Grant Likely Cc: David Daney 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 */ } -- 1.7.11.7 ^ permalink raw reply related [flat|nested] 8+ messages in thread
[parent not found: <1441393926-23225-1-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. [not found] ` <1441393926-23225-1-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2015-09-05 1:14 ` Frank Rowand [not found] ` <55EA41E3.5010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 8+ messages in thread From: Frank Rowand @ 2015-09-05 1:14 UTC (permalink / raw) To: David Daney Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Grant Likely, David Daney 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. 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <55EA41E3.5010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. [not found] ` <55EA41E3.5010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2015-09-05 1:40 ` David Daney [not found] ` <55EA480C.6090306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-09-06 20:46 ` Rob Herring 1 sibling, 1 reply; 8+ messages in thread From: David Daney @ 2015-09-05 1:40 UTC (permalink / raw) To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Grant Likely, David Daney 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <55EA480C.6090306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. [not found] ` <55EA480C.6090306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2015-09-05 2:38 ` Frank Rowand 0 siblings, 0 replies; 8+ messages in thread From: Frank Rowand @ 2015-09-05 2:38 UTC (permalink / raw) To: David Daney Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Grant Likely, David Daney 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. [not found] ` <55EA41E3.5010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-09-05 1:40 ` David Daney @ 2015-09-06 20:46 ` Rob Herring [not found] ` <CAL_JsqK0uW4F7HAcUMSQ-2wCvp_i3a5MTxsyW3XerHAxBrW=SQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 1 reply; 8+ messages in thread From: Rob Herring @ 2015-09-06 20:46 UTC (permalink / raw) To: Frank Rowand Cc: David Daney, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Grant Likely, David Daney On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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. Yes, but we're talking about a print statement. > > 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 don't like it. That's way too complex for just silencing an erroneous error message. Perhaps just move the error message into of_irq_parse_pci and then you can control the print more easily. Or just change to dev_dbg would be okay by me. > 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. I was puzzled by why this is not standard error codes a while back. My best guess is that that there is some legacy here. Changing error values on widely used functions is impossible to audit. NO_IRQ being 0 or -1 is one such case. Rob -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <CAL_JsqK0uW4F7HAcUMSQ-2wCvp_i3a5MTxsyW3XerHAxBrW=SQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. [not found] ` <CAL_JsqK0uW4F7HAcUMSQ-2wCvp_i3a5MTxsyW3XerHAxBrW=SQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-09-07 2:16 ` Frank Rowand 2015-09-07 3:50 ` Frank Rowand 0 siblings, 1 reply; 8+ messages in thread From: Frank Rowand @ 2015-09-07 2:16 UTC (permalink / raw) To: Rob Herring Cc: David Daney, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Grant Likely, David Daney On 9/6/2015 1:46 PM, Rob Herring wrote: > On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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. > > Yes, but we're talking about a print statement. > >> >> A more robust solution would be something like: < snip my bad solution > >> I'm not sure I like my solution, there might be a better way. > > I don't like it. That's way too complex for just silencing an > erroneous error message. > > Perhaps just move the error message into of_irq_parse_pci and then you > can control the print more easily. Or just change to dev_dbg would be > okay by me. I knew I was making it way too hard. Yes, just move the error message to of_irq_parse_pci(), where the "/* No pin, exit */" test occurs. >> 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. > > I was puzzled by why this is not standard error codes a while back. My > best guess is that that there is some legacy here. Changing error > values on widely used functions is impossible to audit. NO_IRQ being 0 > or -1 is one such case. > > Rob > -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. 2015-09-07 2:16 ` Frank Rowand @ 2015-09-07 3:50 ` Frank Rowand 2015-09-07 23:44 ` Frank Rowand 0 siblings, 1 reply; 8+ messages in thread From: Frank Rowand @ 2015-09-07 3:50 UTC (permalink / raw) To: frowand.list Cc: Rob Herring, David Daney, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring, Grant Likely, David Daney On 9/6/2015 7:16 PM, Frank Rowand wrote: > On 9/6/2015 1:46 PM, Rob Herring wrote: >> On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand <frowand.list@gmail.com> 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. >> >> Yes, but we're talking about a print statement. >> >>> >>> A more robust solution would be something like: > > < snip my bad solution > > >>> I'm not sure I like my solution, there might be a better way. >> >> I don't like it. That's way too complex for just silencing an >> erroneous error message. >> >> Perhaps just move the error message into of_irq_parse_pci and then you >> can control the print more easily. Or just change to dev_dbg would be >> okay by me. > > I knew I was making it way too hard. Yes, just move the error message > to of_irq_parse_pci(), where the "/* No pin, exit */" test occurs. And this time I replied too quickly, not really thinking through my comment. There are several error return points in of_irq_parse_pci(), so moving the error message into of_irq_parse_pci() is not the answer. >>> 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. >> >> I was puzzled by why this is not standard error codes a while back. My >> best guess is that that there is some legacy here. Changing error >> values on widely used functions is impossible to audit. NO_IRQ being 0 >> or -1 is one such case. >> >> Rob >> > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. 2015-09-07 3:50 ` Frank Rowand @ 2015-09-07 23:44 ` Frank Rowand 0 siblings, 0 replies; 8+ messages in thread From: Frank Rowand @ 2015-09-07 23:44 UTC (permalink / raw) To: frowand.list Cc: Rob Herring, David Daney, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring, Grant Likely, David Daney On 9/6/2015 8:50 PM, Frank Rowand wrote: > On 9/6/2015 7:16 PM, Frank Rowand wrote: >> On 9/6/2015 1:46 PM, Rob Herring wrote: >>> On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand <frowand.list@gmail.com> 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. >>> >>> Yes, but we're talking about a print statement. >>> >>>> >>>> A more robust solution would be something like: >> >> < snip my bad solution > >> >>>> I'm not sure I like my solution, there might be a better way. >>> >>> I don't like it. That's way too complex for just silencing an >>> erroneous error message. >>> >>> Perhaps just move the error message into of_irq_parse_pci and then you >>> can control the print more easily. Or just change to dev_dbg would be >>> okay by me. >> >> I knew I was making it way too hard. Yes, just move the error message >> to of_irq_parse_pci(), where the "/* No pin, exit */" test occurs. > > And this time I replied too quickly, not really thinking through my comment. > There are several error return points in of_irq_parse_pci(), so moving the > error message into of_irq_parse_pci() is not the answer. is not the answer unless of_irq_parse_pci() is changed over to the single point of return style. I realized I should have typed the whole thought... -Frank ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-09-07 23:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 [not found] ` <55EA41E3.5010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-09-05 1:40 ` David Daney [not found] ` <55EA480C.6090306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-09-05 2:38 ` Frank Rowand 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 3:50 ` Frank Rowand 2015-09-07 23:44 ` Frank Rowand
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).