[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6f05fd6-34a1-4c81-add4-36308fd87352@linaro.org>
Date: Sat, 13 Apr 2024 23:50:34 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Jarkko Sakkinen <jarkko@...nel.org>,
"M. Haener" <michael.haener@...mens.com>, linux-integrity@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Peter Huewe <peterhuewe@....de>,
Jason Gunthorpe <jgg@...pe.ca>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Lukas Wunner <lukas@...ner.de>,
Alexander Sverdlin <alexander.sverdlin@...mens.com>
Subject: Re: [PATCH 2/2] dt-bindings: tpm: Add st,st33ktpm2xi2c to TCG TIS
binding
On 13/04/2024 23:47, Jarkko Sakkinen wrote:
> On Sat Apr 13, 2024 at 10:15 AM EEST, M. Haener wrote:
>> From: Michael Haener <michael.haener@...mens.com>
>>
>> Add the ST chip st33ktpm2xi2c to the supported compatible strings of the
>> TPM TIS I2C schema. The Chip is compliant with the TCG PC Client TPM
>> Profile specification.
>>
>> For reference, a datasheet is available at:
>> https://www.st.com/resource/en/data_brief/st33ktpm2xi2c.pdf
>>
>> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@...mens.com>
>> Signed-off-by: Michael Haener <michael.haener@...mens.com>
>> ---
>> Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml
>> index 3ab4434b7352..af7720dc4a12 100644
>> --- a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml
>> +++ b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml
>> @@ -32,6 +32,7 @@ properties:
>> - enum:
>> - infineon,slb9673
>> - nuvoton,npct75x
>> + - st,st33ktpm2xi2c
>> - const: tcg,tpm-tis-i2c
>>
>> - description: TPM 1.2 and 2.0 chips with vendor-specific I²C interface
>
> Reviewed-by: Jarkko Sakkinen <jarkko@...nel.org>
>
> I'm ready to pick these unless Rob has anything to complain (hold
> to next week).
Plus, even the first patch was not tested... I already wrote it, so
let's be more specific:
NAK, not tested, even though testing is trivial.
I don't understand why opting-out from testing, even for trivial patches
like this. Automation, expressed by get_maintainers.pl, is there for a
reason.
Best regards,
Krzysztof
Powered by blists - more mailing lists