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.
81 be used to get the PHY. In the case of dt boot, the string arguments
82 should contain the phy name as given in the dt data and in the case of
83 non-dt boot, it should contain the label of the PHY. The two
84 devm_phy_get associates the device with the PHY using devres on
86 the the devres data and devres data is freed. phy_optional_get and
87 devm_phy_optional_get should be used when the phy is optional. These
89 the phy cannot be found.
92 consumer calls on the NULL phy become NOPs. That is the release calls,
93 the phy_init() and phy_exit() calls, and phy_power_on() and
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
107 destroys the devres associated with this PHY.
109 6. Destroying the PHY
111 When the driver that created the PHY is unloaded, it should destroy the PHY it
112 created using one of the following 2 APIs.
117 Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
122 This subsystem is pm runtime enabled. So while creating the PHY,
123 pm_runtime_enable of the phy device created by this subsystem is called and
124 while destroying the PHY, pm_runtime_disable is called. Note that the phy
125 device created by this subsystem will be a child of the device that calls
128 So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
138 In order to get reference to a PHY without help from DeviceTree, the framework
141 the struct phy already exists.
143 The framework offers the following API for registering and unregistering the