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

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Sep 25, 2026 at 05:25:02PM +0300, Jarkko Sakkinen wrote:
> 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.

I gave updated feedback.

Br, Jarkko