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

[Bui Duc Phuc]

Hi Corey,

Thanks for your feedback.


> > 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@xxxxxxxxx/
> >
> > 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.
>

This patch does not introduce a new bug. It fixes the incorrect handling of
platform_get_irq_optional() .
The only issue is that, as you pointed out, the patches are not
ordered appropriately.
Perhaps it would be better to make this patch look like this:

-       if (bt_bmc->irq < 0)
+       if (bt_bmc->irq < 0 && bt_bmc->irq != -ENXIO)
                return bt_bmc->irq;

-       rc = devm_request_irq(dev, bt_bmc->irq, bt_bmc_irq, IRQF_SHARED,
-                             DEVICE_NAME, bt_bmc);
-       if (rc < 0) {
-               dev_warn(dev, "Unable to request IRQ %d\n", bt_bmc->irq);
-               bt_bmc->irq = rc;
-               return rc;
+       if (bt_bmc->irq > 0) {
+               rc = devm_request_irq(dev, bt_bmc->irq, bt_bmc_irq,
+                                     IRQF_SHARED, DEVICE_NAME, bt_bmc);
+               if (rc < 0) {
+                       dev_warn(dev, "Unable to request IRQ %d\n",
bt_bmc->irq);
+                       bt_bmc->irq = rc;
+                       return rc;
        }

Then the next patch would remove the error log:
       if (rc < 0) {
-               dev_warn(dev, "Unable to request IRQ %d\n", bt_bmc->irq);
-               bt_bmc->irq = rc;
               return rc;



> And as I said earlier, this function should return an error/interrupt,
> not set the value inside the function.

I agree. This is reasonable and can be refactored to make the code clearer.

>The function has issues,
> and you are right to work on it, but it needs to be consistent with
> everything else in the kernel.
>

Yes, I agree.
I found that quite a few places in the kernel handle the error values
from platform_get_irq_optional()
correctly. However, there are still some places where they are not
handled correctly.

Regarding the incorrect error handling of platform_get_irq_optional(),
I have submitted several patches to address such cases. Some places have
agreed with my approach of propagating all error values except -ENXIO,
while some other places have so far only agreed with propagating -EPROBE_DEFER.

I think that when we do not fully understand the semantics of an API,
we may end up with incorrect error handling. But once the issue has
been identified,
I think we should fix it rather than continue to maintain the
incorrect behavior.

If, with other APIs, callers also unintentionally or intentionally
hide meaningful errors
instead of propagating them upwards, just imagine what the kernel would become.

> 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.
>

If the issue is fixed, having it as a single patch would not be a problem.

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

As I understand it, you mean keeping the current behavior of ignoring
all errors and
continuing to run, in order to ensure that existing systems can still work?
Since the current code already ignores all errors, is that correct?

Best regards,
Phuc