[PATCH v2 1/2] thermal/drivers/rcar_gen3: Handle -ENXIO from optional IRQ lookup

[Geert Uytterhoeven]

Hi Phuc,

On Tue, 11 Aug 2026 at 04:02, Bui Duc Phuc <phucduc.bui at gmail.com> wrote:
> > > -     if (rcar_gen3_thermal_request_irqs(priv, pdev))
> > > +     ret = rcar_gen3_thermal_request_irqs(priv, pdev);
> > > +     if (ret == -ENXIO)
> > >               priv->ops.set_trips = NULL;
> > > +     else if (ret)
> > > +             return ret;
> >
> > I'm not sure I like this.
> >
> > The old behavior is that for any reason we can't get the optional IRQ
> > the driver still works, but without hardware trip points.
>
> Regarding the old behavior, it was handled like this:
> ------------------------------
> irq = platform_get_irq_optional(pdev, i);
>         if (irq < 0)
>                 return irq;
> ------------------------------
> As I understand it, this is essentially the behavior of
> platform_get_irq() itself:
>
> https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/base/platform.c#L301

Except that platform_get_irq() prints an error message, too, which
we want to suppress.

> This could be understood as rcar-gen3 not actually supporting an optional IRQ.
> If you still want to keep the old behavior, then I think we should switch to
> platform_get_irq() instead of platform_get_irq_optional(), since using
> the latter
> could give a misleading impression that rcar-gen3 supports an optional IRQ.
>
> Incidentally, I also don't quite understand why rcar-gen2 supports an
> optional IRQ
> while rcar-gen3 does not. Is there a hardware limitation on rcar-gen3
> that requires
> the IRQ to be present, or is this just a difference in the driver
> implementation?

On R-Car Gen3, thermal has an interrupt.
On R-Car Gen4, thermal does not have an interrupt, but routes this
signal to the ECM.

> Regarding the benefit of the new behavior:
>
> If rcar-gen3 actually supports an optional IRQ, I think the benefit is
> that it reflects
> the actual state of the system. It allows the developer to know that
> something went
> wrong and investigate or fix the underlying issue. In the case of
> `-EPROBE_DEFER`,
> the benefit is even clearer, as it allows the kernel to defer the
> probe and retry it later
> when the dependency becomes available.
>
> If we silently ignore the error as we do currently, the driver may
> still be able to provide
> thermal information as you mentioned. However, can we still guarantee
> the correctness
> and safety of the system?

-EPROBE_DEFER should indeed be handled correctly.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds