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

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

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@broadcom.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