Could you please add a comment here to explain why 10 seconds was chosen? (It's not consistent across the tree: some drivers choose 0.1 seconds, while some others uses 4 seconds, 5 seconds, etc.)

Optional suggestions:

1. If I was you, I would probably use a "ticks" number here instead of seconds (e.g. (10 * hz)). It's not immediately obvious what unit was used here, and it would help clearing the ambiguity that way.

2. Another idea is to use a field in tpm_sc to store a pre-calculated number. The current code would do the multiplication every time the callout_reset is invoked.

Here we are scheduling a callout after 1 tick (0 is silently converted to 1 here), should we wait for TPM_HARVEST_INTERVAL for the first invoke?

Note that because we are scheduling a callout here, we should perform a callout_drain() on device detach.

If I understood the code correctly, does this mean we would no longer have future tpm20_harvest invokes if we ever get a zero-sized response from TPM? If so, is it intentional?

(I think we should still schedule it, or in other words, something like:

if (entropy_size > 0) {
	entropy_size = MIN(entropy_size, TPM_HARVEST_SIZE);
	memcpy(entropy, sc->buf + TPM_HEADER_SIZE + sizeof(uint16_t), entropy_size);
}

sx_xunlock(&sc->dev_lock);

if (entropy_size > 0) {
	random_harvest_queue(entropy, entropy_size, RANDOM_PURE_TPM);
}

callout_reset(&sc->harvest_callout, hz * TPM_HARVEST_INTERVAL,
		tpm20_harvest, sc);

)

Note that line 259 is similar but I'm not sure if a failed sc->transmit counts as a fatal error.

It's worthy to do this and tpm_tis.c change in a separate commit.