Hi, => Last update and happy end To remember what the issue was : kernel panic on reboot on a custom board equipped with CPU NXP LS1043a and TMP V2.0 Infineon slb9670 (spi interface). What we did but didn't fix the issue : update our kernel to 5.10.8 => panic still occurs What we did and fix the issue => use this patch : https://lkml.org/lkml/2020/7/9/1242 Now everything is working as expected and no more panic. Thanks again for your support. Mit freundlichen Grüßen Florian Manoël Siemens AG Digital Industries Process Automation DI PA DCP R&D 2 Östliche Rheinbrückenstr. 50 76187 Karlsruhe, Deutschland Tel.: +49 721 667-20051 mailto:florian.manoel@xxxxxxxxxxx www.siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322 -----Ursprüngliche Nachricht----- Von: Jarkko Sakkinen <jarkko@xxxxxxxxxx> Gesendet: Samstag, 30. Januar 2021 00:25 An: Manoel, Florian (DI PA DCP R&D 2) <florian.manoel@xxxxxxxxxxx> Cc: linux-integrity@xxxxxxxxxxxxxxx; Fuchs, Andreas <andreas.fuchs@xxxxxxxxxxxxxxxxx>; Peter.Huewe@xxxxxxxxxxxx; joshz@xxxxxxxxxx Betreff: Re: TPM V2: kernel panic on linux reboot On Wed, Jan 27, 2021 at 02:51:56PM +0000, mailto:florian.manoel@xxxxxxxxxxx wrote: > Hi, > > thanks for your support, > an update on the kernel panic I am experiencing while trying to set up a TPM V2 on an ARM64 NXP LS1043a custom board : > We updated the kernel from 4.19.144 to 4.19.165, no changes, the panic is still occurring. > > I started to debug, and identify what I believe is the point where this kernel panic is triggered: > '/drivers/char/tpm/tpm-interface.c' > > " > if (chip->ops->clk_enable != NULL) > chip->ops->clk_enable(chip, true); > " BTW, that is quite stupid code from us. In all cases a direct call to tpm_tis_clkrun_enable() would make a lot more sense. Anyway, this does not explain the bug. This just hurts my eyes, that's all.. Anyway we, can disclose that function given the IS_ENABLED() check early on: static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value) { struct tpm_tis_data *data = dev_get_drvdata(&chip->dev); u32 clkrun_val; if (!IS_ENABLED(CONFIG_X86) || !is_bsw() || !data->ilb_base_addr) return; I think a safe conclusion to make that chip->ops is NULL, and causes the panic. > It looks a lot like an issue that is described here with a TPM 1.2 : > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchro > mium.googlesource.com%2Fchromiumos%2Fthird_party%2Fkernel%2F%2B%2F01d1 > d6e2a1a74b9b8acba7d5eee67fe83e914aa1&data=04%7C01%7Cflorian.manoel > %40siemens.com%7Cbc4c3252c2d74220ab9308d8c4ad25ab%7C38ae3bcd95794fd4ad > dab42e1495d55a%7C1%7C0%7C637475595224343568%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 > 0&sdata=VVG4RNo6gtCj8X951xMX%2FsypZ34b1mvaROJmP87r5w8%3D&reser > ved=0 I get: "NOT_FOUND: Requested entity was not found" Please try out with the mainline kernel. I only now spotted that you are using a really old kernel. And I have no idea how patched the kernel is. I misread last time that this happening with the mainline kernel. Debugging downstream kernel is unfortunately out-of-scope. When you have test data with the latest unpatched mainline kernel, it makes sense to look this further. /Jarkko
