A host IRQ resource is not necessarily an LPC SIRQ selector. Let the
frontend configure the route: ACPI uses the allocated _CRS interrupt and
_SRS when present, preserving the firmware selector, while ISA supplies a
separate, range-checked SIRQ. Match trigger and polarity to the host route
and TPM capabilities, including opaque INTRNG resource mappings.
Pass the firmware descriptor unchanged to _SRS; apply the x86 ISA polarity
override only when computing the TPM mode. ISA chips without rising-edge
support now poll instead of substituting a level mode for the host route.
For both FIFO drivers, require a complete GetRandom transport response and
a fresh DATA_AVAIL interrupt before selecting interrupt waits. Perform
the test with polling before publishing the device, and repeat it after
resume. During cold boot, defer the test and publication to an interrupt
configuration hook so the IRQ grace wait can sleep and the handler can run.
Drain the hook before teardown; failed deferred initialization remains
unpublished and can be detached safely. Missing or failed routes release
the handler and IRQ resource;
TPM 1.2 handler-setup failure now also falls back to polling.
Use monotonic deadlines for TPM 1.2 locality, status and burst polling.
Keep lifecycle locality waits uninterruptible, propagate command signal
errors, and terminate transfers when the burst wait expires instead of
retrying a zero burst indefinitely. Check VALID with the requested status
bits and retain bounded polling response retries. Interrupt waits retain
their original single-timeout budget and error return.
Arm only DATA_AVAIL before GO. Mask delivery on the first interrupt and
before relinquishing locality, preventing idle and repeated-source storms.
Bound interrupt sleeps so lost delivery can recover the current command
through polling. Defer unexpected-source cleanup to a task that can
acquire locality, and drain it before destroying driver locks. Preserve
an unread TPM 1.2 response when quiescing an already owned locality.
If the ithread cannot mask the TPM, yield for a tick with the host source
masked so a level storm cannot starve the command owner or cleanup worker.
Register INTR_SLEEPABLE | INTR_EXCL for both drivers, and reject firmware
shared routes before installing a handler. Such routes now poll: FreeBSD
does not allow sleepable shared handlers. Drain maskable events during
firmware programming without letting them validate or reject the IRQ test.
Retain the initial hardware-quiesce guarantee, including after _SRS:
initialization fails when delivery cannot be disabled, and a later unrecoverable
quiesce failure suspends command access. Known TPM 1.2 NOINTS quirks and
the TPM 2.0 polling hint remain effective. Frontends without an explicit
route method use polling.
Tested by: jrm (tpm 1.2 tis)
MFC after: 2 weeks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59657
The intention was clearly that these ACPI bits would be included for
arm64, but MACHINE_ARCH there is aarch64 -- correct the minor typo to
build everything that should be there.
Fixes: c2e9c5bbf0 ("tpm: Refactor TIS and add a SPI attachment")
We're building ACPI, so we need -DDEV_ACPI on CFLAGS. Nomally, the
kernel config brings this in, but there's no kernel directory for the
standalone build.
Sponsored by: Netflix
Summary:
Though mostly used in x86 devices, TPM can be used on others, with a
direct SPI attachment. Refactor the TPM 2.0 driver set to use an
attachment interface, and implement a SPI bus interface.
Test Plan:
Tested on a Raspberry Pi 4, with a GeeekPi TPM2.0 module (SLB9670
TPM) using security/tpm2-tools tpm2_getcaps for very light testing against the
spibus attachment.
Reviewed by: kd
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D45069
the ! operator should have been a ~ instead:
Merge r357348 from the clang 10.0.0 import branch:
Disable new clang 10.0.0 warnings about converting the result of
shift operations to a boolean in tpm(4):
sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of '<<' to a boolean; did you mean '(1 << (0)) != 0'? [-Werror,-Wint-in-bool-context]
WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD);
^
sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro 'TPM_CRB_CTRL_CANCEL_CMD'
#define TPM_CRB_CTRL_CANCEL_CMD BIT(0)
^
sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT'
#define BIT(x) (1 << (x))
^
Such warnings can be useful in C++ contexts, but not so much in kernel
drivers, where this type of bit twiddling is commonplace. So disable
it for this case.
Noticed by: cem
MFC after: 3 days
operations to a boolean in tpm(4):
sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of '<<' to a boolean; did you mean '(1 << (0)) != 0'? [-Werror,-Wint-in-bool-context]
WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD);
^
sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro 'TPM_CRB_CTRL_CANCEL_CMD'
#define TPM_CRB_CTRL_CANCEL_CMD BIT(0)
^
sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT'
#define BIT(x) (1 << (x))
^
Such warnings can be useful in C++ contexts, but not so much in kernel
drivers, where this type of bit twiddling is commonplace. So disable it
for this case.
MFC after: 3 days
Update the appropriate Makefile to build the new driver
together with the old one.
Submitted by: Kornel Duleba <[email protected]>
Reported by: kib
Obtained from: Semihalf
Sponsored by: Stormshield
Kevin Bowling