linux-kernel - Re: [PATCH 2/2] dt-bindings: tpm: Add st,st33ktpm2xi2c to TCG TIS binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 13 Apr 2024 13:01:36 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Lukas Wunner <lukas@...ner.de>
Cc: "M. Haener" <michael.haener@...mens.com>,
 linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
 Peter Huewe <peterhuewe@....de>, Jarkko Sakkinen <jarkko@...nel.org>,
 Jason Gunthorpe <jgg@...pe.ca>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 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 12:56, Lukas Wunner wrote:
> On Sat, Apr 13, 2024 at 12:53:25PM +0200, Krzysztof Kozlowski wrote:
>> On 13/04/2024 12:51, Lukas Wunner wrote:
>>> The binding requires two entries in the compatible string used in the DT,
>>> the chip name followed by the generic string:
>>>
>>>         items:
>>>           - enum:
>>>               - infineon,slb9673
>>>               - nuvoton,npct75x
>>>           - const: tcg,tpm-tis-i2c
>>>
>>> This allows us to deal with device-specific quirks, should they pop up
>>> (e.g. special timing requirements, hardware bugs).  We don't know in
>>> advance if they will be discovered, but if they are, it's cumbersome
>>> to determine after the fact which products (and thus DTs) are affected.
>>> So having the name of the actual chip used on the board has value.
>>
>> So you say devices are compatible. Then the second patch is wrong.
>>
>> I cannot respond to it, though... so NAK-here-for-second-patch.
> 
> I disagree.  It's ugly to have inconsistencies between the DT bindings
> and the driver.  So I think patch [1/2] in this series is fine.

You are mixing different things. This patchset creates inconsistency.
You even refer here to bindings while we discuss the driver...

Why this one driver is different than all other Linux drivers? Why do
you keep pushing here entirely different behavior?

The devices are compatible, so growing match table is both redundant and
confusing. That's everywhere. TPM is not different.

Best regards,
Krzysztof