Lines Matching refs:and

5 and how-to-use.
11 such as serialization, de-serialization, encoding, decoding and is responsible
13 controllers have PHY functionality embedded into it and others use an external
18 all over the Linux kernel to drivers/phy to increase code re-use and for
39 of_phy_provider_register and devm_of_phy_provider_register macros can be used to
40 register the phy_provider and it takes device and of_xlate as
48 devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
62 the device pointer and phy ops.
64 init, exit, power_on and power_off.
67 can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
82 phy_get, phy_optional_get, devm_phy_get and devm_phy_optional_get can
84 should contain the phy name as given in the dt data and in the case of
88 the the devres data and devres data is freed. phy_optional_get and
92 phys and for such drivers referencing phy(s) by name(s) does not make sense. In
98 the phy_init() and phy_exit() calls, and phy_power_on() and
111 Both these APIs are used to release a reference to the PHY and devm_phy_put
122 Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
128 pm_runtime_enable of the phy device created by this subsystem is called and
135 It should also be noted that phy_power_on and phy_power_off performs
136 phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
138 phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
148 The framework offers the following API for registering and unregistering the