On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbind
I checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
On Wed Nov 20 19, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
We've had an issue reported for a Lenovo t490s getting an interrupt storm with the Fedora 5.3 stable kernel, so it appears to be impacting a number of systems.
On Fri, Nov 22, 2019 at 09:18:36AM -0700, Jerry Snitselaar wrote:
On Wed Nov 20 19, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
We've had an issue reported for a Lenovo t490s getting an interrupt storm with the Fedora 5.3 stable kernel, so it appears to be impacting a number of systems.
Hi sorry for inactivity. I've had a renovation going on where I live which has caused some crackling in the comms but I'm catching up during the weekend.
Which CPU model does T490S have? Can you paste /proc/cpuinfo?
/Jarkko
On Fri Nov 29 19, Jarkko Sakkinen wrote:
On Fri, Nov 22, 2019 at 09:18:36AM -0700, Jerry Snitselaar wrote:
On Wed Nov 20 19, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
We've had an issue reported for a Lenovo t490s getting an interrupt storm with the Fedora 5.3 stable kernel, so it appears to be impacting a number of systems.
Hi sorry for inactivity. I've had a renovation going on where I live which has caused some crackling in the comms but I'm catching up during the weekend.
Which CPU model does T490S have? Can you paste /proc/cpuinfo?
/Jarkko
I still don't have access to one of the laptops, but looking online they should have one of the following: i5-8265U, i5-8365U, i7-8565U, or i7-8665U. The tpm is discrete, so I don't know that the cpu will matter. Looking at a log, in the t490s case it is an STMicroelectronics chip. So both Infineon and STM so far.
On Fri Nov 29 19, Jerry Snitselaar wrote:
On Fri Nov 29 19, Jarkko Sakkinen wrote:
On Fri, Nov 22, 2019 at 09:18:36AM -0700, Jerry Snitselaar wrote:
On Wed Nov 20 19, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
We've had an issue reported for a Lenovo t490s getting an interrupt storm with the Fedora 5.3 stable kernel, so it appears to be impacting a number of systems.
Hi sorry for inactivity. I've had a renovation going on where I live which has caused some crackling in the comms but I'm catching up during the weekend.
Which CPU model does T490S have? Can you paste /proc/cpuinfo?
/Jarkko
I still don't have access to one of the laptops, but looking online they should have one of the following: i5-8265U, i5-8365U, i7-8565U, or i7-8665U. The tpm is discrete, so I don't know that the cpu will matter. Looking at a log, in the t490s case it is an STMicroelectronics chip. So both Infineon and STM so far.
In the case reported on Fedora the cpu is a i7-8665U.
On Fri, Nov 29, 2019 at 04:32:47PM -0700, Jerry Snitselaar wrote:
I still don't have access to one of the laptops, but looking online they should have one of the following: i5-8265U, i5-8365U, i7-8565U, or i7-8665U. The tpm is discrete, so I don't know that the cpu will matter. Looking at a log, in the t490s case it is an STMicroelectronics chip. So both Infineon and STM so far.
In the case reported on Fedora the cpu is a i7-8665U.
I don't think CPU will matter that much if it is a dTPM.
/Jarkko
On Fri, Nov 29, 2019 at 04:22:49PM -0700, Jerry Snitselaar wrote:
I still don't have access to one of the laptops, but looking online they should have one of the following: i5-8265U, i5-8365U, i7-8565U, or i7-8665U. The tpm is discrete, so I don't know that the cpu will matter. Looking at a log, in the t490s case it is an STMicroelectronics chip. So both Infineon and STM so far.
Still also seeking a local system.
/Jarkko
On Wed, Nov 20, 2019 at 08:48:25PM -0800, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
It is already in WiP:
https://patchwork.kernel.org/patch/11240111/
Stefan also sent patches that revert to changes that you described:
https://patchwork.kernel.org/cover/11262363/
Probably better first to fix the issue on top of master before deciding actions.
/Jarkko
On Wed, Nov 27, 2019 at 10:58:00PM +0200, Jarkko Sakkinen wrote:
On Wed, Nov 20, 2019 at 08:48:25PM -0800, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
It is already in WiP:
https://patchwork.kernel.org/patch/11240111/
Stefan also sent patches that revert to changes that you described:
https://patchwork.kernel.org/cover/11262363/
Probably better first to fix the issue on top of master before deciding actions.
... and apologies for late response.
/Jarkko
On Wed Nov 27 19, Jarkko Sakkinen wrote:
On Wed, Nov 27, 2019 at 10:58:00PM +0200, Jarkko Sakkinen wrote:
On Wed, Nov 20, 2019 at 08:48:25PM -0800, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
It is already in WiP:
https://patchwork.kernel.org/patch/11240111/
Stefan also sent patches that revert to changes that you described:
https://patchwork.kernel.org/cover/11262363/
Probably better first to fix the issue on top of master before deciding actions.
... and apologies for late response.
/Jarkko
There also was that other issue reported on the list about tpm_tis_core_init failing when calling tpm_get_timeouts due to the power gating changes.
On Wed, Nov 27, 2019 at 06:20:55PM -0700, Jerry Snitselaar wrote:
There also was that other issue reported on the list about tpm_tis_core_init failing when calling tpm_get_timeouts due to the power gating changes.
Please add a (lore.ko) link for reference to this thread.
/Jarkko
On Sat Nov 30 19, Jarkko Sakkinen wrote:
On Wed, Nov 27, 2019 at 06:20:55PM -0700, Jerry Snitselaar wrote:
There also was that other issue reported on the list about tpm_tis_core_init failing when calling tpm_get_timeouts due to the power gating changes.
Please add a (lore.ko) link for reference to this thread.
/Jarkko
https://lore.kernel.org/linux-integrity/a60dadce-3650-44ce-8785-2f737ab9b993...
On Fri, Nov 29, 2019 at 05:12:53PM -0700, Jerry Snitselaar wrote:
On Sat Nov 30 19, Jarkko Sakkinen wrote:
On Wed, Nov 27, 2019 at 06:20:55PM -0700, Jerry Snitselaar wrote:
There also was that other issue reported on the list about tpm_tis_core_init failing when calling tpm_get_timeouts due to the power gating changes.
Please add a (lore.ko) link for reference to this thread.
/Jarkko
https://lore.kernel.org/linux-integrity/a60dadce-3650-44ce-8785-2f737ab9b993...
tpm_chip_stop() probably causes the issue. That is why tpm2_probe() works and failure happens after that.
tpm_chip_stop() should be called once at the end of the function.
/Jarkko
On Fri Dec 06 19, Jarkko Sakkinen wrote:
On Fri, Nov 29, 2019 at 05:12:53PM -0700, Jerry Snitselaar wrote:
On Sat Nov 30 19, Jarkko Sakkinen wrote:
On Wed, Nov 27, 2019 at 06:20:55PM -0700, Jerry Snitselaar wrote:
There also was that other issue reported on the list about tpm_tis_core_init failing when calling tpm_get_timeouts due to the power gating changes.
Please add a (lore.ko) link for reference to this thread.
/Jarkko
https://lore.kernel.org/linux-integrity/a60dadce-3650-44ce-8785-2f737ab9b993...
tpm_chip_stop() probably causes the issue. That is why tpm2_probe() works and failure happens after that.
tpm_chip_stop() should be called once at the end of the function.
The patch I posted that fixed the issue for him moved the tpm_chip_start() from the irq probing section right below there to before the tpm_get_timeouts call, but your idea is better.
Any thoughts on the irq issue? I need to go back and look at the older commits again, but before Stefan's patch enabling the irq flag I'm not sure the last time that testing code section in tpm_tis_send was actually used. I think prior to that it always just went straight to tpm_tis_send_main.
570a36097f30 ("tpm: drop 'irq' from struct tpm_vendor_specific") adds the flag, and I can see where it disables and enables the flag in the testing code in tpm_tis_send, but I don't see where it enables the flag originally for it to ever get into the testing section of tpm_tis_send. That means since this commit tpm_tis hasn't been using interrupts, right?
Regards, Jerry
/Jarkko
On Fri, Dec 06, 2019 at 04:02:55PM -0700, Jerry Snitselaar wrote:
On Fri Dec 06 19, Jarkko Sakkinen wrote:
On Fri, Nov 29, 2019 at 05:12:53PM -0700, Jerry Snitselaar wrote:
On Sat Nov 30 19, Jarkko Sakkinen wrote:
On Wed, Nov 27, 2019 at 06:20:55PM -0700, Jerry Snitselaar wrote:
There also was that other issue reported on the list about tpm_tis_core_init failing when calling tpm_get_timeouts due to the power gating changes.
Please add a (lore.ko) link for reference to this thread.
/Jarkko
https://lore.kernel.org/linux-integrity/a60dadce-3650-44ce-8785-2f737ab9b993...
tpm_chip_stop() probably causes the issue. That is why tpm2_probe() works and failure happens after that.
tpm_chip_stop() should be called once at the end of the function.
The patch I posted that fixed the issue for him moved the tpm_chip_start() from the irq probing section right below there to before the tpm_get_timeouts call, but your idea is better.
Yes, the chip can be reserved for the whole course of the function because it is single user at that point.
Any thoughts on the irq issue? I need to go back and look at the older commits again, but before Stefan's patch enabling the irq flag I'm not sure the last time that testing code section in tpm_tis_send was actually used. I think prior to that it always just went straight to tpm_tis_send_main.
I'd prefer to look it up with the fix for start/stop because it is a regression on its own and mixed effect is not great way to analyze anything.
So what we need is a T490S owner to provide klog with the fix applied.
/Jarkko
On Wed, Nov 27, 2019 at 12:58 PM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
On Wed, Nov 20, 2019 at 08:48:25PM -0800, Dan Williams wrote:
On Mon, Sep 2, 2019 at 7:34 AM Jarkko Sakkinen jarkko.sakkinen@linux.intel.com wrote:
Hi
A new driver for fTPM living inside ARM TEE was added this round. In addition to that, there is three bug fixes and one clean up.
/Jarkko
The following changes since commit 8fb8e9e46261e0117cb3cffb6dd8bb7e08f8649b:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-08-30 09:23:45 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190902
for you to fetch changes up to e8bd417aab0c72bfb54465596b16085702ba0405:
tpm/tpm_ftpm_tee: Document fTPM TEE driver (2019-09-02 17:08:35 +0300)
tpmdd updates for Linux v5.4
Jarkko Sakkinen (1): tpm: Remove a deprecated comments about implicit sysfs locking
Lukas Bulwahn (1): MAINTAINERS: fix style in KEYS-TRUSTED entry
Sasha Levin (2): tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE tpm/tpm_ftpm_tee: Document fTPM TEE driver
Stefan Berger (2): tpm_tis_core: Turn on the TPM before probing IRQ's tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
Hi Jarrko,
I'm replying here because I can't find the patches to reply to directly from LKML.
Commit 7f064c378e2c "tpm_tis_core: Turn on the TPM before probing IRQ's" in the v5.3-stable tree caused a regression on a pre-release platform with a TPM2 device. The interrupt starts screaming when the driver is loaded and does not stop until the device is force unbond from the driver by:
echo IFX0740:00 > /sys/bus/platform/drivers/tpm_tis/unbindI checked v5.4-rc8 and it has the same problem. I tried reverting:
1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts 5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
Which silenced the screaming interrupt problem, but now the TPM is reporting:
[ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
...at load, where it was not reporting this previously. Can you take a look?
It is already in WiP:
That fix did not work for me.
Stefan also sent patches that revert to changes that you described:
https://patchwork.kernel.org/cover/11262363/
Probably better first to fix the issue on top of master before deciding actions.
Revert and try again sounds good to me.
linux-stable-mirror@lists.linaro.org
-
Dan Williams -
Jarkko Sakkinen -
Jerry Snitselaar