linux-kernel - Re: [PATCH 3/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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c483e962-a565-45b0-91e2-41f47e2cf4bb@linaro.org>
Date:   Wed, 6 Dec 2023 18:31:56 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Florian Fainelli <florian.fainelli@...adcom.com>,
        Markus Mayer <mmayer@...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 3/4] memory: brcmstb_dpfe: support DPFE API v4

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@...adcom.com>
>>> ---
>>
>> ...
>>
>>> +
>>>   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.

Best regards,
Krzysztof