From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Markus Mayer <mmayer@broadcom.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Rob Herring <robh+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
Device Tree Mailing List <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4
Date: Wed, 6 Dec 2023 12:14:14 +0100 [thread overview]
Message-ID: <28531f53-3213-4d12-b4c8-d91cfd0461d5@linaro.org> (raw)
In-Reply-To: <20231205184741.3092376-1-mmayer@broadcom.com>
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
prev parent reply other threads:[~2023-12-06 11:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 18:47 [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4 Markus Mayer
2023-12-05 18:47 ` [PATCH 1/4] dt-bindings: memory: additional compatible strings for Broadcom DPFE Markus Mayer
2023-12-06 11:09 ` Krzysztof Kozlowski
2023-12-06 16:32 ` Florian Fainelli
2023-12-06 17:29 ` Krzysztof Kozlowski
2023-12-06 17:36 ` Florian Fainelli
2023-12-06 17:42 ` Krzysztof Kozlowski
2023-12-05 18:47 ` [PATCH 2/4] memory: brcmstb_dpfe: introduce version-specific compatible strings Markus Mayer
2023-12-05 19:05 ` Florian Fainelli
2023-12-06 11:09 ` Krzysztof Kozlowski
2023-12-06 16:19 ` Florian Fainelli
2023-12-06 17:33 ` Krzysztof Kozlowski
2023-12-05 18:47 ` [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4 Markus Mayer
2023-12-05 19:05 ` Florian Fainelli
2023-12-06 11:10 ` Krzysztof Kozlowski
2023-12-06 16:18 ` Florian Fainelli
2023-12-06 17:31 ` Krzysztof Kozlowski
2023-12-06 18:48 ` Markus Mayer
2023-12-05 18:47 ` [PATCH 4/4] memory: brcmstb_dpfe: introduce best-effort API detection Markus Mayer
2023-12-05 19:06 ` Florian Fainelli
2023-12-06 11:13 ` Krzysztof Kozlowski
2023-12-06 16:24 ` Florian Fainelli
2023-12-06 11:14 ` Krzysztof Kozlowski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28531f53-3213-4d12-b4c8-d91cfd0461d5@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmayer@broadcom.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).