Is it not important to validate the size of the write?

mr.name doesn't get copied. It'll become a pointer to stack garbage once this function returns.

"rw mutex" sounds like this should be a reader/writer lock, but presumably the mutex is really meant to serialize MMIO operations? Maybe mmio_mutex would be a better name?

The comment doesn't explain why.

I've rechecked the usage of the mutex. It was useless as mem.c:access_memory already locks on mmio accesses.

This can be replaced with

if (!(size == 1 || size == 2 || size == 4 || size == 8))
    return (EINVAL);
memcpy(dst, src, size);

Why bother trying to handle unaligned accesses at all? The code below becomes more complicated as a result (you need this is_offsetof macro), and its behaviour is hard to reason about.

warn/warnx don't need trailing newlines.

Suppose that the thread is currently processing a command. When it's done, it'll re-acquire the lock, then set crb->regs.ctrl_start.start = false, then go to sleep, so the signal is not acknowledged. Presumably that's not what we want here?

This can be defined on the stack. register_mem() just makes a copy of it, so there's no need for this to be a global variable.

When the thread is processing a command, the write is ignored by

			if (!start.start || crb->regs.ctrl_start.start)
				break;

That's the required behaviour by the TPM specification https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf

1. On a write of 0001h to the Start field:
   a. If the TPM is in the Command Reception state, the TPM SHALL transition to Command Execution and begin processing the command in the buffer.
   b. If the TPM is in any other State, the TPM SHALL ignore the write.
2. The TPM SHALL ignore writes of 0 to this field.
3. When the TPM completes command processing, the TPM SHALL clear this field to 0000h and transition to Command Completion.

Ok. Shouldn't we acquire the mutex before calling tpm_crb_mmiocpy() and checking !start.start || crb->regs.ctrl_start.start though?

I don't have a strong preference on that. The crb thread is only accessing cmd_size, cmd_addr, rsp_size, rsp_addr and data_buffer. My patch already acquires the mutex for accesses to those register.

I think it would be better to avoid the data race nonetheless.

Should this return error?