[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SEZPR06MB69597BA5B7F02E0B9995131A964C2@SEZPR06MB6959.apcprd06.prod.outlook.com>
Date: Fri, 16 Feb 2024 16:03:02 +0800
From: Yang Xiwen <forbidden405@...look.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
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>, Yang Xiwen <forbidden405@...mail.com>,
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 3/6] dt-bindings: net: remove outdated hisilicon-femac
On 2/16/2024 3:21 PM, Krzysztof Kozlowski wrote:
> On 16/02/2024 00:48, Yang Xiwen via B4 Relay wrote:
>> From: Yang Xiwen <forbidden405@...look.com>
>>
>> The user documented(Hi3516) is not found in current kernel anymore.
>> Remove this binding entirely due to recent driver changes.
> Hardware does not change because you decided to re-implement driver.
The only hardware i have is the hi3798mv200. According to downstream
driver name, this is supposed to be a hisi-femac-v3 actually. I don't
know much about Hi3516, but it confuses me a lot. According to the
device tree node example in the text binding file, the MDIO bus is
supposed to be inside the femac core (femac core is at 0x0-0x1000 &
0x1100-0x1300 and mdio bus is at 0x1100-0x1120). So i think it's highly
possible they are the same hardware. But according to the TRM and my
tests, there are 3 clocks in total for femac core in hi3798mv200, one
for mac ctrl, one for ahb bus(I'm sure this "bus" clock is not MDIO bus
clock), and one for phy, which is very similar to the hisi-gmac driver.
Which complicates things a lot is the complex clock enabling timing
requirements here. at least for hi3798mv200(and all SoCs with
hisi-femac-v3 core i think according to the downstream kernel source),
It must strictly follow the sequence in hisi_femac_phy_reset() (disable
MAC clk and BUS clk first before asserting PHY reset), or the PHY would
fail to work. So as said in previous reply, the simplest way is to do
all resets and clocks management in the MAC driver, or else it'll be
very hard to implement. I can't find an easy way to "tell" a driver to
kindly disable its clocks remotely.
>
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
Powered by blists - more mailing lists