On Fri, Oct 02, 2026 at 05:44:34PM +0300, Dan Carpenter wrote: > The bind_evtchn_to_irqhandler() function can never return 0. > Historically, IRQ functions used to return zero on error, but then we > added an architecture where that was a valid IRQ so it went from being > an error to being success (but in a limitted way, just enough for that > arch to boot, I guess). Eventually we removed it and we will never > allow zero to be a valid IRQ again. > > The problem here is that if zero were an invalid IRQ then we should > return a negative error code but the code returns zero/success. > > Change the code to check for negative error codes so it's not question > of how the zero should be handled. > > Signed-off-by: Dan Carpenter <[email protected]> > --- > From static analysis. Untested. > > drivers/char/tpm/xen-tpmfront.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c > index 3c0cce57c4ae..731444eac5f2 100644 > --- a/drivers/char/tpm/xen-tpmfront.c > +++ b/drivers/char/tpm/xen-tpmfront.c > @@ -266,7 +266,7 @@ static int setup_ring(struct xenbus_device *dev, struct > tpm_private *priv) > > rv = bind_evtchn_to_irqhandler(priv->evtchn, tpmif_interrupt, 0, > "tpmif", priv); > - if (rv <= 0) { > + if (rv < 0) { > xenbus_dev_fatal(dev, rv, "allocating TPM irq"); > return rv; > } > -- > 2.53.0 >
Looks good to me. Isn't this a bug by definition? Br, Jarkko
