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.
Best regards,
Krzysztof
