netdev - Re: [PATCH net-next v4 6/6] net: hisi_femac: remove unused compatible strings

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] [day] [month] [year] [list]

Message-ID: <7f722ffc-b0b5-4bd7-a46b-3ce5ae61ad5d@linaro.org>
Date: Tue, 27 Feb 2024 08:48:47 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Yang Xiwen <forbidden405@...look.com>,
 Yisen Zhuang <yisen.zhuang@...wei.com>, Salil Mehta
 <salil.mehta@...wei.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Andrew Lunn <andrew@...n.ch>,
 Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH net-next v4 6/6] net: hisi_femac: remove unused compatible
 strings

On 27/02/2024 08:36, Yang Xiwen wrote:
> On 2/27/2024 2:53 PM, Krzysztof Kozlowski wrote:
>> On 27/02/2024 02:51, Yang Xiwen wrote:
>>> On 2/26/2024 3:55 PM, Krzysztof Kozlowski wrote:
>>>> On 22/02/2024 13:43, Yang Xiwen via B4 Relay wrote:
>>>>> From: Yang Xiwen <forbidden405@...look.com>
>>>>>
>>>>> The only documented SoC Hi3516DV300 does not receive any updates from 8
>>>>> years ago. With the recent driver changes, it unlikely works for this
>>>>> SoC anymore. Remove the binding for this SoC.
>>>>>
>>>>> Also it's hard to get the version number and it's unknown how the
>>>>> version can be used. Remove them until it's really needed.
>>>>>
>>>>> Signed-off-by: Yang Xiwen <forbidden405@...look.com>
>>>>> ---
>>>>>  drivers/net/ethernet/hisilicon/hisi_femac.c | 4 +---
>>>>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/hisilicon/hisi_femac.c b/drivers/net/ethernet/hisilicon/hisi_femac.c
>>>>> index eab91e011d11..9466ca9da2bb 100644
>>>>> --- a/drivers/net/ethernet/hisilicon/hisi_femac.c
>>>>> +++ b/drivers/net/ethernet/hisilicon/hisi_femac.c
>>>>> @@ -990,9 +990,7 @@ static int hisi_femac_drv_resume(struct platform_device *pdev)
>>>>>  #endif
>>>>>  
>>>>>  static const struct of_device_id hisi_femac_match[] = {
>>>>> -	{.compatible = "hisilicon,hisi-femac-v1",},
>>>>> -	{.compatible = "hisilicon,hisi-femac-v2",},
>>>>> -	{.compatible = "hisilicon,hi3516cv300-femac",},
>>>>> +	{.compatible = "hisilicon,hisi-femac",},
>>>>
>>>> What is happening here? Removal could be justified, but then order of
>>>> your patches is totally wrong. But that hisi-femac is a no-go or provide
>>>> proper rationale.
>>>
>>> I don't understand exactly... In dts, we commonly have a SoC specific
>>> compatible string first, generic compatible string the second. e.g.
>>>
>>> compatible = "hisilicon,hi3798mv200-perictrl", "syscon", "simple-mfd".
>>
>> There is no generic compatible here. hi3798mv200 is soc.
>>
>>>
>>> So i think this is recommended. Or does it mean we only need them in
>>
>> It is allowed for certain cases and recommended for even fewer ones. Do
>> you want to say you have fully discoverable features here and you do not
>> need any properties? Or you want to say that all possible hardware will
>> have exactly the same programming interface (registers etc)?
> 
> Of course not. Take FEMAC for example. The FEMAC core on Hi3516 and

If they have different programming interface then you cannot use generic
compatible as fallback.

> Hi3798 can programmed in the same way. They use the same
> resources(resets and clocks). Though still a bit different in hardware,
> basically the fifo depth etc..
> 
> Hi3516 FEMAC is not special enough to have a new compatible string, nor
> do hi3798 FEMAC. Nor do i think we need those undocumented version
> numbers, i.e. "hisilicon,hisi-femac-v1/2". As i observed, this driver is
> generic enough to handle all the FEMAC cores i know, no matter which
> version nor which SoC. This can also be concluded from the driver, the
> driver defined 3 compatibles but they are all treated the same.
> 
> Should I remove all of them, and only leave a generic
> "hisilicon,hisi-femac" instead?

No.

Use one SoC specific compatible as fallback. That's what we ask almost
every time...

Best regards,
Krzysztof