On Mon, Nov 29, 2021 at 10:22:41AM -0600, Pierre-Louis Bossart wrote:
> On 11/25/21 1:50 AM, Tang Bin wrote:
> > In the function sst_platform_get_resources(), if platform_get_irq()
> > failed, the return should not be zero, as the example in
> > platform.c is
> > * int irq = platform_get_irq(pdev, 0)
> > * if (irq < 0)
> > * return irq;
> > So remove the redundant check to simplify the code.
>
> Humm, it's a bit of a gray area.
>
> the comments for platform_get_irq and platform_get_irq_optional say:
>
> * Return: non-zero IRQ number on success, negative error number on failure.
>
> but if you look at platform_get_irq_optional, there are two references
> to zero being a possible return value:
>
> if (num == 0 && has_acpi_companion(&dev->dev)) {
> ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
> /* Our callers expect -ENXIO for missing IRQs. */
> if (ret >= 0 || ret == -EPROBE_DEFER)
This is bogus == 0 check.
> goto out;
>
> out_not_found:
> ret = -ENXIO;
> out:
> WARN(ret == 0, "0 is an invalid IRQ number\n");
> return ret;
>
> https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L234
>
> I am not sure if there's any merit in removing the test for the zero
> return value. It may be on the paranoid side but it's aligned with a
> possible code path in the platform code.
>
> Or it could be that the platform code is wrong, and the label used
> should have been
>
> /* Our callers expect -ENXIO for missing IRQs. */
> if (ret >= 0 || ret == -EPROBE_DEFER)
> goto out_not_found;
In case one wants to dive into new discussion on the topic:
https://lore.kernel.org/linux-serial/20220110195449.12448-2-s.shtylyov@xxxxxx/T/#u
--
With Best Regards,
Andy Shevchenko
