Re: [PATCH 0/3] crypto: ccp - two PSP init fixes, and the AMD BC-250

From: Mattia Tadini

Date: Tue Sep 22 2026 - 06:06:13 EST


On 9/21/26 10:10, Mario Limonciello wrote:
> Sorry; but what's the point of adding support? You can't access the
> crypto engine, it doesn't run SEV or TEE, it doesn't support DBC, it
> doesn't report HSTI.

Thanks for looking at it. One correction first, and the mistake is
mine: the cover letter is wrong about HSTI. The security reporting bit
is clear, but psp_populate_hsti() then asks through the platform access
mailbox, and on this board PSP_CMD_HSTI_QUERY does answer. With the
series applied on 7.2.6:

fused_part=1 debug_lock_on=1
boot_integrity=0 tsme_status=0
anti_rollback_status=0 rom_armor_enforced=0
rpmc_production_enabled=0 rpmc_spirom_available=0
hsp_tpm_available=0

> It seems that the capability register isn't even populated on this
> system.

It reads 0x00000002, the TEE bit and nothing else. That lone bit, with
no TEE behind it, is what patches 1 and 2 are about.

> To me it appears the patch series is a lot of "fixes" to let you
> read.... the bootloader version. Am I missing something else?

Only the above. Once the device is bound, userspace gets the bootloader
version (fwupd picks it up as "Secure Processor", bootloader
00.1c.01.02) and the HSTI attributes. Nothing more: no crypto engine,
no SEV, no TEE, and the firmware rejects the DBC command.

If that is not enough to carry an ID, I understand, and patch 3 can go.
Patches 1 and 2 then have no reason to go in either: with the current
table I don't know of a shipped part that sets the TEE bit on a pspv1
or pspv2 function, so they would only guard against a device that is
not there.

So: would you take the series with the HSTI data as the justification
for patch 3 (I would send a v2 with a corrected cover letter), or
should I drop it?

Thanks,
Mattia