[PATCH] ARM: i.MX: Kamstrup mx7 concentrator board support

[Rouven Czerwinski]

On Mon, 2021-04-12 at 13:24 +0200, Ahmad Fatoum wrote:
> Hello Lars,
> 
> On 12.04.21 12:45, Lars Pedersen wrote:
> > > > +#define BOARD_RESTART_GPIO IMX_GPIO_NR(7, 12)
> > > > +#define TPM_RESET_GPIO IMX_GPIO_NR(3, 8)
> > > > +
> > > > +static void kamstrup_mx7_tpm_reset(void)
> > > > +{
> > > > +     imx7_setup_pad(MX7D_PAD_LCD_DATA03__GPIO3_IO8);
> > > > +
> > > > +     gpio_request(TPM_RESET_GPIO, "tpm-reset");
> > > > +     gpio_direction_output(TPM_RESET_GPIO, 1);
> > > > +     mdelay(100);
> > > > +     gpio_set_value(TPM_RESET_GPIO, 0);
> > > > +     mdelay(100);
> > > > +     gpio_set_value(TPM_RESET_GPIO, 1);
> > > > +     gpio_free(TPM_RESET_GPIO);
> > > 
> > > We are trying to cut down on code that doesn't use the driver model.
> > > Couldn't this be represented as a gpio-hog in the device tree or
> > > a reset line for the SPI device?
> > 
> > I can't find anything in the DT binding for the SPI/TPM driver to use
> > a reset line.
> 
> Proper way would be for this to be added into Linux then,
> but that's out of scope for the patch here.
> 
> > Can a DT gpio-hog toggle the pin? Don't you need a
> > driver for this?
> 
> You can't pulse with a gpio-hog. I assumed the TPM is in reset by
> default.
> 
> > I see the following options:
> > 
> > 1) gpio-hog with a label and use new gpiolib in board.c.
> > 2) gpio-hog and control the pin in a boot script.
> 
> If there's no straight-forward way to do it without board code,
> it's ok the way it is with one change though: I missed it the first
> time, but your board breaks multi-image support because you don't
> check whether the initcall is indeed running on your board (See for
> example imx_v7_defconfig, which builds over a hundred boards at once).
> 
> Easiest way to get this right is to write a board driver.
> See arch/arm/boards/lxa-mc1/board.c for an example.

TPMs usually don't have a reset line since it is a hardware misdesign
if the reset needs to be done within the bootloader. This opens up the
TPM to an attack where the system is properly booted, unlocking keys
which are only accessible if the correct PCR sequence is send to the
TPM. Than the attacker resets the hardware/CPU, but potentially loads
up a different bootloader or tricks the bootloader into skipping the
TPM reset. This will leave the TPM keys accessible even if the system
has not been booted with the correct measured boot values. Boards with
TPMs should be designed so that a CPU-Reset always results in a TPM
Reset as well.

Regards,
Rouven