| Message ID | b773b3b1ed25a0e6d5d826b6c43293473cbd24e7.1583952276.git.amanharitsh123@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Handled return value of platform_get_irq correctly | expand |
On 11/03/2020 20:19, Aman Sharma wrote: > diff --git a/drivers/pci/controller/pcie-tango.c b/drivers/pci/controller/pcie-tango.c > index 21a208da3f59..18c2c4313eb5 100644 > --- a/drivers/pci/controller/pcie-tango.c > +++ b/drivers/pci/controller/pcie-tango.c > @@ -273,9 +273,9 @@ static int tango_pcie_probe(struct platform_device *pdev) > writel_relaxed(0, pcie->base + SMP8759_ENABLE + offset); > > virq = platform_get_irq(pdev, 1); > - if (virq <= 0) { > + if (virq < 0) { > dev_err(dev, "Failed to map IRQ\n"); > - return -ENXIO; > + return virq; > } > > irq_dom = irq_domain_create_linear(fwnode, MSI_MAX, &dom_ops, pcie); Weee, here we go again :-) https://patchwork.kernel.org/patch/11066455/ https://patchwork.kernel.org/patch/10006651/ Last time around, my understanding was that, going forward, the best solution was: virq = platform_get_irq(...) if (virq <= 0) return virq ? : -ENODEV; i.e. map 0 to -ENODEV, pass other errors as-is, remove the dev_err @Bjorn/Lorenzo did you have a change of heart? Regards.
[+cc another Marc] On Thu, Mar 12, 2020 at 10:53:06AM +0100, Marc Gonzalez wrote: > On 11/03/2020 20:19, Aman Sharma wrote: > > > diff --git a/drivers/pci/controller/pcie-tango.c b/drivers/pci/controller/pcie-tango.c > > index 21a208da3f59..18c2c4313eb5 100644 > > --- a/drivers/pci/controller/pcie-tango.c > > +++ b/drivers/pci/controller/pcie-tango.c > > @@ -273,9 +273,9 @@ static int tango_pcie_probe(struct platform_device *pdev) > > writel_relaxed(0, pcie->base + SMP8759_ENABLE + offset); > > > > virq = platform_get_irq(pdev, 1); > > - if (virq <= 0) { > > + if (virq < 0) { > > dev_err(dev, "Failed to map IRQ\n"); > > - return -ENXIO; > > + return virq; > > } > > > > irq_dom = irq_domain_create_linear(fwnode, MSI_MAX, &dom_ops, pcie); > > Weee, here we go again :-) > > https://patchwork.kernel.org/patch/11066455/ > https://patchwork.kernel.org/patch/10006651/ > > Last time around, my understanding was that, going forward, > the best solution was: > > virq = platform_get_irq(...) > if (virq <= 0) > return virq ? : -ENODEV; > > i.e. map 0 to -ENODEV, pass other errors as-is, remove the dev_err > > @Bjorn/Lorenzo did you have a change of heart? Yes. In 10006651 (Oct 20, 2017), I thought: irq = platform_get_irq(pdev, 0); if (irq <= 0) return -ENODEV; was fine. In 11066455 (Aug 7, 2019), I said I thought I was wrong and that: platform_get_irq() is a generic interface and we have to be able to interpret return values consistently. The overwhelming consensus among platform_get_irq() callers is to treat "irq < 0" as an error, and I think we should follow suit. ... I think the best pattern is: irq = platform_get_irq(pdev, i); if (irq < 0) return irq; I still think what I said in 2019 is the right approach. I do see your comment in 10006651 about this pattern: if (virq <= 0) return virq ? : -ENODEV; but IMHO it's too complicated for general use. Admittedly, it's not *very* complicated, but it's a relatively unusual C idiom and I stumble over it every time I see it. If 0 is a special case I think it should be mapped to a negative error in arch-specific code, which I think is what Linus T suggested in [1]. I think there's still a large consensus that "irq < 0" is the error case. In the tree today we have about 1400 callers of platform_get_irq() and platform_get_irq_byname() [2]. Of those, almost 900 check for "irq < 0" [3], while only about 150 check for "irq <= 0" [4] and about 15 use some variant of a "irq ? : -ENODEV" pattern. The bottom line is that in drivers/pci, I'd like to see either a single style or a compelling argument for why some checks should be "irq < 0" and others should be "irq <= 0". [1] https://yarchive.net/comp/linux/zero.html [2] $ git grep "=.*platform_get_irq" | wc -l 1422 [3] $ git grep -A4 "=.*platform_get_irq" | grep "<\s*0" | wc -l 894 [4] $ git grep -A4 "=.*platform_get_irq" | grep "<=\s*0" | wc -l 151 [5] $ git grep -A4 "=.*platform_get_irq" | grep "return.*?.*:.*;" | wc -l 15
On 12/03/2020 15:11, Bjorn Helgaas wrote: > [+cc another Marc] Doh! I should indeed have CCed maz and tglx. > On Thu, Mar 12, 2020 at 10:53:06AM +0100, Marc Gonzalez wrote: > >> On 11/03/2020 20:19, Aman Sharma wrote: >> >>> diff --git a/drivers/pci/controller/pcie-tango.c b/drivers/pci/controller/pcie-tango.c >>> index 21a208da3f59..18c2c4313eb5 100644 >>> --- a/drivers/pci/controller/pcie-tango.c >>> +++ b/drivers/pci/controller/pcie-tango.c >>> @@ -273,9 +273,9 @@ static int tango_pcie_probe(struct platform_device *pdev) >>> writel_relaxed(0, pcie->base + SMP8759_ENABLE + offset); >>> >>> virq = platform_get_irq(pdev, 1); >>> - if (virq <= 0) { >>> + if (virq < 0) { >>> dev_err(dev, "Failed to map IRQ\n"); >>> - return -ENXIO; >>> + return virq; >>> } >>> >>> irq_dom = irq_domain_create_linear(fwnode, MSI_MAX, &dom_ops, pcie); >> >> Weee, here we go again :-) >> >> https://patchwork.kernel.org/patch/11066455/ >> https://patchwork.kernel.org/patch/10006651/ >> >> Last time around, my understanding was that, going forward, >> the best solution was: >> >> virq = platform_get_irq(...) >> if (virq <= 0) >> return virq ? : -ENODEV; >> >> i.e. map 0 to -ENODEV, pass other errors as-is, remove the dev_err >> >> @Bjorn/Lorenzo did you have a change of heart? > > Yes. In 10006651 (Oct 20, 2017), I thought: > > irq = platform_get_irq(pdev, 0); > if (irq <= 0) > return -ENODEV; > > was fine. In 11066455 (Aug 7, 2019), I said I thought I was wrong and > that: > > platform_get_irq() is a generic interface and we have to be able to > interpret return values consistently. The overwhelming consensus > among platform_get_irq() callers is to treat "irq < 0" as an error, > and I think we should follow suit. > ... > I think the best pattern is: > > irq = platform_get_irq(pdev, i); > if (irq < 0) > return irq; > > I still think what I said in 2019 is the right approach. I do see > your comment in 10006651 about this pattern: > > if (virq <= 0) > return virq ? : -ENODEV; > > but IMHO it's too complicated for general use. Admittedly, it's not > *very* complicated, but it's a relatively unusual C idiom and I > stumble over it every time I see it. FTR, omitting the middle operand is a GNU extension. https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html The valid C idiom would be virq ? virq : -ENODEV > If 0 is a special case I think > it should be mapped to a negative error in arch-specific code, which I > think is what Linus T suggested in [1]. Lorenzo, being both PCI maintainer and ARM employee should be in a good position to change the arch-specific code for arm and arm64? > I think there's still a large consensus that "irq < 0" is the error > case. In the tree today we have about 1400 callers of > platform_get_irq() and platform_get_irq_byname() [2]. Of those, > almost 900 check for "irq < 0" [3], while only about 150 check for > "irq <= 0" [4] and about 15 use some variant of a "irq ? : -ENODEV" > pattern. > > The bottom line is that in drivers/pci, I'd like to see either a > single style or a compelling argument for why some checks should be > "irq < 0" and others should be "irq <= 0". > > [1] https://yarchive.net/comp/linux/zero.html > [2] $ git grep "=.*platform_get_irq" | wc -l > 1422 > [3] $ git grep -A4 "=.*platform_get_irq" | grep "<\s*0" | wc -l > 894 > [4] $ git grep -A4 "=.*platform_get_irq" | grep "<=\s*0" | wc -l > 151 > [5] $ git grep -A4 "=.*platform_get_irq" | grep "return.*?.*:.*;" | wc -l > 15 Interesting stats, thanks. Regards.
Bjorn, Bjorn Helgaas <helgaas@kernel.org> writes: > On Thu, Mar 12, 2020 at 10:53:06AM +0100, Marc Gonzalez wrote: >> Last time around, my understanding was that, going forward, >> the best solution was: >> >> virq = platform_get_irq(...) >> if (virq <= 0) >> return virq ? : -ENODEV; >> >> i.e. map 0 to -ENODEV, pass other errors as-is, remove the dev_err >> >> @Bjorn/Lorenzo did you have a change of heart? > > Yes. In 10006651 (Oct 20, 2017), I thought: > > irq = platform_get_irq(pdev, 0); > if (irq <= 0) > return -ENODEV; > > was fine. In 11066455 (Aug 7, 2019), I said I thought I was wrong and > that: > > platform_get_irq() is a generic interface and we have to be able to > interpret return values consistently. The overwhelming consensus > among platform_get_irq() callers is to treat "irq < 0" as an error, > and I think we should follow suit. > ... > I think the best pattern is: > > irq = platform_get_irq(pdev, i); > if (irq < 0) > return irq; Careful. 0 is not a valid interrupt. Thanks, tglx
On Fri, Mar 13, 2020 at 10:05:58PM +0100, Thomas Gleixner wrote: > Bjorn Helgaas <helgaas@kernel.org> writes: > > On Thu, Mar 12, 2020 at 10:53:06AM +0100, Marc Gonzalez wrote: > >> Last time around, my understanding was that, going forward, > >> the best solution was: > >> > >> virq = platform_get_irq(...) > >> if (virq <= 0) > >> return virq ? : -ENODEV; > >> > >> i.e. map 0 to -ENODEV, pass other errors as-is, remove the dev_err > >> > >> @Bjorn/Lorenzo did you have a change of heart? > > > > Yes. In 10006651 (Oct 20, 2017), I thought: > > > > irq = platform_get_irq(pdev, 0); > > if (irq <= 0) > > return -ENODEV; > > > > was fine. In 11066455 (Aug 7, 2019), I said I thought I was wrong and > > that: > > > > platform_get_irq() is a generic interface and we have to be able to > > interpret return values consistently. The overwhelming consensus > > among platform_get_irq() callers is to treat "irq < 0" as an error, > > and I think we should follow suit. > > ... > > I think the best pattern is: > > > > irq = platform_get_irq(pdev, i); > > if (irq < 0) > > return irq; > > Careful. 0 is not a valid interrupt. Should callers of platform_get_irq() check for a 0 return value? About 900 of them do not. Or should platform_get_irq() return a negative error instead of 0? If 0 is not a valid interrupt, I think it would be easier to use the interface if we made it so platform_get_irq() could never return 0, which I think would also fit the interface documentation better: * Return: IRQ number on success, negative error number on failure. Bjorn
On Fri, Mar 13, 2020 at 04:56:42PM -0500, Bjorn Helgaas wrote: > On Fri, Mar 13, 2020 at 10:05:58PM +0100, Thomas Gleixner wrote: > > Bjorn Helgaas <helgaas@kernel.org> writes: > > > On Thu, Mar 12, 2020 at 10:53:06AM +0100, Marc Gonzalez wrote: > > >> Last time around, my understanding was that, going forward, > > >> the best solution was: > > >> > > >> virq = platform_get_irq(...) > > >> if (virq <= 0) > > >> return virq ? : -ENODEV; > > >> > > >> i.e. map 0 to -ENODEV, pass other errors as-is, remove the dev_err > > >> > > >> @Bjorn/Lorenzo did you have a change of heart? > > > > > > Yes. In 10006651 (Oct 20, 2017), I thought: > > > > > > irq = platform_get_irq(pdev, 0); > > > if (irq <= 0) > > > return -ENODEV; > > > > > > was fine. In 11066455 (Aug 7, 2019), I said I thought I was wrong and > > > that: > > > > > > platform_get_irq() is a generic interface and we have to be able to > > > interpret return values consistently. The overwhelming consensus > > > among platform_get_irq() callers is to treat "irq < 0" as an error, > > > and I think we should follow suit. > > > ... > > > I think the best pattern is: > > > > > > irq = platform_get_irq(pdev, i); > > > if (irq < 0) > > > return irq; > > > > Careful. 0 is not a valid interrupt. > > Should callers of platform_get_irq() check for a 0 return value? > About 900 of them do not. > > Or should platform_get_irq() return a negative error instead of 0? > If 0 is not a valid interrupt, I think it would be easier to use the > interface if we made it so platform_get_irq() could never return 0, > which I think would also fit the interface documentation better: > > * Return: IRQ number on success, negative error number on failure. Trying again -- I'm not quite catching your meaning, Thomas. If platform_get_irq*() can return 0, but 0 is not a valid IRQ, I think it's sort of complicated to parse that return value. Drivers that require an IRQ would do this: irq = platform_get_irq(pdev, i); if (irq < 0) return irq; if (irq == 0) return -EINVAL; # error since driver requires IRQ return devm_request_irq(dev, irq, ...); Drivers that can either use an IRQ or do polling would do this: irq = platform_get_irq(pdev, i); if (irq <= 0) return setup_polling(); return devm_request_irq(dev, irq, ...); I think those are sort of ungainly, especially the first. If we made it so those functions never returned 0, drivers that need an IRQ could do this: irq = platform_get_irq(pdev, i); if (irq < 0) return irq; return devm_request_irq(dev, irq, ...); and drivers that support polling could do this: irq = platform_get_irq(pdev, i); if (irq < 0) return setup_polling(); return devm_request_irq(dev, irq, ...); That seems a lot easier to get correct, and it matches what most of the callers already do.
Bjorn, Bjorn Helgaas <helgaas@kernel.org> writes: > On Fri, Mar 13, 2020 at 04:56:42PM -0500, Bjorn Helgaas wrote: >> On Fri, Mar 13, 2020 at 10:05:58PM +0100, Thomas Gleixner wrote: >> > > I think the best pattern is: >> > > >> > > irq = platform_get_irq(pdev, i); >> > > if (irq < 0) >> > > return irq; >> > >> > Careful. 0 is not a valid interrupt. >> >> Should callers of platform_get_irq() check for a 0 return value? >> About 900 of them do not. I don't know what I was looking at. platform_get_irq() does the right thing already, so checking for irq < 0 is sufficient. Sorry for the confusion! Thanks, tglx
On Wed, Mar 18, 2020 at 02:42:48PM +0100, Thomas Gleixner wrote: > Bjorn Helgaas <helgaas@kernel.org> writes: > > On Fri, Mar 13, 2020 at 04:56:42PM -0500, Bjorn Helgaas wrote: > >> On Fri, Mar 13, 2020 at 10:05:58PM +0100, Thomas Gleixner wrote: > >> > > I think the best pattern is: > >> > > > >> > > irq = platform_get_irq(pdev, i); > >> > > if (irq < 0) > >> > > return irq; > >> > > >> > Careful. 0 is not a valid interrupt. > >> > >> Should callers of platform_get_irq() check for a 0 return value? > >> About 900 of them do not. > > I don't know what I was looking at. > > platform_get_irq() does the right thing already, so checking for irq < 0 > is sufficient. > > Sorry for the confusion! Thanks, I was indeed confused! Maybe we could reduce future confusion by strengthening the comments slightly, e.g., - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. I don't want to push my luck, but it's pretty hard to prove that platform_get_irq() never returns 0. What would you think of something like the following? @@ -133,23 +133,24 @@ EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_byname); * if (irq < 0) * return irq; * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) { + int ret; #ifdef CONFIG_SPARC /* sparc does not have irqs represented as IORESOURCE_IRQ resources */ if (!dev || num >= dev->archdata.num_irqs) return -ENXIO; - return dev->archdata.irqs[num]; + ret = dev->archdata.irqs[num]; + goto out; #else struct resource *r; - int ret; if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) { ret = of_irq_get(dev->dev.of_node, num); if (ret > 0 || ret == -EPROBE_DEFER) - return ret; + goto out; } r = platform_get_resource(dev, IORESOURCE_IRQ, num); @@ -157,7 +158,7 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) if (r && r->flags & IORESOURCE_DISABLED) { ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r); if (ret) - return ret; + goto out; } } @@ -171,13 +172,17 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) struct irq_data *irqd; irqd = irq_get_irq_data(r->start); - if (!irqd) - return -ENXIO; + if (!irqd) { + ret = -ENXIO; + goto out; + } irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS); } - if (r) - return r->start; + if (r) { + ret = r->start; + goto out; + } /* * For the index 0 interrupt, allow falling back to GpioInt @@ -190,11 +195,14 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num); /* Our callers expect -ENXIO for missing IRQs. */ if (ret >= 0 || ret == -EPROBE_DEFER) - return ret; + goto out; } - return -ENXIO; + ret = -ENXIO; #endif +out: + WARN(ret == 0, "0 is an invalid IRQ number\n"); + return ret; } EXPORT_SYMBOL_GPL(platform_get_irq_optional); @@ -212,7 +220,7 @@ EXPORT_SYMBOL_GPL(platform_get_irq_optional); * if (irq < 0) * return irq; * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq(struct platform_device *dev, unsigned int num) { @@ -284,8 +292,10 @@ static int __platform_get_irq_byname(struct platform_device *dev, } r = platform_get_resource_byname(dev, IORESOURCE_IRQ, name); - if (r) + if (r) { + WARN(r->start == 0, "0 is an invalid IRQ number\n"); return r->start; + } return -ENXIO; } @@ -297,7 +307,7 @@ static int __platform_get_irq_byname(struct platform_device *dev, * * Get an IRQ like platform_get_irq(), but then by name rather then by index. * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq_byname(struct platform_device *dev, const char *name) { @@ -319,7 +329,7 @@ EXPORT_SYMBOL_GPL(platform_get_irq_byname); * Get an optional IRQ by name like platform_get_irq_byname(). Except that it * does not print an error message if an IRQ can not be obtained. * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq_byname_optional(struct platform_device *dev, const char *name)
Bjorn Helgaas <helgaas@kernel.org> writes: > On Wed, Mar 18, 2020 at 02:42:48PM +0100, Thomas Gleixner wrote: >> Bjorn Helgaas <helgaas@kernel.org> writes: >> > On Fri, Mar 13, 2020 at 04:56:42PM -0500, Bjorn Helgaas wrote: >> >> On Fri, Mar 13, 2020 at 10:05:58PM +0100, Thomas Gleixner wrote: >> >> > > I think the best pattern is: >> >> > > >> >> > > irq = platform_get_irq(pdev, i); >> >> > > if (irq < 0) >> >> > > return irq; >> >> > >> >> > Careful. 0 is not a valid interrupt. >> >> >> >> Should callers of platform_get_irq() check for a 0 return value? >> >> About 900 of them do not. >> >> I don't know what I was looking at. >> >> platform_get_irq() does the right thing already, so checking for irq < 0 >> is sufficient. >> >> Sorry for the confusion! > > Thanks, I was indeed confused! Maybe we could reduce future confusion > by strengthening the comments slightly, e.g., > > - * Return: IRQ number on success, negative error number on failure. > + * Return: non-zero IRQ number on success, negative error number on failure. > > I don't want to push my luck, but it's pretty hard to prove that > platform_get_irq() never returns 0. What would you think of something > like the following? No objections from my side.
On Thu, Mar 19, 2020 at 09:47:47AM +0100, Thomas Gleixner wrote: > Bjorn Helgaas <helgaas@kernel.org> writes: > > On Wed, Mar 18, 2020 at 02:42:48PM +0100, Thomas Gleixner wrote: > >> Bjorn Helgaas <helgaas@kernel.org> writes: > >> > On Fri, Mar 13, 2020 at 04:56:42PM -0500, Bjorn Helgaas wrote: > >> >> On Fri, Mar 13, 2020 at 10:05:58PM +0100, Thomas Gleixner wrote: > >> >> > > I think the best pattern is: > >> >> > > > >> >> > > irq = platform_get_irq(pdev, i); > >> >> > > if (irq < 0) > >> >> > > return irq; > >> >> > > >> >> > Careful. 0 is not a valid interrupt. > >> >> > >> >> Should callers of platform_get_irq() check for a 0 return value? > >> >> About 900 of them do not. > >> > >> I don't know what I was looking at. > >> > >> platform_get_irq() does the right thing already, so checking for irq < 0 > >> is sufficient. > >> > >> Sorry for the confusion! > > > > Thanks, I was indeed confused! Maybe we could reduce future confusion > > by strengthening the comments slightly, e.g., > > > > - * Return: IRQ number on success, negative error number on failure. > > + * Return: non-zero IRQ number on success, negative error number on failure. > > > > I don't want to push my luck, but it's pretty hard to prove that > > platform_get_irq() never returns 0. What would you think of something > > like the following? > > No objections from my side. OK, thanks! Aman, my suggestion for you is to include the patch below as the first patch in your series. Then post a v2 of it, making sure to cc: everybody who commented on the first version. Bjorn driver core: platform: Specify that IRQ 0 is invalid These interfaces return a negative error number or an IRQ: platform_get_irq() platform_get_irq_optional() platform_get_irq_byname() platform_get_irq_byname_optional() The function comments suggest checking for error like this: irq = platform_get_irq(...); if (irq < 0) return irq; which is what most callers (~900 of 1400) do, so it's implicit that IRQ 0 is invalid. But some callers check for "irq <= 0", and it's not obvious from the source that we never return an IRQ 0. Make this more explicit by updating the comments to say that an IRQ number is always non-zero and adding a WARN() if we ever do return zero. If we do return IRQ 0, it likely indicates a bug in the arch-specific parts of platform_get_irq(). Relevant prior discussion at [1,2]. [1] https://lore.kernel.org/lkml/Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org/ [2] https://lore.kernel.org/lkml/Pine.LNX.4.64.0701252029570.25027@woody.linux-foundation.org/ Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 7fa654f1288b..50f3a5da89dc 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -133,23 +133,24 @@ EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_byname); * if (irq < 0) * return irq; * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) { + int ret; #ifdef CONFIG_SPARC /* sparc does not have irqs represented as IORESOURCE_IRQ resources */ if (!dev || num >= dev->archdata.num_irqs) return -ENXIO; - return dev->archdata.irqs[num]; + ret = dev->archdata.irqs[num]; + goto out; #else struct resource *r; - int ret; if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) { ret = of_irq_get(dev->dev.of_node, num); if (ret > 0 || ret == -EPROBE_DEFER) - return ret; + goto out; } r = platform_get_resource(dev, IORESOURCE_IRQ, num); @@ -157,7 +158,7 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) if (r && r->flags & IORESOURCE_DISABLED) { ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r); if (ret) - return ret; + goto out; } } @@ -171,13 +172,17 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) struct irq_data *irqd; irqd = irq_get_irq_data(r->start); - if (!irqd) - return -ENXIO; + if (!irqd) { + ret = -ENXIO; + goto out; + } irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS); } - if (r) - return r->start; + if (r) { + ret = r->start; + goto out; + } /* * For the index 0 interrupt, allow falling back to GpioInt @@ -190,11 +195,14 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num) ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num); /* Our callers expect -ENXIO for missing IRQs. */ if (ret >= 0 || ret == -EPROBE_DEFER) - return ret; + goto out; } - return -ENXIO; + ret = -ENXIO; #endif +out: + WARN(ret == 0, "0 is an invalid IRQ number\n"); + return ret; } EXPORT_SYMBOL_GPL(platform_get_irq_optional); @@ -212,7 +220,7 @@ EXPORT_SYMBOL_GPL(platform_get_irq_optional); * if (irq < 0) * return irq; * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq(struct platform_device *dev, unsigned int num) { @@ -284,8 +292,10 @@ static int __platform_get_irq_byname(struct platform_device *dev, } r = platform_get_resource_byname(dev, IORESOURCE_IRQ, name); - if (r) + if (r) { + WARN(r->start == 0, "0 is an invalid IRQ number\n"); return r->start; + } return -ENXIO; } @@ -297,7 +307,7 @@ static int __platform_get_irq_byname(struct platform_device *dev, * * Get an IRQ like platform_get_irq(), but then by name rather then by index. * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq_byname(struct platform_device *dev, const char *name) { @@ -319,7 +329,7 @@ EXPORT_SYMBOL_GPL(platform_get_irq_byname); * Get an optional IRQ by name like platform_get_irq_byname(). Except that it * does not print an error message if an IRQ can not be obtained. * - * Return: IRQ number on success, negative error number on failure. + * Return: non-zero IRQ number on success, negative error number on failure. */ int platform_get_irq_byname_optional(struct platform_device *dev, const char *name)
diff --git a/drivers/pci/controller/pcie-tango.c b/drivers/pci/controller/pcie-tango.c index 21a208da3f59..18c2c4313eb5 100644 --- a/drivers/pci/controller/pcie-tango.c +++ b/drivers/pci/controller/pcie-tango.c @@ -273,9 +273,9 @@ static int tango_pcie_probe(struct platform_device *pdev) writel_relaxed(0, pcie->base + SMP8759_ENABLE + offset); virq = platform_get_irq(pdev, 1); - if (virq <= 0) { + if (virq < 0) { dev_err(dev, "Failed to map IRQ\n"); - return -ENXIO; + return virq; } irq_dom = irq_domain_create_linear(fwnode, MSI_MAX, &dom_ops, pcie);
Signed-off-by: Aman Sharma <amanharitsh123@gmail.com> --- drivers/pci/controller/pcie-tango.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)