On 4/15/20 5:17 PM, Harald Seiler wrote:
Hello Marek,
On Wed, 2020-04-15 at 16:53 +0200, Marek Vasut wrote:
On 4/15/20 4:48 PM, Harald Seiler wrote:
Use DM_ETH instead of legacy networking.
Some more descriptive commit message would help.
[...]
diff --git a/arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi b/arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi new file mode 100644 index 000000000000..88840bb45920 --- /dev/null +++ b/arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi @@ -0,0 +1,22 @@ +// SPDX-License-Identifier: (GPL-2.0+) +/*
- Copyright (C) 2020 Harald Seiler hws@denx.de
- */
+/ {
- fec_vio: regulator-fec {
compatible = "regulator-fixed";regulator-name = "fec-vio";gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;regulator-always-on;- };
+};
The VIO regulator is on the pdk2, so it should be in the PDK2 U-Boot extras.
+&fec {
- phy-reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
- phy-reset-duration = <1>;
- phy-reset-post-delay = <10>;
So is the PHY, so this should also be in the PDK2 extras.
(and it should be fixed in Linux too eventually, if it's not done yet)
I think Linux handles this a bit different: The node for the PHY contains almost the same properties already so I believe that is what's used in the kernel:
ethphy0: ethernet-phy@0 { reg = <0>; max-speed = <100>; reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>; reset-delay-us = <1000>; reset-post-delay-us = <1000>; };
Not sure why U-Boot uses a different set of properties, maybe it makes sense at some point to start using those instead.
Also, this was the reason why I put it into the general dhcom dtsi. I was thinking that, if the existing properties are this general, mine should probably be, too.
I recently had a look into the MDIO subsystem in Linux and the reset GPIO can be either MDIO-bus level OR PHY-level, so that's why there are two sets of properties at different location. Look at:
linux-2.6$ git grep gpio.*reset drivers/net/phy/
I _think_ U-Boot only implements one of those two options, but I might be wrong there.