linux-kernel - [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20231205184741.3092376-1-mmayer@broadcom.com>
Date:   Tue,  5 Dec 2023 10:47:33 -0800
From:   Markus Mayer <mmayer@...adcom.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Rob Herring <robh+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc:     Markus Mayer <mmayer@...adcom.com>,
        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: [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4

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
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".

The changes are split into several steps.

First, we update the binding and introduce the versioned compatible
strings.

Secondly, we add support for brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
in the driver to match existing API versions.

Thirdly, we introduce DPFE API v4.

Lastly, there is a change that isn't directly related to the
introduction of the new binding format or DPFE API v4. However, with the
increasing number of API versions, broadening compatibility can be
helpful. If registering the driver using the DT-provided compatible
string fails, the driver will try all DPFE APIs (except for v1) to see
if one might end up working. This can come in handy if the driver moves
on and learns about new API versions while Device Tree cannot be
updated.

Markus Mayer (4):
  dt-bindings: memory: additional compatible strings for Broadcom DPFE
  memory: brcmstb_dpfe: introduce version-specific compatible strings
  memory: brcmstb_dpfe: support DPFE API v4
  memory: brcmstb_dpfe: introduce best-effort API detection

 .../memory-controllers/brcm,dpfe-cpu.yaml     |  8 +-
 drivers/memory/brcmstb_dpfe.c                 | 95 ++++++++++++++++++-
 2 files changed, 100 insertions(+), 3 deletions(-)

-- 
2.43.0