aboutsummaryrefslogtreecommitdiff
path: root/Documentation/driver-api
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2022-12-19 08:40:58 -0600
committerLinus Torvalds <torvalds@linux-foundation.org>2022-12-19 08:40:58 -0600
commite79041113b19b8c7b8410d862d4a3630debded58 (patch)
tree581b5ce8a812de69078b8c825eba2cc91358d7ec /Documentation/driver-api
parentb8fd76f41820951d8a6e2521c25f54afadf338bd (diff)
parentbea3ce759b4664f20f1f57c53fe018c3b67da147 (diff)
Merge tag 'phy-for-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy
Pull phy updates from Vinod Koul: "This tme we have again a big pile of qcom-qmp-* changes, one new driver and bunch of new hardware support. New hardware support: - Allwinner H616 USB PHY and A100 DPHY support - TI J721s2, J784s4 and J721e support - Freescale i.MX8MP PCIe PHY support - New driver for Renesas Ethernet SERDES supporting R-Car S4-8 - Qualcomm SM8450 PCIe1 PHY support in EP mode - Qualcomm SC8280XP PCIe PHY support (including x4 mode) - Fixed Qualcomm SC8280XP USB4-USB3-DP PHY DT bindings Updates: - A big pile of updates on qcom-qmp-* drivers following the driver split and reorganization merged earlier - Phy order of API calls documentation update" * tag 'phy-for-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (174 commits) phy: ti: phy-j721e-wiz: add j721s2-wiz-10g module support dt-bindings: phy-j721e-wiz: add j721s2 compatible string phy: use devm_platform_get_and_ioremap_resource() phy: allwinner: phy-sun6i-mipi-dphy: Add the A100 DPHY variant phy: allwinner: phy-sun6i-mipi-dphy: Add a variant power-on hook phy: allwinner: phy-sun6i-mipi-dphy: Set the enable bit last phy: allwinner: phy-sun6i-mipi-dphy: Make RX support optional dt-bindings: sun6i-a31-mipi-dphy: Add the A100 DPHY variant dt-bindings: sun6i-a31-mipi-dphy: Add the interrupts property phy: qcom-qmp-pcie: drop redundant clock allocation phy: qcom-qmp-usb: drop redundant clock allocation phy: qcom-qmp: drop unused type header phy: qcom-qmp-usb: drop sc8280xp reference-clock source dt-bindings: phy: qcom,sc8280xp-qmp-usb3-uni: drop reference-clock source phy: qcom-qmp-combo: add support for updated sc8280xp binding phy: qcom-qmp-combo: rename DP_PHY register pointer phy: qcom-qmp-combo: rename common-register pointers phy: qcom-qmp-combo: clean up DP clock callbacks phy: qcom-qmp-combo: separate clock and provider registration phy: qcom-qmp-combo: add clock registration helper ...
Diffstat (limited to 'Documentation/driver-api')
-rw-r--r--Documentation/driver-api/phy/phy.rst25
1 files changed, 24 insertions, 1 deletions
diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst
index 8fc1ce0bb905..8e8b3e8f9523 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -94,7 +94,8 @@ Inorder to dereference the private data (in phy_ops), the phy provider driver
can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
phy_ops to get back the private data.
-4. Getting a reference to the PHY
+Getting a reference to the PHY
+==============================
Before the controller can make use of the PHY, it has to get a reference to
it. This framework provides the following APIs to get a reference to the PHY.
@@ -130,6 +131,28 @@ the phy_init() and phy_exit() calls, and phy_power_on() and
phy_power_off() calls are all NOP when applied to a NULL phy. The NULL
phy is useful in devices for handling optional phy devices.
+Order of API calls
+==================
+
+The general order of calls should be::
+
+ [devm_][of_]phy_get()
+ phy_init()
+ phy_power_on()
+ [phy_set_mode[_ext]()]
+ ...
+ phy_power_off()
+ phy_exit()
+ [[of_]phy_put()]
+
+Some PHY drivers may not implement :c:func:`phy_init` or :c:func:`phy_power_on`,
+but controllers should always call these functions to be compatible with other
+PHYs. Some PHYs may require :c:func:`phy_set_mode <phy_set_mode_ext>`, while
+others may use a default mode (typically configured via devicetree or other
+firmware). For compatibility, you should always call this function if you know
+what mode you will be using. Generally, this function should be called after
+:c:func:`phy_power_on`, although some PHY drivers may allow it at any time.
+
Releasing a reference to the PHY
================================