[3/6] dt-bindings: net: remove outdated hisilicon-femac
Commit Message
From: Yang Xiwen <forbidden405@outlook.com>
The user documented(Hi3516) is not found in current kernel anymore.
Remove this binding entirely due to recent driver changes.
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
---
.../devicetree/bindings/net/hisilicon-femac.txt | 41 ----------------------
1 file changed, 41 deletions(-)
Comments
On 16/02/2024 00:48, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen <forbidden405@outlook.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.
Best regards,
Krzysztof
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@outlook.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
>
On 16/02/2024 09:03, Yang Xiwen wrote:
> 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@outlook.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.
>
None of these explain why support for these devices should be dropped...
Best regards,
Krzysztof
deleted file mode 100644
@@ -1,41 +0,0 @@
-Hisilicon Fast Ethernet MAC controller
-
-Required properties:
-- compatible: should contain one of the following version strings:
- * "hisilicon,hisi-femac-v1"
- * "hisilicon,hisi-femac-v2"
- and the soc string "hisilicon,hi3516cv300-femac".
-- reg: specifies base physical address(s) and size of the device registers.
- The first region is the MAC core register base and size.
- The second region is the global MAC control register.
-- interrupts: should contain the MAC interrupt.
-- clocks: A phandle to the MAC main clock.
-- resets: should contain the phandle to the MAC reset signal(required) and
- the PHY reset signal(optional).
-- reset-names: should contain the reset signal name "mac"(required)
- and "phy"(optional).
-- phy-mode: see ethernet.txt [1].
-- phy-handle: see ethernet.txt [1].
-- hisilicon,phy-reset-delays-us: triplet of delays if PHY reset signal given.
- The 1st cell is reset pre-delay in micro seconds.
- The 2nd cell is reset pulse in micro seconds.
- The 3rd cell is reset post-delay in micro seconds.
-
-The MAC address will be determined using the optional properties
-defined in ethernet.txt[1].
-
-[1] Documentation/devicetree/bindings/net/ethernet.txt
-
-Example:
- hisi_femac: ethernet@10090000 {
- compatible = "hisilicon,hi3516cv300-femac","hisilicon,hisi-femac-v2";
- reg = <0x10090000 0x1000>,<0x10091300 0x200>;
- interrupts = <12>;
- clocks = <&crg HI3518EV200_ETH_CLK>;
- resets = <&crg 0xec 0>,<&crg 0xec 3>;
- reset-names = "mac","phy";
- mac-address = [00 00 00 00 00 00];
- phy-mode = "mii";
- phy-handle = <&phy0>;
- hisilicon,phy-reset-delays-us = <10000 20000 20000>;
- };