On Thu, Dec 10, 2020 at 12:23:57PM +0800, Kai-Heng Feng wrote: > > > > On Dec 8, 2020, at 18:17, Jarkko Sakkinen <[email protected]> wrote: > > > > On Mon, Dec 07, 2020 at 12:42:53PM +0800, Kai-Heng Feng wrote: > >> Hi Jarkko, > >> > >> A user report that the system can only do S3 once. Subsequent S3 fails > >> after commit a3fbfae82b4c ("tpm: take TPM chip power gating out of > >> tpm_transmit()"). > >> > >> Dmesg with the issue, collected under 5.10-rc2: > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891502/comments/14 > >> > >> Dmesg without the issue, collected under 5.0.0-rc8: > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891502/comments/16 > >> > >> Full bug report here: > >> https://bugs.launchpad.net/bugs/1891502 > >> > >> Kai-Heng > > > > Relevant part: > > > > > > [80601.620149] tpm tpm0: Error (28) sending savestate before suspend > > [80601.620165] PM: __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x90 returns 28 > > [80601.620172] PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x20 returns 28 > > [80601.620178] PM: Device 00:01 failed to suspend: error 28 > > > > Looking at this there are two issues: > > > > A. TPM_ORD_SAVESTATE command failing, this a new regression. > > B. When tpm_pm_suspend() fails, it should not fail the whole suspend > > procedure. And it returns the TPM error code back to the upper > > layers when it does so, which makes no sense. This is an old > > issue revealed by A. > > > > Let's look at tpm_pm_suspend(): > > > > /* > > * We are about to suspend. Save the TPM state > > * so that it can be restored. > > */ > > int tpm_pm_suspend(struct device *dev) > > { > > struct tpm_chip *chip = dev_get_drvdata(dev); > > int rc = 0; > > > > if (!chip) > > return -ENODEV; > > > > if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED) > > goto suspended; > > > > if ((chip->flags & TPM_CHIP_FLAG_FIRMWARE_POWER_MANAGED) && > > !pm_suspend_via_firmware()) > > goto suspended; > > > > if (!tpm_chip_start(chip)) { > > if (chip->flags & TPM_CHIP_FLAG_TPM2) > > tpm2_shutdown(chip, TPM2_SU_STATE); > > else > > rc = tpm1_pm_suspend(chip, tpm_suspend_pcr); > > > > tpm_chip_stop(chip); > > } > > > > suspended: > > return rc; > > } > > EXPORT_SYMBOL_GPL(tpm_pm_suspend); > > > > I would modify this into: > > > > /* > > * We are about to suspend. Save the TPM state > > * so that it can be restored. > > */ > > int tpm_pm_suspend(struct device *dev) > > { > > struct tpm_chip *chip = dev_get_drvdata(dev); > > int rc = 0; > > > > if (!chip) > > return -ENODEV; > > > > if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED) > > goto suspended; > > > > if ((chip->flags & TPM_CHIP_FLAG_FIRMWARE_POWER_MANAGED) && > > !pm_suspend_via_firmware()) > > goto suspended; > > > > if (!tpm_chip_start(chip)) { > > if (chip->flags & TPM_CHIP_FLAG_TPM2) > > tpm2_shutdown(chip, TPM2_SU_STATE); > > else > > tpm1_pm_suspend(chip, tpm_suspend_pcr); > > > > tpm_chip_stop(chip); > > } > > > > suspended: > > return rc; > > } > > EXPORT_SYMBOL_GPL(tpm_pm_suspend); > > > > I.e. it's a good idea to put something into klog but that should not > > fail the whole suspend procedure. TPM is essentially opt-in feature. > > > > Of course issue A needs to be also sorted out but would this work as > > a quick initial fix? I can queue a patch for this. Is it possible to > > try out this fix for if I drop a patch? > > Yes, possible test result from affected user. > > I had to cut those code and do a diff side by side to find what changed. > Hopefully next time I can get one from `git diff`... > > Kai-Heng
Yes you can. Sorry about that. /Jarkko
