On Fri, Jul 30, 2021 at 04:24:01PM +0200, Borys Movchan wrote: > On 7/28/21 11:58 PM, Jarkko Sakkinen wrote: > > On Wed, Jul 28, 2021 at 12:57:30PM +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 adds the possibility to detect an active state of > > > the TPM and gives the user-space a chance to finish the > > > firmware upgrade/recover the TPM. > > > > This is different than telling what the patch does. It's just > > describing a goal, but does not describe how the driver is > > changed, and reasons for doing that. > > > > For instance, you check 'limited_mode' flag in a few sites. > > How can I know that those are exactly the locations where this > > needs to be done? > > > > Seems like I got what you are looking for. Let me try to explain the > reasoning > and doubts regarding what I meant under my change. Please try to nail this in the commit message instead, and I'll then review that. /Jarkko
