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]
Message-ID: <548b7a66-9a56-4971-89eb-1a147d658f0f@linaro.org>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ