On 24.05.23 17:30, Jarkko Sakkinen wrote: > ATTENTION: This e-mail is from an external sender. Please check attachments and links before opening e.g. with mouseover. > > > On Wed May 24, 2023 at 6:58 AM EEST, Jarkko Sakkinen wrote: >>> rc = tpm_tis_read32(priv, TPM_INT_STATUS(priv->locality), &interrupt); >>> if (rc < 0) >>> - return IRQ_NONE; >>> + goto unhandled; >>> >>> if (interrupt == 0) >>> - return IRQ_NONE; >>> + goto unhandled; >>> >>> set_bit(TPM_TIS_IRQ_TESTED, &priv->flags); >>> if (interrupt & TPM_INTF_DATA_AVAIL_INT) >>> @@ -780,10 +829,14 @@ static irqreturn_t tis_int_handler(int dummy, void *dev_id) >>> rc = tpm_tis_write32(priv, TPM_INT_STATUS(priv->locality), interrupt); >>> tpm_tis_relinquish_locality(chip, 0); >>> if (rc < 0) >>> - return IRQ_NONE; >>> + goto unhandled; >>> >>> tpm_tis_read32(priv, TPM_INT_STATUS(priv->locality), &interrupt); >>> return IRQ_HANDLED; >>> + >>> +unhandled: >>> + tpm_tis_process_unhandled_interrupt(chip); >>> + return IRQ_HANDLED; >>> } > > Some minor glitches I noticed. > > You could simplify the flow by making the helper to return IRQ_NONE. > > E.g. > > tpm_tis_relinquish_locality(chip, 0); > if (rc < 0) > return tpm_tis_process_unhandled_interrupt(chip); Agreed, this way we could spare a few lines in the interrupt handler (but note that the implementation only returns IRQ_HANDLED never IRQ_NONE. This is to prevent the generic irq code from doing its own interrupt storm handling before the TPM driver had a chance to fall back to polling). > > I'd recommend changing the function name simply tpm_tis_rollback_interrupt(). > Also tpm_tis_handle_irq_storm() is a pretty bad function name > because handle also can mean anything. You are resetting to the > polling mode, right? > > So perhaps that could be e.g. tpm_tis_reenable_polling? I'm open > for any other name but it really needs to give a hint what the > function does. tpm_tis_reenable_polling() sounds good to me. Regards, Lino
