[RFC] Reset pins of phys and their representation in a device tree
Uwe Kleine-König
u.kleine-koenig at pengutronix.de
Thu May 12 00:15:42 PDT 2016
Hello,
I have a machine here where the reset pin of the phy is connected to a
GPIO.
There are different possibilities available today to handle this
situation, here are the ones I'm aware of:
- Use a gpio-hog to set the reset gpio to non-active
This might result in dependency problems (and that's what I am
currently faced with) because there is no connection in the device
tree between the hog and the phy.
- [Documentation/devicetree/bindings/net/fsl-fec.txt]
The fec node supports properties
phy-reset-gpios = <&gpio2 14 0>;
phy-reset-duration = <200> /* milliseconds */;
Something similar exists in TI's vendor kernel
(http://git.ti.com/ti-linux-kernel/ti-linux-kernel/commit/17d192b999ee904ced223c16cef76111a51c461b)
with different (and IMHO bader) naming.
This is the wrong place to specify the gpios; they shouldn't be in the
mac's node, but in a phy node instead.
So what I actually want is to put the gpio specification in the right
place and let it look as follows:
mymdiobus {
[...]
myfirstphy: ethernet-phy at 0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
reset-gpios = <&gpio2 14 0>;
reset-duration-ms = <200>;
};
mysecondphy: ethernet-phy at 2 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <2>;
reset-gpios = <&gpio3 10 0>;
reset-duration-ms = <200>;
};
};
And with this we could defer probe of &myfirstphy if &gpio2 isn't
available yet.
Does this sound sensible? Does something like that already exist which I
missed? Any further ideas/comments?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
More information about the linux-arm-kernel
mailing list