Re: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4

[Markus Mayer]

On Thu, 28 May 2026 at 14:45, Markus Mayer <mmayer@xxxxxxxxxxxx> wrote:
>
> On Wed, 6 Dec 2023 at 10:48, Markus Mayer <mmayer@xxxxxxxxxxxx> wrote:
> >
> > On Wed, 6 Dec 2023 at 09:32, Krzysztof Kozlowski
> > <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > >
> > > On 06/12/2023 17:18, Florian Fainelli wrote:
> > > >
> > > >
> > > > On 12/6/2023 3:10 AM, Krzysztof Kozlowski wrote:
> > > >> On 05/12/2023 19:47, Markus Mayer wrote:
> > > >>> Add support for version 4 of the DPFE API. This new version is largely
> > > >>> identical to version 3. The main difference is that all commands now
> > > >>> take the MHS version number as the first argument. Any other arguments
> > > >>> have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
> > > >>> v4).
> > > >>>
> > > >>> Signed-off-by: Markus Mayer <mmayer@xxxxxxxxxxxx>
> > > >>
> > > >> ...
> > > >>
> > > >>> +
> > > >>>   static const char *get_error_text(unsigned int i)
> > > >>>   {
> > > >>>     static const char * const error_text[] = {
> > > >>> @@ -929,8 +954,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
> > > >>>     { .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
> > > >>>     { .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
> > > >>>     { .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
> > > >>> +   { .compatible = "brcm,dpfe-cpu-v4", .data = &dpfe_api_v4 },
> > > >>>
> > > >>
> > > >> No, use SoC specific compatible.
> > > >
> > > > This is not that simple because for a given SoC, the API implemented by
> > > > the firmware can change, in fact it has changed over the lifetime of a
> > > > given SoC as firmware updates get rolled out. Arguably the dialect
> > > > spoken by the firmware should not have changed and we told the firmware
> > > > team about that but it basically went nowhere and here we are.
> > > >
> > > > The Device Tree gets populated by the boot loader which figures out
> > > > which API is spoken and places one of those compatible strings
> > > > accordingly for the kernel to avoid having to do any sort of run-time
> > > > detection which is slow and completely unnecessary when we can simply
> > > > tell it ahead of time what to use.
> > >
> > > Thanks for providing justification, quite reasonable. A pity that none
> > > of the commit msgs answered this way.
> >
> > The real pity is how this API was designed, making all of this
> > necessary in the first place.
> >
> > We can definitely spell out more clearly in the commit messages what
> > is going on and why all of this is needed. I'll pull all the pieces
> > together from the various responses. As long as there's a way we can
> > reasonably implement what we need, we'll be happy.

Updated the e-mail address for Krzysztof. Here's the original mail
from a few minutes ago.

> It has been a minute, but we'd like to resume this effort[1] to
> upstream these changes or some variation thereof.
>
> What are the best steps to resume this undertaking? There are still a
> few topics where I am not entirely clear on how to better explain
> things or how to address the feedback provided. My apologies for that.
> I will do my best to address whatever concerns there are.
>
> Should I put together a new pull request that contains improved commit
> messages and addresses some of the feedback and we hash out whatever
> questions remain on the new thread? Or would it be better for me to
> reply to the old thread with some of the questions that remain before
> sending a revised series?
>
> Thanks,
> -Markus
>
> [1] https://lore.kernel.org/all/20231205184741.3092376-1-mmayer@xxxxxxxxxxxx/