Lines Matching refs:the

4 This document explains the Generic PHY Framework along with the APIs provided,
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
12 for obtaining the required data transmission rate. Note that some USB
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
22 functionality is not embedded within the controller).
24 2. Registering/Unregistering the PHY provider
27 For the simple case where the PHY provider implements only a single instance of
28 the PHY, the framework provides its own implementation of of_xlate in
29 of_phy_simple_xlate. If the PHY provider implements multiple instances, it
40 register the phy_provider and it takes device and of_xlate as
41 arguments. For the dt boot case, all PHY providers should use one of the above
42 2 macros to register the PHY provider.
49 unregister the PHY.
51 3. Creating the PHY
53 The PHY driver should create the PHY in order for other peripheral controllers
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
62 the device pointer and phy ops.
66 Inorder to dereference the private data (in phy_ops), the phy provider driver
67 can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
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.
83 be used to get the PHY. In the case of dt boot, the string arguments
84 should contain the phy name as given in the dt data and in the case of
85 non-dt boot, it should contain the label of the PHY.  The two
86 devm_phy_get associates the device with the PHY using devres on
88 the the devres data and devres data is freed. phy_optional_get and
89 devm_phy_optional_get should be used when the phy is optional. These
91 the phy cannot be found.Some generic drivers, such as ehci, may use multiple
94 the index.
97 consumer calls on the NULL phy become NOPs. That is the release calls,
98 the phy_init() and phy_exit() calls, and phy_power_on() and
102 5. Releasing a reference to the PHY
104 When the controller no longer needs the PHY, it has to release the reference
105 to the PHY it has obtained using the APIs mentioned in the above section. The
106 PHY framework provides 2 APIs to release a reference to the PHY.
111 Both these APIs are used to release a reference to the PHY and devm_phy_put
112 destroys the devres associated with this PHY.
114 6. Destroying the PHY
116 When the driver that created the PHY is unloaded, it should destroy the PHY it
117 created using one of the following 2 APIs.
122 Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
127 This subsystem is pm runtime enabled. So while creating the PHY,
128 pm_runtime_enable of the phy device created by this subsystem is called and
129 while destroying the PHY, pm_runtime_disable is called. Note that the phy
130 device created by this subsystem will be a child of the device that calls
133 So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
143 In order to get reference to a PHY without help from DeviceTree, the framework
146 the struct phy already exists.
148 The framework offers the following API for registering and unregistering the