On 8/5/21 10:52 PM, Jarkko Sakkinen wrote: > On Wed, Aug 04, 2021 at 06:21:31PM +0200, Borys Movchan wrote: >> If something went wrong during the TPM firmware upgrade, like power >> failure or the firmware image file get corrupted, the TPM might end >> up in Upgrade or Failure mode upon the next start. The state is >> persistent between the TPM power cycle/restart. >> >> According to TPM specification: >> * If the TPM is in Upgrade mode, it will answer with TPM2_RC_UPGRADE >> to all commands except Field Upgrade related ones. >> * If the TPM is in Failure mode, it will allow performing TPM >> initialization but will not provide any crypto operations. >> Will happily respond to Field Upgrade calls. >> >> The fix changes the behavior of the `tpm2_auto_startup` function, so > > In commit messages, you ought to use imperative form: > > "Change the behaviour of tpm2_auto_startup(), ..." > Done >> it tries to detect what mode TPM is running in. If the chip is in the >> Upgrade or Failure mode, the function returns -EIO error code which >> can be used later to adjust driver behavior later. > *How* tpm2_auto_startup() detects the mode? Done >> After `tpm_chip_register` calls `tpm2_auto_startup` it checks for the > Please remove all these hyphens. They make the commit message a pain > to read. E.g. instead write tpm_chip_register(). This is not Github. Done >> error code. If the TPM is in Upgrade or Failure mode, set the >> `limited_mode` flag. The calls to `tpm2_get_cc_attrs_tbl`, >> `tpm_add_hwrng` and `tpm_get_pcr_allocation` will fail if the TPM is >> in Failure or Upgrade mode, so use `limited_mode` flag to exclude >> them from the module initialization sequence. >> >> Signed-off-by: Borys Movchan <borysmn@xxxxxxxx> >> --- >> >> Notes: >> Commit message updated > v2: > * Commit message updated. > > Notes would be something that had existed already in the first version. > Here we want a simple change log. Corrected > /Jarkko > Kind regards, Borys
