linux-kernel - Re: [PATCH v1 1/6] dt-bindings: cache: Document the sifive,perfmon-counters property

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 for Android: free password hash cracker in your pocket

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

Message-ID: <6ac4005b-01e6-48c2-971e-d6a127134d13@linaro.org>
Date: Sun, 18 Feb 2024 19:35:35 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Samuel Holland <samuel.holland@...ive.com>, Will Deacon
 <will@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Eric Lin <eric.lin@...ive.com>, Conor Dooley <conor@...nel.org>
Cc: Palmer Dabbelt <palmer@...belt.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Paul Walmsley <paul.walmsley@...ive.com>,
 linux-riscv@...ts.infradead.org, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v1 1/6] dt-bindings: cache: Document the
 sifive,perfmon-counters property

On 18/02/2024 16:29, Samuel Holland wrote:
> Hi Krzysztof,
> 
> On 2024-02-17 3:00 AM, Krzysztof Kozlowski wrote:
>> On 16/02/2024 01:08, Samuel Holland wrote:
>>> The SiFive Composable Cache controller contains an optional PMU with a
>>> configurable number of event counters. Document a property which
>>
>> Configurable in what context? By chip designers or by OS? Why this
>> cannot be deduced from the compatible?
> 
> This parameter is configurable by the chip designers.
> 
> The information certainly can be deduced from the SoC-specific compatible
> string, but doing so makes the driver only work on that specific list of SoCs.

Usually that's exactly what's expected, so why here usual approach is wrong?

> When provided via a property, the driver can work without changes on any SoC
> that uses this IP block. (None of the SoCs currently listed in the binding

Sorry, properties are not a work-around for missing compatibles.

> contain a PMU, so there is no backward compatibility concern with adding the new
> property.)
> 
> My understanding of the purpose of the SoC-specific compatible string is to
> handle eventualities (silicon bugs, integration quirks, etc.), not to
> intentionally limit the driver to a narrow list of hardware.

Depends what is the hardware. For most of licensed blocks, the final
design is the hardware so equals to its compatible.

Best regards,
Krzysztof