Re: [PATCH] tpm: crb: handle ACPI NVS memory region overlap
From: Jarkko Sakkinen
Date: Fri Sep 25 2026 - 10:25:17 EST
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@xxxxxxxxxxxxxxx/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