On Thu, May 7, 2020 at 7:17 AM Jerry Snitselaar <jsnitsel@xxxxxxxxxx> wrote:
>
> On Thu May 07 20, Hans de Goede wrote:
> >Hi All,
> >
> >On 4/10/20 11:06 PM, Jarkko Sakkinen wrote:
> >>On Thu, Apr 09, 2020 at 11:10:44PM +0200, Hans de Goede wrote:
> >>>Since commit dda8b2af395b ("tpm: Revert "tpm_tis_core: Set
> >>>TPM_CHIP_FLAG_IRQ before probing for interrupts"") we no longer set
> >>>the TPM_CHIP_FLAG_IRQ ever.
> >>>
> >>>So the whole IRQ probing code is not useful, worse we rely on the
> >>>IRQ-test path of tpm_tis_send() to call disable_interrupts() if
> >>>interrupts do not work, but that path never gets entered because we
> >>>never set the TPM_CHIP_FLAG_IRQ.
> >>>
> >>>So the remaining IRQ probe code calls request_irq() and never calls
> >>>free_irq() even when the interrupt is not working.
> >>>
> >>>On some systems, e.g. the Lenovo X1 8th gen, the interrupt we try
> >>>to use and never free creates an interrupt storm followed by
> >>>an "irq XX: nobody cared" oops.
> >>>
> >>>Since it is non-functional at the moment anyways, lets just completely
> >>>disable the IRQ code in tpm_tis_core for now.
> >>>
> >>>Fixes: dda8b2af395b ("tpm: Revert "tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts"")
> >>>Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> >>>---
> >>>Note I'm working with Lenovo to try and get to the bottom of this.
> >>>---
> >>
> >>OK if I recall correctly the reason for reverting was that the fixes
> >>Stefan was sending were broken and no access to hardware were the
> >>issues would be visible. The reason for not doing anything til this
> >>day is that we don't have T490 available.
> >
> >So as promised I have been in contact with Lenovo about this.
> >
> >Specifically I have been in contact with Lenovo about seeing an
> >IRQ storm when the tpm_tis code tries to use the IRQ on a X1 carbon
> >8th gen (X1C8), because of the now public plan that Lenovo will
> >offer ordering this model with Fedora pre-installed:
> >https://lwn.net/Articles/818595/
> >
> >On the X1C8 the problem has been diagnosed to be a misconfigured
> >GPIO pin on the CPU (the SoC). The X1C8 uses an SPI connected
> >TPM chip with its IRQ connected to a GPIO on the SoC which is
> >configured in Direct IRQ mode, so that it directly asserts
> >IRQs on one of the APIC IRQs. The problem is that due to the
> >misconfiguration as soon as the IRQ is enabled it fires
> >continuously.
> >
> >For the X1C8 this should be fixed in the BIOS of the first
> >batch which gets shipped out to customers so there we should
> >not have to worry about this.
> >
> >It is likely (but not yet confirmed) that the issue on the T490
> >is the same, although on my test X1C8 device I got an IRQ storm,
> >followed by the kernel disabling the IRQ, not a non booting system.
> >I guess this might be due to kernel configuration differences.
> >
> >Assuming that the issue on the T490 is the same, we might see a
> >BIOS update fixing this, but given that non-booting is
> >'not good ("tm")' even if there will be a BIOS fix we should
> >still do something at the kernel level to also work with the
> >older unfixed BIOS which is already out there.
> >
> >I've been thinking about this and I'm afraid that the only thing
> >what we can do is add a DMI product-name (product-version for Lenovo)
> >string based blacklist for IRQ usage to drivers/char/tpm/tpm_tis.c
> >and set tpm_info.irq = -1 for devices on that list.
> >
> >My plan is to prepare a RFC patch of such a blacklist, while we
> >wait for confirmation that the root cause on the T490 is the same
> >as on the X1C8, but before I work on that I'm wondering if
> >people agree that that is the best approach, or if there are
> >other suggestions for dealing with this ?
> >
> >Regards,
> >
> >Hans
> >
>
> Dan,
>
> Could this be the cause of the problem on the system you were
> seeing the issue with, or was that using PTT?
It sounds similar, I'm just not immediately aware of where I can find
out how the GPIOs are routed on that development board. I'll poke
around.
What's PTT?
My concern with a blacklist is that the existing tpm_tis module
parameter to disable interrupts, IIRC, did not help mitigate this
problem. So I would think that if there is a blackilst it should at
least be amenable by module parameter for new platforms, or that
specifying "interrupts=0" to tpm_tis.ko behaves identically to the
device being placed on the list.
