Lines Matching refs:to

5 and how-to-use.
9 *PHY* is the abbreviation for physical layer. It is used to connect a device
10 to the physical medium e.g., the USB controller has a PHY to provide functions
17 The intention of creating this framework is to bring the PHY drivers spread
18 all over the Linux kernel to drivers/phy to increase code re-use and for
21 This framework will be of use only to devices that use external PHY (PHY
26 PHY provider refers to an entity that implements one or more PHY instances.
39 of_phy_provider_register and devm_of_phy_provider_register macros can be used to
42 2 macros to register the PHY provider.
48 devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
54 to make use of it. The PHY framework provides 2 APIs to create the PHY.
61 The PHY drivers can use one of the above 2 APIs to create the PHY by passing
66 Inorder to dereference the private data (in phy_ops), the phy provider driver
68 phy_ops to get back the private data.
70 4. Getting a reference to the PHY
72 Before the controller can make use of the PHY, it has to get a reference to
73 it. This framework provides the following APIs to get a reference to the PHY.
81 be used to get the PHY. In the case of dt boot, the string arguments
94 phy_power_off() calls are all NOP when applied to a NULL phy. The NULL
97 5. Releasing a reference to the PHY
99 When the controller no longer needs the PHY, it has to release the reference
100 to the PHY it has obtained using the APIs mentioned in the above section. The
101 PHY framework provides 2 APIs to release a reference to the PHY.
106 Both these APIs are used to release a reference to the PHY and devm_phy_put
138 In order to get reference to a PHY without help from DeviceTree, the framework
139 offers lookups which can be compared to clkdev that allow clk structures to be
140 bound to devices. A lookup can be made be made during runtime when a handle to