[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <984d3ec6-fe30-d662-5cee-9eb4323c305e@kunbus.com>
Date: Tue, 23 May 2023 12:41:24 +0200
From: Lino Sanfilippo <l.sanfilippo@...bus.com>
To: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
Lukas Wunner <lukas@...ner.de>
Cc: Lino Sanfilippo <LinoSanfilippo@....de>, peterhuewe@....de,
jarkko@...nel.org, jgg@...pe.ca, jsnitsel@...hat.com,
hdegoede@...hat.com, oe-lkp@...ts.linux.dev, lkp@...el.com,
peterz@...radead.org, linux@...ewoehner.de,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
p.rosenberger@...bus.com
Subject: Re: [PATCH 1/2] tpm, tpm_tis: Handle interrupt storm
Hi,
On 23.05.23 11:14, Péter Ujfalusi wrote:
>>
>>>> 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;
>>>
>>> This is more like an error than just unhandled IRQ. Yes, it was ignored,
>>> probably because it is common?
>>
>> The interrupt may be shared and then it's not an error.
>
> but this is tpm_tis_write32() failing, no? If it is shared interrupt and
> we return IRQ_HANDLED unconditionally then I think the core will think
> that the interrupt was for this device and it was handled.
>
At this point we already know the interrupt was for our device. Otherwise we would
have already bailed out at
if (interrupt == 0)
Regards,
Lino
> --
> Péter
Powered by blists - more mailing lists