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

[Corey Minyard <corey@minyard.net>]

On Wed, Aug 19, 2026 at 09:22:28AM +0700, Bui Duc Phuc wrote:
> Hi Corey,
> 
> Thank you for your feedback.
> 
> > Yes, ignoring errors is the right thing to do in this case.  Printing a
> > warning log about incorrect configuration is ok, but breaking systems
> > that have incorrect configuration is not ok.
> >
> 
> If that's the case, then perhaps platform_get_irq() would be a better fit than
> platform_get_irq_optional(). platform_get_irq() already prints an error message
> internally and only requires the caller to distinguish between success
> and failure.
> This seems to match the behavior you are looking for.

No, it is optional.  Some systems don't have interrupts.  But they may
be misconfigured in this case.  For instance, they may put "0" for the
interrupt if they don't support it.  These things can't always be easily
fixed.  The big thing is we can't change behaviour without a really
compelling reasons.

> 
> > It is common for these systems to not have interrupts.  I think it's a
> > bad idea, but I didn't design the hardware or the specifciations.  And
> > it's common for configuration to have issues :-(
> >
> 
> 
> Hardware configuration is handled by software, so if the software configures
> the hardware incorrectly but ignores the error, the problem may go undetected.
> Could this allow the same driver bug to persist when the driver is used
> with newer generations of chips?
> 
> Also, if software silently ignores errors, it can hide a problem in
> the hardware or
> in how the hardware is being used. This can make the problem harder to detect
> and potentially allow it to persist when the design is reused in
> subsequent chip generations.

I'm not going to argue with any of this.  But I also have to live inside
the parameters of the real world.

It doesn't have to be silent, you can print a warning.  But it can't
return an error in this case.

> 
> > Anyway, I think you have the parameters now, looking forward to the next
> > patch.
> 
> My goal is to ensure that the correct error code is returned to the caller.
> Although I could implement it by ignoring the errors as you suggested,
> I will not do so because that goes against the goal of this series.

Ok, that's fine.  This isn't critical.

Thanks,

-corey

> 
> Best regards,
> Phuc