On Thu, Dec 14, 2017 at 05:06:14PM +0100, Alexander Steffen wrote: > When one of the commands during the auto_startup sequences does not return > TPM_RC_SUCCESS, tpm_chip_register misleadingly returns ENODEV, even though > a TPM device is definitely present. > > An error response during those sequences is indeed unexpected, so to > prevent subsequent errors, the kernel should not make use of the TPM > device. But user space applications still might be able to communicate with > the TPM, so they can be used to further diagnose and/or fix the problem. To > allow this, with this patch the device is still exported to user space, > even if a TPM error code has been received, but the kernel itself will not > be allowed to use the device for anything. > > This is not a hypothetical scenario, but there are devices in the wild that > show this behavior. With this fix, those devices can be recovered from > their failed state. > > Signed-off-by: Alexander Steffen <Alexander.Steffen@xxxxxxxxxxxx> Agree with Jason's comments. For SGX code that I've been upstreaming to arch/x86 tree the feedback was that local variable declarations should be in line length order, which makes sense to me i.e. startup_succesful should be the first declaration. why you need that variable anyway, cannot you deduce it from rc? /Jarkko
