dt-bindings: tpm: Clean all the things
Subsystems (3)
v2 cover dt-bindings: tpm: Clean all the things
TPM dt-bindings cleanup, take two.
Changes v1 -> v2:
* [PATCH 1/3]:
* Overhaul i2c compatible definitions. Turns out that the fallback tcg,tpm-tis-i2c only applies to chips conforming to the PTP spec, wheras other chips use a vendor-specific interface and thus omit the fallback.
* Don't enforce fallback compatible tcg,tpm_tis-spi for google,cr50.
* Add nodename restriction to tpm-common.yaml.
* Add clock constraints that were previously documented for
infineon,slb9635tt and infineon,slb9645tt.
* Drop google,cr50 SPI example (Rob).
* Fix errors for linux,sml-base, linux,sml-size and lpcpd-gpios properties (Rob).
* [PATCH 2/3]:
* Amend device_type with enum (Rob).
* Fix nodename in example (Rob).
Link to v1:
https://lore.kernel.org/linux-devicetree/[email protected]/
Lukas Wunner (3):
dt-bindings: tpm: Consolidate TCG TIS bindings
dt-bindings: tpm: Convert IBM vTPM bindings to DT schema
dt-bindings: tpm: Document Microsoft fTPM bindings
.../bindings/security/tpm/google,cr50.txt | 19 --- .../bindings/security/tpm/ibmvtpm.txt | 41 ------- .../bindings/security/tpm/st33zp24-i2c.txt | 34 ------ .../bindings/security/tpm/st33zp24-spi.txt | 32 ----- .../bindings/security/tpm/tpm-i2c.txt | 26 ---- .../bindings/security/tpm/tpm_tis_mmio.txt | 25 ---- .../bindings/security/tpm/tpm_tis_spi.txt | 23 ---- .../devicetree/bindings/tpm/ibm,vtpm.yaml | 104 ++++++++++++++++ .../bindings/tpm/microsoft,ftpm.yaml | 48 ++++++++ .../bindings/tpm/tcg,tpm-tis-i2c.yaml | 113 ++++++++++++++++++ .../bindings/tpm/tcg,tpm-tis-mmio.yaml | 49 ++++++++ .../bindings/tpm/tcg,tpm_tis-spi.yaml | 79 ++++++++++++ .../devicetree/bindings/tpm/tpm-common.yaml | 72 +++++++++++ .../devicetree/bindings/trivial-devices.yaml | 16 --- 14 files changed, 465 insertions(+), 216 deletions(-) delete mode 100644 Documentation/devicetree/bindings/security/tpm/google,cr50.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt create mode 100644 Documentation/devicetree/bindings/tpm/ibm,vtpm.yaml create mode 100644 Documentation/devicetree/bindings/tpm/microsoft,ftpm.yaml create mode 100644 Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml create mode 100644 Documentation/devicetree/bindings/tpm/tcg,tpm-tis-mmio.yaml create mode 100644 Documentation/devicetree/bindings/tpm/tcg,tpm_tis-spi.yaml create mode 100644 Documentation/devicetree/bindings/tpm/tpm-common.yaml
Signature · 1 line
2.40.1
PATCH v2 1/3 dt-bindings: tpm: Consolidate TCG TIS bindings
A significant number of Trusted Platform Modules conform to the "TIS" specification published by the Trusted Computing Group ("TCG PC Client Specific TPM Interface Specification"). These chips typically use an SPI, I²C or LPC bus as transport (via MMIO in the latter case). Some of them even support multiple of those buses (selectable through a config strap) or the same chip is available in multiple SKUs, each with a different bus interface.
The devicetree bindings for these TPMs have not been converted to DT schema yet and are spread out across 3 generic files and 3 chip-specific files. A few TPM compatible strings were added to trivial-devices.yaml even though additional properties are documented in the plaintext bindings.
Consolidate the devicetree bindings into 3 files, one per bus.
Move common properties to a separate tpm-common.yaml.
Document compatible strings which are supported by the TPM TIS driver but were neglected to be added to the devicetree bindings.
Document the memory-region property recently introduced by commit 1e2714bb83fc ("tpm: Add reserved memory event log").
---
Changes v1 -> v2:
* Overhaul i2c compatible definitions. Turns out that the fallback tcg,tpm-tis-i2c only applies to chips conforming to the PTP spec, wheras other chips use a vendor-specific interface and thus omit the fallback.
* Don't enforce fallback compatible tcg,tpm_tis-spi for google,cr50.
* Add nodename restriction to tpm-common.yaml.
* Add clock constraints that were previously documented for
infineon,slb9635tt and infineon,slb9645tt.
* Drop google,cr50 SPI example (Rob).
* Fix errors for linux,sml-base, linux,sml-size and lpcpd-gpios properties (Rob).
.../bindings/security/tpm/google,cr50.txt | 19 --- .../bindings/security/tpm/st33zp24-i2c.txt | 34 ------ .../bindings/security/tpm/st33zp24-spi.txt | 32 ----- .../bindings/security/tpm/tpm-i2c.txt | 26 ---- .../bindings/security/tpm/tpm_tis_mmio.txt | 25 ---- .../bindings/security/tpm/tpm_tis_spi.txt | 23 ---- .../bindings/tpm/tcg,tpm-tis-i2c.yaml | 113 ++++++++++++++++++ .../bindings/tpm/tcg,tpm-tis-mmio.yaml | 49 ++++++++ .../bindings/tpm/tcg,tpm_tis-spi.yaml | 79 ++++++++++++ .../devicetree/bindings/tpm/tpm-common.yaml | 72 +++++++++++ .../devicetree/bindings/trivial-devices.yaml | 16 --- 11 files changed, 313 insertions(+), 175 deletions(-) delete mode 100644 Documentation/devicetree/bindings/security/tpm/google,cr50.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt delete mode 100644 Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt create mode 100644 Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml create mode 100644 Documentation/devicetree/bindings/tpm/tcg,tpm-tis-mmio.yaml create mode 100644 Documentation/devicetree/bindings/tpm/tcg,tpm_tis-spi.yaml create mode 100644 Documentation/devicetree/bindings/tpm/tpm-common.yaml
Documentation/devicetree/bindings/security/tpm/google,cr50.txt deleted +0 -19
@@ -1,19 +0,0 @@ -* H1 Secure Microcontroller with Cr50 Firmware on SPI Bus. - -H1 Secure Microcontroller running Cr50 firmware provides several -functions, including TPM-like functionality. It communicates over -SPI using the FIFO protocol described in the PTP Spec, section 6. - -Required properties: -- compatible: Should be "google,cr50". -- spi-max-frequency: Maximum SPI frequency. - -Example: - -&spi0 { - tpm@0 { - compatible = "google,cr50"; - reg = <0>; - spi-max-frequency = <800000>; - }; -};
Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt deleted +0 -34
@@ -1,34 +0,0 @@ -* STMicroelectronics SAS. ST33ZP24 TPM SoC - -Required properties: -- compatible: Should be "st,st33zp24-i2c". -- clock-frequency: I²C work frequency. -- reg: address on the bus - -Optional ST33ZP24 Properties: -- interrupts: GPIO interrupt to which the chip is connected -- lpcpd-gpios: Output GPIO pin used for ST33ZP24 power management D1/D2 state. -If set, power must be present when the platform is going into sleep/hibernate mode. - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. - -Example (for ARM-based BeagleBoard xM with ST33ZP24 on I2C2): - -&i2c2 { - - - st33zp24: st33zp24@13 { - - compatible = "st,st33zp24-i2c"; - - reg = <0x13>; - clock-frequency = <400000>; - - interrupt-parent = <&gpio5>; - interrupts = <7 IRQ_TYPE_LEVEL_HIGH>; - - lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>; - }; -};
Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt deleted +0 -32
@@ -1,32 +0,0 @@ -* STMicroelectronics SAS. ST33ZP24 TPM SoC - -Required properties: -- compatible: Should be "st,st33zp24-spi". -- spi-max-frequency: Maximum SPI frequency (<= 10000000). - -Optional ST33ZP24 Properties: -- interrupts: GPIO interrupt to which the chip is connected -- lpcpd-gpios: Output GPIO pin used for ST33ZP24 power management D1/D2 state. -If set, power must be present when the platform is going into sleep/hibernate mode. - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. - -Example (for ARM-based BeagleBoard xM with ST33ZP24 on SPI4): - -&mcspi4 { - - - st33zp24@0 { - - compatible = "st,st33zp24-spi"; - - spi-max-frequency = <10000000>; - - interrupt-parent = <&gpio5>; - interrupts = <7 IRQ_TYPE_LEVEL_HIGH>; - - lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>; - }; -};
Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt deleted +0 -26
@@ -1,26 +0,0 @@ -* Device Tree Bindings for I2C based Trusted Platform Module(TPM) - -Required properties: - -- compatible : 'manufacturer,model', eg. nuvoton,npct650 -- label : human readable string describing the device, eg. "tpm" -- linux,sml-base : 64-bit base address of the reserved memory allocated for - the firmware event log -- linux,sml-size : size of the memory allocated for the firmware event log - -Optional properties: - -- powered-while-suspended: present when the TPM is left powered on between - suspend and resume (makes the suspend/resume - callbacks do nothing). - -Example (for OpenPower Systems with Nuvoton TPM 2.0 on I2C) ----------------------------------------------------------- - -tpm@57 { - reg = <0x57>; - label = "tpm"; - compatible = "nuvoton,npct650", "nuvoton,npct601"; - linux,sml-base = <0x7f 0xfd450000>; - linux,sml-size = <0x10000>; -};
Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt deleted +0 -25
@@ -1,25 +0,0 @@ -Trusted Computing Group MMIO Trusted Platform Module - -The TCG defines multi vendor standard for accessing a TPM chip, this -is the standard protocol defined to access the TPM via MMIO. Typically -this interface will be implemented over Intel's LPC bus. - -Refer to the 'TCG PC Client Specific TPM Interface Specification (TIS)' TCG -publication for the specification. - -Required properties: - -- compatible: should contain a string below for the chip, followed by - "tcg,tpm-tis-mmio". Valid chip strings are: - * "atmel,at97sc3204" -- reg: The location of the MMIO registers, should be at least 0x5000 bytes -- interrupts: An optional interrupt indicating command completion. - -Example: - - tpm_tis@90000 { - compatible = "atmel,at97sc3204", "tcg,tpm-tis-mmio"; - reg = <0x90000 0x5000>; - interrupt-parent = <&EIC0>; - interrupts = <1 2>; - };
Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt deleted +0 -23
@@ -1,23 +0,0 @@ -Required properties: -- compatible: should be one of the following - "st,st33htpm-spi" - "infineon,slb9670" - "tcg,tpm_tis-spi" -- spi-max-frequency: Maximum SPI frequency (depends on TPMs). - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. - -Example (for ARM-based BeagleBoard xM with TPM_TIS on SPI4): - -&mcspi4 { - - - tpm_tis@0 { - - compatible = "tcg,tpm_tis-spi"; - - spi-max-frequency = <10000000>; - }; -};
Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml new file +113 -0
113 lines not on this page · raw message
Documentation/devicetree/bindings/tpm/tcg,tpm-tis-mmio.yaml new file +49 -0
49 lines not on this page · raw message
Documentation/devicetree/bindings/tpm/tcg,tpm_tis-spi.yaml new file +79 -0
79 lines not on this page · raw message
Documentation/devicetree/bindings/tpm/tpm-common.yaml new file +72 -0
72 lines not on this page · raw message
Documentation/devicetree/bindings/trivial-devices.yaml +0 -16
@@ -49,8 +49,6 @@ properties: - ams,iaq-core # i2c serial eeprom (24cxx) - at,24c08 - # i2c trusted platform module (TPM) - - atmel,at97sc3204t # ATSHA204 - i2c h/w symmetric crypto module - atmel,atsha204 # ATSHA204A - i2c h/w symmetric crypto module
@@ -145,12 +143,6 @@ properties: - infineon,ir38263 # Infineon IRPS5401 Voltage Regulator (PMIC) - infineon,irps5401 - # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) - - infineon,slb9635tt - # Infineon SLB9645 I2C TPM (new protocol, max 400khz) - - infineon,slb9645tt - # Infineon SLB9673 I2C TPM 2.0 - - infineon,slb9673 # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor - infineon,tlv493d-a1b6 # Infineon Multi-phase Digital VR Controller xdpe11280
@@ -301,10 +293,6 @@ properties: - national,lm85 # I2C ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator - national,lm92 - # i2c trusted platform module (TPM) - - nuvoton,npct501 - # i2c trusted platform module (TPM2) - - nuvoton,npct601 # Nuvoton Temperature Sensor - nuvoton,w83773g # OKI ML86V7667 video decoder
@@ -349,8 +337,6 @@ properties: - silabs,si7020 # Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply - skyworks,sky81452 - # Socionext SynQuacer TPM MMIO module - - socionext,synquacer-tpm-mmio # SparkFun Qwiic Joystick (COM-15168) with i2c interface - sparkfun,qwiic-joystick # i2c serial eeprom (24cxx)
@@ -405,8 +391,6 @@ properties: - winbond,w83793 # Vicor Corporation Digital Supervisor - vicor,pli1209bc - # i2c trusted platform module (TPM) - - winbond,wpct301 required: - compatible
Signature · 1 line
2.40.1
PATCH v2 2/3 dt-bindings: tpm: Convert IBM vTPM bindings to DT schema
In reply to Lukas WunnerConvert the devicetree bindings for the IBM Virtual Trusted Platform Module to DT schema. Drop properties which are already documented in tpm-common.yaml.
Document the "IBM,vtpm20" compatible string introduced by commit 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2").
---
Changes v1 -> v2:
* Amend device_type with enum (Rob).
* Fix nodename in example (Rob).
.../bindings/security/tpm/ibmvtpm.txt | 41 ------- .../devicetree/bindings/tpm/ibm,vtpm.yaml | 104 ++++++++++++++++++ 2 files changed, 104 insertions(+), 41 deletions(-) delete mode 100644 Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt create mode 100644 Documentation/devicetree/bindings/tpm/ibm,vtpm.yaml
Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt deleted +0 -41
@@ -1,41 +0,0 @@ -* Device Tree Bindings for IBM Virtual Trusted Platform Module(vtpm) - -Required properties: - -- compatible : property name that conveys the platform architecture - identifiers, as 'IBM,vtpm' -- device_type : specifies type of virtual device -- interrupts : property specifying the interrupt source number and - sense code associated with this virtual I/O Adapters -- ibm,my-drc-index : integer index for the connector between the device - and its parent - present only if Dynamic - Reconfiguration(DR) Connector is enabled -- ibm,#dma-address-cells: specifies the number of cells that are used to - encode the physical address field of dma-window - properties -- ibm,#dma-size-cells : specifies the number of cells that are used to - encode the size field of dma-window properties -- ibm,my-dma-window : specifies DMA window associated with this virtual - IOA -- ibm,loc-code : specifies the unique and persistent location code - associated with this virtual I/O Adapters -- linux,sml-base : 64-bit base address of the reserved memory allocated - for the firmware event log -- linux,sml-size : size of the memory allocated for the firmware event log - -Example (IBM Virtual Trusted Platform Module) ---------------------------------------------- - - vtpm@30000003 { - ibm,#dma-size-cells = <0x2>; - compatible = "IBM,vtpm"; - device_type = "IBM,vtpm"; - ibm,my-drc-index = <0x30000003>; - ibm,#dma-address-cells = <0x2>; - linux,sml-base = <0xc60e 0x0>; - interrupts = <0xa0003 0x0>; - ibm,my-dma-window = <0x10000003 0x0 0x0 0x0 0x10000000>; - ibm,loc-code = "U8286.41A.10082DV-V3-C3"; - reg = <0x30000003>; - linux,sml-size = <0xbce10200>; - };
Documentation/devicetree/bindings/tpm/ibm,vtpm.yaml new file +104 -0
104 lines not on this page · raw message
Signature · 1 line
2.40.1
PATCH v2 3/3 dt-bindings: tpm: Document Microsoft fTPM bindings
In reply to Lukas WunnerA driver for Microsoft's firmware-based Trusted Platform Module (fTPM) was merged with commit 09e574831b27 ("tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE"), but its devicetree bindings were not.
This is the only remaining undocumented compatible string for a TPM, so add a DT schema based on the patch linked below.
--- .../bindings/tpm/microsoft,ftpm.yaml | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/tpm/microsoft,ftpm.yaml
Documentation/devicetree/bindings/tpm/microsoft,ftpm.yaml new file +48 -0
@@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/tpm/microsoft,ftpm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microsoft firmware-based Trusted Platform Module (fTPM) + +maintainers: + - Thirupathaiah Annapureddy <[email protected]> + - Sasha Levin <[email protected]> + +description: | + Commodity CPU architectures, such as ARM and Intel CPUs, have started to + offer trusted computing features in their CPUs aimed at displacing dedicated + trusted hardware. Unfortunately, these CPU architectures raise serious + challenges to building trusted systems because they omit providing secure + resources outside the CPU perimeter. + + Microsoft's firmware-based TPM 2.0 (fTPM) leverages ARM TrustZone to overcome + these challenges and provide software with security guarantees similar to + those of dedicated trusted hardware. + + https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/ + https://github.com/Microsoft/ms-tpm-20-ref/tree/main/Samples/ARM32-FirmwareTPM + +properties: + compatible: + enum: + - microsoft,ftpm + +required: + - compatible + - linux,sml-base + - linux,sml-size + +allOf: + - $ref: tpm-common.yaml# + +unevaluatedProperties: false + +examples: + - | + tpm { + compatible = "microsoft,ftpm"; + linux,sml-base = <0x0 0xc0000000>; + linux,sml-size = <0x10000>; + };
Signature · 1 line
2.40.1
Re: [PATCH v2 1/3] dt-bindings: tpm: Consolidate TCG TIS bindings
In reply to Lukas WunnerQuoted 35 lines · Lukas Wunner
A significant number of Trusted Platform Modules conform to the "TIS" specification published by the Trusted Computing Group ("TCG PC Client Specific TPM Interface Specification"). These chips typically use an SPI, I²C or LPC bus as transport (via MMIO in the latter case). Some of them even support multiple of those buses (selectable through a config strap) or the same chip is available in multiple SKUs, each with a different bus interface.
The devicetree bindings for these TPMs have not been converted to DT schema yet and are spread out across 3 generic files and 3 chip-specific files. A few TPM compatible strings were added to
trivial-devices.yamleven though additional properties are documented in the plaintext bindings.Consolidate the devicetree bindings into 3 files, one per bus.
Move common properties to a separate
tpm-common.yaml.Document compatible strings which are supported by the TPM TIS driver but were neglected to be added to the devicetree bindings.
Document the memory-region property recently introduced by commit
1e2714bb83fc("tpm: Add reserved memory event log").Signed-off-by Lukas Wunner <[email protected]>---
Changes v1 -> v2:
* Overhaul i2c compatible definitions. Turns out that the fallback tcg,tpm-tis-i2c only applies to chips conforming to the PTP spec, wheras other chips use a vendor-specific interface and thus omit the fallback.
* Don't enforce fallback compatible tcg,tpm_tis-spi for google,cr50.
* Add nodename restriction totpm-common.yaml.
* Add clock constraints that were previously documented for
Quoted 2 lines
infineon,slb9635tt and infineon,slb9645tt.* Drop google,cr50 SPI example (Rob).
That's going to avoid a warning in the examples, but it's going to fail any actual google,c50 SPI user. What's going to happen is both the SPI and I2C TPM schemas will be applied. Any SPI based cases will fail if they have SPI properties because the I2C schema won't allow them. If there is no fallback for google,cr50, then you must do a separate schema doc (well, you could do an if/then schema in tcg,tpm-tis-i2c.yaml to reference spi-peripheral-props.yaml, but that would look kind of odd).
Rob
Re: [PATCH v2 1/3] dt-bindings: tpm: Consolidate TCG TIS bindings
Quoted 16 lines · Rob Herring
Quoted 15 lines · On Mon, Nov 27, 2023 at 8:09AM Lukas Wunner <[email protected]> wrote:
A significant number of Trusted Platform Modules conform to the "TIS" specification published by the Trusted Computing Group ("TCG PC Client Specific TPM Interface Specification"). These chips typically use an SPI, I²C or LPC bus as transport (via MMIO in the latter case). Some of them even support multiple of those buses (selectable through a config strap) or the same chip is available in multiple SKUs, each with a different bus interface.
The devicetree bindings for these TPMs have not been converted to DT schema yet and are spread out across 3 generic files and 3 chip-specific files. A few TPM compatible strings were added to
trivial-devices.yamleven though additional properties are documented in the plaintext bindings.Consolidate the devicetree bindings into 3 files, one per bus.
[...]
Quoted 11 lines
Quoted 2 lines
Changes v1 -> v2:
* Drop google,cr50 SPI example (Rob).That's going to avoid a warning in the examples, but it's going to fail any actual google,c50 SPI user. What's going to happen is both the SPI and I2C TPM schemas will be applied. Any SPI based cases will fail if they have SPI properties because the I2C schema won't allow them. If there is no fallback for google,cr50, then you must do a separate schema doc (well, you could do an if/then schema in tcg,tpm-tis-i2c.yaml to reference
spi-peripheral-props.yaml, but that would look kind of odd).
I'm wondering if a "select:" property in the schema would be a viable (and acceptable) way to solve this.
Ideally the validator would match a regex against the $nodename of the parent and see if it contains "spi" or "i2c". But I think matching against the parent's $nodename isn't possible, is it? I can only match the TPM's $nodename, right?
All the devicetree nodes in arch/arm64/boot/dts/* containing a google,cr50 compatible string have an spi-max-frequency property if they're attached to SPI. So I think it may be possible to select the i2c or spi schema based on presence of that property if the compatible string is google,cr50. A bit kludgy perhaps but if there's no better option?
What I don't like about creating a custom schema for google,cr50 is that there may be other chips in the future which support multiple buses, so we'd need an spi+i2c schema and probably also an spi+i2c+mmio, i2c+mmio, spi+mmio schema. It gets messy. Granted we could enforce that these newly added chips use a fallback compatible that we could select the schema with. Still, automatically selecting the right schema would be better, in particular if I could somehow match against the $nodename of the parent.
Thoughts?
Thanks,
Lukas
Re: [PATCH v2 1/3] dt-bindings: tpm: Consolidate TCG TIS bindings
Quoted 31 lines · Lukas Wunner
Quoted 16 lines · Rob Herring
Quoted 15 lines · On Mon, Nov 27, 2023 at 8:09AM Lukas Wunner <[email protected]> wrote:
A significant number of Trusted Platform Modules conform to the "TIS" specification published by the Trusted Computing Group ("TCG PC Client Specific TPM Interface Specification"). These chips typically use an SPI, I涎 or LPC bus as transport (via MMIO in the latter case). Some of them even support multiple of those buses (selectable through a config strap) or the same chip is available in multiple SKUs, each with a different bus interface.
The devicetree bindings for these TPMs have not been converted to DT schema yet and are spread out across 3 generic files and 3 chip-specific files. A few TPM compatible strings were added to
trivial-devices.yamleven though additional properties are documented in the plaintext bindings.Consolidate the devicetree bindings into 3 files, one per bus.
[...]
Quoted 11 lines
Quoted 2 lines
Changes v1 -> v2:
* Drop google,cr50 SPI example (Rob).That's going to avoid a warning in the examples, but it's going to fail any actual google,c50 SPI user. What's going to happen is both the SPI and I2C TPM schemas will be applied. Any SPI based cases will fail if they have SPI properties because the I2C schema won't allow them. If there is no fallback for google,cr50, then you must do a separate schema doc (well, you could do an if/then schema in tcg,tpm-tis-i2c.yaml to reference
spi-peripheral-props.yaml, but that would look kind of odd).
Quoted 6 lines
I'm wondering if a "select:" property in the schema would be a viable (and acceptable) way to solve this.
Ideally the validator would match a regex against the $nodename of the parent and see if it contains "spi" or "i2c". But I think matching against the parent's $nodename isn't possible, is it?
No. I've thought of adding something like that, but haven't.
Quoted 2 lines
I can only
match the TPM's $nodename, right?
Right.
Quoted 6 lines
All the devicetree nodes in
arch/arm64/boot/dts/*containing a google,cr50 compatible string have an spi-max-frequency property if they're attached to SPI. So I think it may be possible to select the i2c or spi schema based on presence of that property if the compatible string is google,cr50. A bit kludgy perhaps but if there's no better option?
I don't think we should make spi-max-frequency required.
Quoted 8 lines
What I don't like about creating a custom schema for google,cr50 is that there may be other chips in the future which support multiple buses, so we'd need an spi+i2c schema and probably also an spi+i2c+mmio, i2c+mmio, spi+mmio schema. It gets messy. Granted we could enforce that these newly added chips use a fallback compatible that we could select the schema with. Still, automatically selecting the right schema would be better, in particular if I could somehow match against the $nodename of the parent.
Seems like more of a theoretical problem than realistic. I think cr50 is a bit of a special case. It also has other functions AIUI and maybe we'll need other DT properties. If we do have new ones, I think enforcing the fallback should be enough. After all, that's what you tried to do in v1, but we're stuck with it for cr50.
Another option is combine the SPI and I2C schemas. Then you just need:
if:
properties:
compatible:
contains:
enum:
- tcg,tpm_tis-spi
- google,cr50
then:
$ref: spi-peripheral-props.yaml
I would leave MMIO separate in that case. Seems unlikely something would have MMIO and a serial interface.
I still lean towards a separate schema for cr50 over this.
BTW, there's now another conversion patch[1] which I forgot to Cc you on my reply.
Rob
Re: [PATCH v2 1/3] dt-bindings: tpm: Consolidate TCG TIS bindings
Quoted 6 lines · Rob Herring
Quoted 3 lines · On Wed, Dec 13, 2023 at 10:23AM Lukas Wunner <[email protected]> wrote:
Ideally the validator would match a regex against the $nodename of the parent and see if it contains "spi" or "i2c". But I think matching against the parent's $nodename isn't possible, is it?
No. I've thought of adding something like that, but haven't.
Please consider this a feature request. :)
It would be good if it were possible to define constraints not just for the $nodename of the parent, but any of its properties.
E.g. with i2c, the clock-frequency is set at the host controller's devicetree node, not at each attached i2c peripheral's node. For ACPI, i2c_acpi_find_bus_speed() walks the bus to find the highest clock speed supported by all attached i2c peripherals, but for OF, the onus is on the devicetree author to manually determine the clock.
Thus, for a TPM such as infineon,slb9635tt which only supports 100 kHz, I want to validate that the parent node's clock-frequency is less than or equal to that.
In Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt there's an example showing a clock-frequency property at the peripheral's node and I mistakenly carried that over to the yaml schema. A look at the code reveals that's entirely bogus so I'll drop the clock-frequency property in v3. I will retain textual hints that infineon,slb9635tt is limited to 100 kHz and infineon,slb9645tt to 400 kHz, but as it stands I can't define rules that would allow the validator to check that automatically.
Thanks,
Lukas
Re: [PATCH v2 1/3] dt-bindings: tpm: Consolidate TCG TIS bindings
Quoted 7 lines · Lukas Wunner
Quoted 5 lines · Rob Herring
Quoted 3 lines · On Wed, Dec 13, 2023 at 10:23AM Lukas Wunner <[email protected]> wrote:
Ideally the validator would match a regex against the $nodename of the parent and see if it contains "spi" or "i2c". But I think matching against the parent's $nodename isn't possible, is it?
Quoted 6 lines
Quoted 1 line
No. I've thought of adding something like that, but haven't.
Please consider this a feature request. :)
It would be good if it were possible to define constraints not just for the $nodename of the parent, but any of its properties.
You could write such a schema, but it would have to be applied to the parent node rather than the child node. It would have to be applied to every 'i2c' node and in theory you could have one for every i2c device. We could define something like "$defs/parent-schema" within the child device schema and make the tools apply it to the parent node.
Quoted 11 lines
E.g. with i2c, the clock-frequency is set at the host controller's devicetree node, not at each attached i2c peripheral's node. For ACPI,
i2c_acpi_find_bus_speed()walks the bus to find the highest clock speed supported by all attached i2c peripherals, but for OF, the onus is on the devicetree author to manually determine the clock.Thus, for a TPM such as infineon,slb9635tt which only supports 100 kHz, I want to validate that the parent node's clock-frequency is less than or equal to that.
Quoted 8 lines
In
Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txtthere's an example showing a clock-frequency property at the peripheral's node and I mistakenly carried that over to the yaml schema. A look at the code reveals that's entirely bogus so I'll drop the clock-frequency property in v3. I will retain textual hints that infineon,slb9635tt is limited to 100 kHz and infineon,slb9645tt to 400 kHz, but as it stands I can't define rules that would allow the validator to check that automatically.
We could adapt the bindings to accept that. Makes sense as that's mostly a property of each device. SPI freq is per child, but I guess I2C has to be the minimum of all the child nodes.
Rob