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@xxxxxxxxxxx> >>> >>> 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
