<bamse>
lumag: first thing that comes to mind is that i will now get -EINVAL back from trustzone because there is a platform-level fallback with "invalid" signature and my rootfs doesn't have the device-specific firmware - which today would result in -ENOENT "you don't have the firmware for this device"
<lumag>
bamse, hmm, true.
<lumag>
And it's harder to understand EINVAL
<lumag>
Do we have a change of getting the 'fused' or 'secured' status for the device?
<lumag>
But then we'd still need device-specific slpi
<lumag>
bamse, btw: with the sensors being now handled by adsp, which parts of adsp/asdp_dtb/etc becomes devices-specific?
<lumag>
(in the same way as we consider slpi.mbn being device-specific even for non-secured devices)