This might be because Juniper's code base isn't up to date with 16-current:
/w/main/src/sys/dev/tpm/tpm_crb.c:104:14: error: use of undeclared identifier 'ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON'

.acpi_sm = ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON,
           ^

/w/main/src/sys/dev/tpm/tpm_crb.c:151:25: error: invalid application of 'sizeof' to an incomplete type 'const struct tpmcrb_sm_cfg_map[]'

for (size_t i = 0; i < nitems(tpmcrb_sm_cfg_map); i++) {
                       ^~~~~~~~~~~~~~~~~~~~~~~~~

/w/main/src/sys/sys/param.h:321:26: note: expanded from macro 'nitems'
#define nitems(x) (sizeof((x)) / sizeof((x)[0]))

^~~~~

2 errors generated.

This patch didn't make my Juniper EX4000 catch-fire-and-burn.

missed a 'git add'

Follow request from https://reviews.freebsd.org/D53460

update per comments

In D53460#1224717, @imp wrote:

I'd prefer them in GENERIC. All of our kernel config knowledge is tribal. I'm sorry. DEFAULTS are for things that every kernel must have. Tpm is optional, so belongs in GENERIC. Cool stuff, but a large percentage of systems lack it. I'd also add it to MINIMAL since I didn't notice a way to discover it with PNP data.

I wish things were better documented.

In D53460#1224696, @imp wrote:

we're trying really really hard to not add anything to DEFAULTS. Why is this justified?

add

failed to 'git add' the DEPRECATION NOTICE section after I documented it in share/examples/mdoc/example.4

Let me give some motivation, since someone may ask "why" or "so what".
We're removing entropy sources from the enum at Juniper, (related to D53304) and I'm trying to reduce diffs to upstream. Since we're changing the order, why not semi-prefetch the 16.0 changes. RANDOM_PURE_START is currently pegged to RANDOM_PURE_SAFE which should go away for 16.0. Another way of looking at it - since I've already changed the 'enum entropy' twice in 16.0 (any KPI concerns), the reorder of RANDOM_PURE_TPM to re-peg RANDOM_PURE_START to make a smaller commit in the future for the removal of safe(4) should be non-contentious. Also, I hope to get this into 15.0-RELEASE so that RANDOM_PURE_START doesn't change in 15.x.

respond to comments

update

update

In D53390#1220118, @jhibbits wrote:

RANDOM_KEYBOARD and RANDOM_MOUSE can be masked away by sysctls. What is the need to remove them this way?

If your goal is to permit explicitly enabling or disabling random sources at compile time, I suggest going the KTR route, and having a RANDOM_COMPILE mask that defaults to everything enabled, allowing one to configure the random mask in the kernel config. This would centralize all this logic rather than having #ifdefs scattered around for each source.

In D53184#1216773, @emaste wrote:

Also share/man/man4/padlock.4 and any obsolete files additions

In D53184#1216799, @emaste wrote:

and share/man/man4/Makefile
and any .Xr padlock 4s

man page stuff

tweak comment

DEFAULTS

Move to DEFAULTS and add tier-2

No need to explicitly include opt_global.h

rebase HEAD

Can you add a summary in the commit log message instead of just "id: Clean up"

tweak