Re: [PATCH 2/4] ipmi: bt-bmc: Handle -ENXIO from optional IRQ lookup

[Corey Minyard <corey@minyard.net>]

On Mon, Aug 17, 2026 at 09:28:50PM +0700, Bui Duc Phuc wrote:
> On Mon, Aug 17, 2026 at 6:40 PM Corey Minyard <corey@minyard.net> wrote:
> >
> > On Mon, Aug 17, 2026 at 05:50:39PM +0700, phucduc.bui@gmail.com wrote:
> > > From: bui duc phuc <phucduc.bui@gmail.com>
> > >
> > > platform_get_irq_optional() can return -ENXIO when no IRQ resource is
> > > available, as well as other negative error codes.
> > >
> > > The probe path supports running without an IRQ by falling back to
> > > the timer. Treat -ENXIO as the no-IRQ case while propagating other
> > > errors to the caller.
> >
> > This is obviously wrong, it will pass -ENXIO into devm_request_irq()
> > if returned.
> >
> 
> 
> No. This is addressed in the following patch:
> [PATCH 3/4] ipmi: bt-bmc: Request IRQ only when available
> 
> https://lore.kernel.org/all/20260817105041.63224-3-phucduc.bui@gmail.com/
> 
> Please take a look at the subsequent patches in the series as well.

You cannot add patches that introduce bugs then fix them later.
Occassionally it might be necessary, but it should be avoided if
possible, and it's certainly possible here.

And as I said earlier, this function should return an error/interrupt,
not set the value inside the function.  The function has issues,
and you are right to work on it, but it needs to be consistent with
everything else in the kernel.

This would also be better as a single patch.  There's no reason to split
it up to this fine a level of detail, it makes it hard to follow.

And it must work if no interrupt is available for any reason.

-corey

> 
> Best regards,
> Phuc