From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Yang Xiwen <forbidden405@outlook.com>,
Yisen Zhuang <yisen.zhuang@huawei.com>,
Salil Mehta <salil.mehta@huawei.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v4 6/6] net: hisi_femac: remove unused compatible strings
Date: Tue, 27 Feb 2024 08:48:47 +0100 [thread overview]
Message-ID: <7f722ffc-b0b5-4bd7-a46b-3ce5ae61ad5d@linaro.org> (raw)
In-Reply-To: <SEZPR06MB6959E3E0C16ABFA9171FC4DE96592@SEZPR06MB6959.apcprd06.prod.outlook.com>
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@outlook.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@outlook.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
prev parent reply other threads:[~2024-02-27 7:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 12:43 [PATCH net-next v4 0/6] net: hisi-femac: add support for Hi3798MV200, remove unmaintained compatibles Yang Xiwen via B4 Relay
2024-02-22 12:43 ` [PATCH net-next v4 1/6] dt-bindings: net: hisilicon-femac-mdio: convert to YAML Yang Xiwen via B4 Relay
2024-02-22 18:14 ` Krzysztof Kozlowski
2024-02-22 18:19 ` Yang Xiwen
2024-02-24 10:01 ` Krzysztof Kozlowski
2024-02-24 12:01 ` Yang Xiwen
2024-02-22 12:43 ` [PATCH net-next v4 2/6] net: mdio: hisi-femac: make clock optional Yang Xiwen via B4 Relay
2024-02-22 12:43 ` [PATCH net-next v4 3/6] dt-bindings: net: remove outdated hisilicon-femac Yang Xiwen via B4 Relay
2024-02-26 7:50 ` Krzysztof Kozlowski
2024-02-27 1:43 ` Yang Xiwen
2024-02-27 6:51 ` Krzysztof Kozlowski
2024-02-22 12:43 ` [PATCH net-next v4 4/6] dt-bindings: net: add hisilicon,hisi-femac Yang Xiwen via B4 Relay
2024-02-26 7:53 ` Krzysztof Kozlowski
2024-02-22 12:43 ` [PATCH net-next v4 5/6] net: hisilicon: add support for hisi_femac core on Hi3798MV200 Yang Xiwen via B4 Relay
2024-02-26 7:54 ` Krzysztof Kozlowski
2024-02-22 12:43 ` [PATCH net-next v4 6/6] net: hisi_femac: remove unused compatible strings Yang Xiwen via B4 Relay
2024-02-26 7:55 ` Krzysztof Kozlowski
2024-02-27 1:51 ` Yang Xiwen
2024-02-27 6:53 ` Krzysztof Kozlowski
2024-02-27 7:36 ` Yang Xiwen
2024-02-27 7:48 ` Krzysztof Kozlowski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7f722ffc-b0b5-4bd7-a46b-3ce5ae61ad5d@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=forbidden405@outlook.com \
--cc=hkallweit1@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=salil.mehta@huawei.com \
--cc=yisen.zhuang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).