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: <90ab2113-f3f7-4d1f-83ca-aa57cbe63a79@linaro.org>
Date: Tue, 27 Feb 2024 07:53:11 +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 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)?

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ