linux-kernel - Re: [PATCH 0/4] memory: brcmstb

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]

Date:   Wed, 6 Dec 2023 12:14:14 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Markus Mayer <mmayer@...adcom.com>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Rob Herring <robh+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc:     Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
        Device Tree Mailing List <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4

On 05/12/2023 19:47, Markus Mayer wrote:
> It has become necessary to distinguish between the various DPFE API
> versions by version number. Having just chip-specific compatible strings
> and one generic version is no longer meeting our needs.
> 
> Also, a new DPFE API version, v4, needs to be supported by the driver.
> 
> As a result, an intermediate compatible string format is being

Introducing new SoC does not justify this. It's not correlated, not
related. Stop using some fake arguments to introduce something which we
do not want: versions.

> introduced: brcm,dpfe-cpu-v<N> where <N> represents the API version
> number. This is more specific than the catch-all "brcm,dpfe-cpu" and
> more generic than chip-specific compatible strings, such as
> "brcm,bcm7271-dpfe-cpu".

NAK

Best regards,
Krzysztof