linux-kernel - Re: [PATCH v3 1/4] dt-bindings: arm: qcom-soc: simplify SoC-matching patterns

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: <80a37af3-ffef-4342-b7d3-f2eb36bb60ba@kernel.org>
Date: Fri, 1 Nov 2024 09:37:23 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Krishna Kurapati <quic_kriskura@...cinc.com>,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/4] dt-bindings: arm: qcom-soc: simplify SoC-matching
 patterns

On 01/11/2024 08:47, Dmitry Baryshkov wrote:
> On Fri, Nov 01, 2024 at 08:26:04AM +0100, Krzysztof Kozlowski wrote:
>> On Fri, Nov 01, 2024 at 02:49:22AM +0200, Dmitry Baryshkov wrote:
>>> The patterns for individual SoC families grew up to be pretty complex,
>>> containing lots of special cases and optional suffixes. Split them per
>>> the suffix to make it easier to extend SoC patterns.
>>
>> This is doing something quite different - split is not important here.
>> Instead you narrow the patterns significantly and disallow things like
>> msm8994pro, sc8280p or sc8280px, and allow things like sa5200p.
> 
> Just for the sake of correctness, msm8994pro is still allowed, if I'm
> not mistaken.
> 
>> I don't see here much of pattern simplifying - dropping (pro)? really
>> makes little difference.
> 
> Patterns are simplified by being explicit. E.g. in the previous
> iteration I completely didn't notice the intersection of the |p that I
> have added with the existing [a-z][a-z]? pattern. If you think that
> sa5200p should be disallowed, I can tune the numeric part of the
> pattern. And sc8280p / sc8280px should not be allowed in the first
> place, such platforms don't exist.

I am fine with this, but extend the commit msg with some good rationale.
Have in mind that the point of this pattern was *not* to validate SoCs
names. sa5200p is fine, sc8180p is fine and all others are fine, sc8280z
as well, because we do not want to grow this pattern with every new model.

The only, single point of this entire binding is to disallow incorrect
order of block names in compatible. Not validate the SoC names. If you
need narrower patterns to achieve that objective, sure. If you need
narrower patterns to validate SoC names, then nope.

Best regards,
Krzysztof