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: Fri, 22 Mar 2024 08:01:53 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Sean Anderson <sean.anderson@...ux.dev>, Conor Dooley <conor@...nel.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Richard Alpe <richard@...42.se>, linux-kernel@...r.kernel.org,
 Niklas Söderlund <niklas.soderlund@...natech.se>,
 Michael Walle <michael@...le.cc>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: nvmem: Remove fsl,t1023-sfp in favor of
 fsl,layerscape-sfp

On 21/03/2024 17:21, Sean Anderson wrote:
> On 3/19/24 13:55, Conor Dooley wrote:
>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote:
>>> On 3/18/24 11:40, Conor Dooley wrote:
>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
>>>>> On 3/17/24 11:10, Conor Dooley wrote:
>>>>
>>>>>> Additionally, should
>>>>>> they fall back to t1023-sfp? I see that there's already some dts files
>>>>>> with these compatibles in them but seemingly no driver support as there
>>>>>> is for the t1023-sfp.
>>>>>
>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0.
>>>>
>>>> Sounds like a fallback is suitable then, although that will require
>>>> updating the various dts files.
>>>
>>> Yes, a fallback (like what is done for the T-series) would be suitable,
>>> but given that these devicetrees have been in-tree for eight years I
>>> think it would be preferable to support the existing bindings for
>>> compatibility purposes.
>>
>> Just cos stuff snuck into the tree in dts files doesn't make it right
>> though, I'd rather the bindings were done correctly. I don't care if you
>> want to support all of the compatibles in the driver so that it works
>> with the existing devicetrees though, as long as you mention the
>> rationale in the commit message.
> 
> It doesn't really matter what the schema has as long as the driver supports
> existing device trees.

We do not talk about driver now but bindings. You add new compatibles on
a basis that they were already used. This cannot bypass regular review
comments, so if during regular review process we would require
fallbacks, then you are expected to listen to review also when
documenting existing compatibles. Otherwise everyone would prefer to
snuck in incorrect code and later document it "it was there!".

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ