Re: [PATCH] tpm: clean up error checking in setup_ring()

[Jarkko Sakkinen]

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 <error27@xxxxxxxxx>
> ---
> 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