On 08/03/2024 09:18, Yang Xiwen wrote:
> On 3/8/2024 4:09 PM, Krzysztof Kozlowski wrote:
>> On 08/03/2024 09:07, Yang Xiwen wrote:
>>> On 3/8/2024 4:02 PM, Krzysztof Kozlowski wrote:
>>>> On 07/03/2024 12:34, Yang Xiwen via B4 Relay wrote:
>>>>> From: Yang Xiwen <forbidden405@xxxxxxxxxxx>
>>>>>
>>>>> Register the sub MDIO bus if it is found. Also implement the internal
>>>>> PHY reset procedure as needed.
>>>> ...
>>>>
>>>>>
>>>>> @@ -946,6 +991,7 @@ static int hisi_femac_drv_resume(struct platform_device *pdev)
>>>>>
>>>>> static const struct of_device_id hisi_femac_match[] = {
>>>>> {.compatible = "hisilicon,hi3516cv300-femac",},
>>>>> + {.compatible = "hisilicon,hi3798mv200-femac",},
>>>> Why do you keep growing this table?
>>>
>>> I'm completely confused. Don't I need to keep binding and driver
>>> compatible ids sync?
>>>
>>>
>>> The FEMAC cores on 2 SoCs are compatible afaik. That's why i want to add
>>> a generic "hisilicon,hisi-femac" compatible. Though i know nothing about
>>> the mysterious version numbers (v1, v2 etc..) documented in the old
>>> binding, so i want them to be removed. Instead only keep one generic
>>> fallback compatible.
>>>
>>>
>>> Do you mean that i broke the backward compatibility for
>>> "hisilicon,hi3516cv300-femac"?
>> No. I meant, use one as fallback and only fallback needs to be in the
>> device ID table. There are dozens if not hundreds of such examples in
>> the tree.
>
>
> I don't think an arbitrary SoC compatible is a good name for a fallback
> compatible. Why can't we have "hisilicon,hisi-femac" instead of the odd
Why? Anyway, why rules for Hisilicon should be different than for
everyone else?
> "hisilicon,hi3516cv300-femac", If we are not going to keep backward
> compatibility? Hi3516CV300 is just an old and outdated ordinary SoC
> after all, but the FEMAC core is still being used in latest SoCs afaik.
> I can't see the reason to relate this core to some old SoC and keep the
> compatible forever.
Why rules for Hisilicon should be different than for everyone else?
Best regards,
Krzysztof
