From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=none Received: from bmailout1.hostsharing.net (bmailout1.hostsharing.net [IPv6:2a01:37:1000::53df:5f64:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07C96110; Wed, 22 Nov 2023 03:29:53 -0800 (PST) Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 78B5830000D39; Wed, 22 Nov 2023 12:29:49 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 6D36237039; Wed, 22 Nov 2023 12:29:49 +0100 (CET) Date: Wed, 22 Nov 2023 12:29:49 +0100 From: Lukas Wunner To: Francesco Dolcini Cc: Lino Sanfilippo , Philipp Zabel , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-integrity@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH 2/2] reset: Add Infineon SLB9670 TPM reset driver Message-ID: <20231122112949.GA18812@wunner.de> References: <75b775d0526e72f292e0546a306b37680714686c.1695754856.git.lukas@wunner.de> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) On Wed, Nov 22, 2023 at 12:33:58AM +0100, Francesco Dolcini wrote: > On Tue, Sep 26, 2023 at 09:09:36PM +0200, Lukas Wunner wrote: > > Normally the platform firmware is responsible for taking a Trusted > > Platform Module out of reset on boot and storing measurements into it. > > > > However if the platform firmware is incapable of doing that -- as is the > > case on the Raspberry Pi -- then the onus is on the kernel to take the > > TPM out of reset before trying to attach a driver to it. > > > > Provide a reset driver for such platforms. > > > > The Infineon SLB9670 TPM requires a specific reset sequence on its RST# > > pin which is documented in sections 5.4 and 5.5 of the datasheet: > > Are you really sure that this change is required? > I have seen the RST# Timing diagram in the datasheet, however I wonder > if a reset is required at all during power-up, for example. If the RST# pin is not toggled at all upon a warm reset (reboot), the TPM will remain in whatever state it was during the previous boot. Also, the pin controller connected to RST# might be reset upon a reboot (think of a SoC internal pin controller setting all its registers to 0) and RST# might be asserted as a result. It is then necessary to take the TPM out of reset. > Not to mention that I would have expected some firmware to implement > such reset timing and I was not able to find any (I looked at > arm/arm64), if this is really required I the driver can work at all? > Which platform firmware implements such reset sequence? I can't answer how a TPM is reset by firmware on arm/arm64, you'd have to ask an FAE at ARM. Normally I'd expect firmware in ROM do that so all subsequently executed code which is mutable (EFI, bootloader, kernel) can be measured. Again, on simple platforms such as the Raspberry Pi there's no support to reset a TPM in ROM. > Not to mention that I was able to see the driver probe succeed in a > similar setup to the one you are describing in the commit message > (different board, arm64, but nothing done by the platform firmware). Hm, is the RST# pin even connected on that board? Thanks, Lukas