Re: [PATCH] tpm: crb: handle ACPI NVS memory region overlap

[Jarkko Sakkinen <jarkko@kernel.org>]

On Sun, Sep 20, 2026 at 02:33:12PM +0800, Delton Ding wrote:
> Hi Jarkko and MicroFish,
> 
> I'm following up on this discussion:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2652132.html
> 
> I would like to add a Fujitsu/Intel platform with what appears to be a
> related NVS resource reservation failure. I have not tested the proposed
> patch; this is an additional hardware report.
> 
> Hardware and software:
> 
>   System: FUJITSU FMVU14003
>   Board: FJNB2B5
>   CPU: Intel Core i5-7300U (family 6, model 142, stepping 9)
>   BIOS: Version 1.33, 11/25/2025
>   OS: NixOS 26.05
>   Running kernel: 7.2.5 (NixOS build)
>   /proc/sys/kernel/tainted: 0
> 
> On this machine, the TPM2 table specifies StartMethod 2 (ACPI Start).
> The control area, rather than the MMIO range reported by _CRS, lies
> inside ACPI NVS:
> 
>   TPM2 table (length 52, revision 3, checksum valid):
>     ControlAddress: 0x000000008ff6e000
>     StartMethod:    2
> 
>   Relevant /proc/iomem entries:
>     8d77f000-8ff7efff : ACPI Non-volatile Storage
>     fed40000-fed44fff : MSFT0101:00
> 
>   The TPM SSDT declares _CRS with base 0xfed40000 and length 0x5000.
>   It also contains:
> 
>     OperationRegion (TPMR, SystemMemory, 0xFED40000, 0x5000)
>     OperationRegion (TNVS, SystemMemory, 0x8FF6F000, 0x27)
>     OperationRegion (CONA, SystemMemory, 0x8FF6E000, 0x30)
> 
> The kernel reports:
> 
>   tpm_crb_acpi MSFT0101:00: error -EBUSY: can't request region for
> resource [mem 0x8ff6e000-0x8ff6e02f]
>   tpm_crb_acpi MSFT0101:00: probe with driver tpm_crb_acpi failed with error -16
>   ima: No TPM chip found, activating TPM-bypass!
> 
> Neither /dev/tpm0 nor /dev/tpmrm0 exists, and both /sys/class/tpm and
> /sys/class/tpmrm are empty. The ACPI device has status 15 and an existing
> platform physical_node, so platform device creation itself succeeded.
> 
> Based on the ACPI tables and source inspection, this appears to reach the
> iores == NULL path in crb_map_res() when crb_map_io() first maps the
> 48-byte control area. That area lies outside _CRS but within the NVS
> reservation. This is an inference from the tables and error range;
> I have not instrumented the driver to trace the call path.
> 
> Earlier boot logs show the same error and address on BIOS 1.10, 1.30
> with kernel 7.2.6. I do not have a known-good Linux kernel on this machine,
> so I am not reporting this as a confirmed regression. The TPM works in
> Windows on the same machine; its TPM firmware has also been updated.
> The vendor of the TPM is infineon, but the exact TPM firmware revision
> has not been collected here.
> 
> The missing devices cause systemd 260.2 to wait 90 seconds in the initrd
> and another 90 seconds after switching to the real root. We have prepared
> systemd.tpm2_wait=0 as a local workaround for the boot delay; it does not
> restore the TPM device.
> 
> Does this look like another instance of the NVS mapping issue, and is
> there a preferred revised patch or targeted diagnostic for this ACPI
> StartMethod 2 layout? I can provide the raw TPM2 table and TPM SSDT,
> including its disassembly, if useful.
> 
> Best Regards,
> Delton Ding

Yes it does.

I need to revisit this properly. Thanks for reminding.

Br, Jarkko