driver-api/phy/phy.rst

8 and how-to-use.
15 such as serialization, de-serialization, encoding, decoding and is responsible
17 controllers have PHY functionality embedded into it and others use an external
18 PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
22 all over the Linux kernel to drivers/phy to increase code re-use and for
25 This framework will be of use only to devices that use external PHY (PHY
32 For the simple case where the PHY provider implements only a single instance of
36 dt boot case.
49 arguments. For the dt boot case, all PHY providers should use one of the above
54 nodes within extra levels for context and extensibility, in which case the low
78 to make use of it. The PHY framework provides 2 APIs to create the PHY.
88 The PHY drivers can use one of the above 2 APIs to create the PHY by passing
94 can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
100 Before the controller can make use of the PHY, it has to get a reference to
119 In the case of dt boot, the string arguments
120 should contain the phy name as given in the dt data and in the case of
121 non-dt boot, it should contain the label of the PHY.  The two
126 functions will never return -ENODEV, but instead return NULL when
128 Some generic drivers, such as ehci, may use multiple phys. In this case,
155 others may use a default mode (typically configured via devicetree or other
197 pm_runtime_get_sync of PHY provider device because of parent-child relationship.
224 Documentation/devicetree/bindings/phy/phy-bindings.txt