Hi Michal, [...] > >>>> Thanks for explaining. This got me to re-read the existing tests and > >>>> while > >>>> none of it is as clear as I would like, your example here is just as > >>>> clear as the > >>>> rest, so it's fine and I'll pick it up soon. > >>> > >>> I see this patch is not yet applied on the repo, could you please let me > >>> know when this will be applied? > >> > >> Ilias, since you've said you'd review TPM related patches, does this: > >> https://patchwork.ozlabs.org/project/uboot/patch/1624340962-91190-1-git-send-email-t.karthik.re...@xilinx.com/ > >> work for you? Thanks. > >> > > > > I am not too familiar with the pytest framework we have, but couldn't > > we do this automatically? > > IOW instead of explicitly adding a variable, do a 'tpm info' and if > > that doesn't return a valid device, skip the tests. > > Unfortunately not. Because imagine how this will work if you have tpm on > board but there is bug in the driver that it is not probed. Then tpm > info will return no device and all tests will be silently skipped.
Looking at tpm_info I think it's the other way around, isn't it ? tpm_info will call get_tpm(), which in theory will fail if there's no TPM probed or not present. So even in that case the self-tests will fail. OTOH the 'tpm info' command just returns a CMD Success/Failure, so it's not easy to figure out if a TPM is indeed present or not without refactoring the cmdline interface. So I think this is reasonable for now Acked-by: Ilias Apalodimas <ilias.apalodi...@linaro.org> > > It would be much better it the test itself was designed from the > beginning that you need to state that board has TPM. But it wasn't > that's why we designed this patch in a way that you declare that you > want to skip these tests which is OK. > > It doesn't make any sense to go back and start to have multiple > defconfigs for different configurations where all boards works quite > well with one defconfig. That's why we enable TPM because it on SOM but > we need to be able to disable these tests on others. > > Thanks, > Michal > > >