Revert "drivers: phy: add generic PHY framework"

This reverts commit 528bac1d1f2a8bb10ebc3e56dd8f22e2d76f197f.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

2 files changed, 0 insertions, 195 deletions

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
deleted file mode 100644
index 8ae844fc0c6..00000000000
--- a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-This document explains only the device tree data binding. For general
-information about PHY subsystem refer to Documentation/phy.txt
-
-PHY device node
-===============
-
-Required Properties:
-#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
-		cells is defined by the binding for the phy node. The PHY
-		provider can use the values in cells to find the appropriate
-		PHY.
-
-For example:
-
-phys: phy {
-    compatible = "xxx";
-    reg = <...>;
-    .
-    .
-    #phy-cells = <1>;
-    .
-    .
-};
-
-That node describes an IP block (PHY provider) that implements 2 different PHYs.
-In order to differentiate between these 2 PHYs, an additonal specifier should be
-given while trying to get a reference to it.
-
-PHY user node
-=============
-
-Required Properties:
-phys : the phandle for the PHY device (used by the PHY subsystem)
-phy-names : the names of the PHY corresponding to the PHYs present in the
-	    *phys* phandle
-
-Example 1:
-usb1: usb_otg_ss@xxx {
-    compatible = "xxx";
-    reg = <xxx>;
-    .
-    .
-    phys = <&usb2_phy>, <&usb3_phy>;
-    phy-names = "usb2phy", "usb3phy";
-    .
-    .
-};
-
-This node represents a controller that uses two PHYs, one for usb2 and one for
-usb3.
-
-Example 2:
-usb2: usb_otg_ss@xxx {
-    compatible = "xxx";
-    reg = <xxx>;
-    .
-    .
-    phys = <&phys 1>;
-    phy-names = "usbphy";
-    .
-    .
-};
-
-This node represents a controller that uses one of the PHYs of the PHY provider
-device defined previously. Note that the phy handle has an additional specifier
-"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
deleted file mode 100644
index 05f8fdaa721..00000000000
--- a/Documentation/phy.txt
+++ /dev/null
@@ -1,129 +0,0 @@
-			    PHY SUBSYSTEM
-		  Kishon Vijay Abraham I <kishon@ti.com>
-
-This document explains the Generic PHY Framework along with the APIs provided,
-and how-to-use.
-
-1. Introduction
-
-*PHY* is the abbreviation for physical layer. It is used to connect a device
-to the physical medium e.g., the USB controller has a PHY to provide functions
-such as serialization, de-serialization, encoding, decoding and is responsible
-for obtaining the required data transmission rate. Note that some USB
-controllers have PHY functionality embedded into it and others use an external
-PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
-SATA etc.
-
-The intention of creating this framework is to bring the PHY drivers spread
-all over the Linux kernel to drivers/phy to increase code re-use and for
-better code maintainability.
-
-This framework will be of use only to devices that use external PHY (PHY
-functionality is not embedded within the controller).
-
-2. Registering/Unregistering the PHY provider
-
-PHY provider refers to an entity that implements one or more PHY instances.
-For the simple case where the PHY provider implements only a single instance of
-the PHY, the framework provides its own implementation of of_xlate in
-of_phy_simple_xlate. If the PHY provider implements multiple instances, it
-should provide its own implementation of of_xlate. of_xlate is used only for
-dt boot case.
-
-struct phy_provider *__of_phy_provider_register(struct device *dev,
-	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
-	struct of_phandle_args *args));
-struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
-	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
-	struct of_phandle_args *args))
-
-__of_phy_provider_register and __devm_of_phy_provider_register can be used to
-register the phy_provider and it takes device, owner and of_xlate as
-arguments. For the dt boot case, all PHY providers should use one of the above
-2 APIs to register the PHY provider.
-
-void devm_of_phy_provider_unregister(struct device *dev,
-	struct phy_provider *phy_provider);
-void of_phy_provider_unregister(struct phy_provider *phy_provider);
-
-devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
-unregister the PHY.
-
-3. Creating the PHY
-
-The PHY driver should create the PHY in order for other peripheral controllers
-to make use of it. The PHY framework provides 2 APIs to create the PHY.
-
-struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
-	const char *label);
-extern struct phy *devm_phy_create(struct device *dev, u8 id,
-        const struct phy_ops *ops, const char *label);
-
-The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, id, phy ops, label and a driver data.
-phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *label* is mandatory for non-dt boot case
-and it should be unique as well.
-
-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
-
-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.
-
-struct phy *phy_get(struct device *dev, const char *string);
-struct phy *devm_phy_get(struct device *dev, const char *string);
-
-phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
-the string arguments should contain the phy name as given in the dt data and
-in the case of non-dt boot, it should contain the label of the PHY.
-The only difference between the two APIs is that devm_phy_get associates the
-device with the PHY using devres on successful PHY get. On driver detach,
-release function is invoked on the the devres data and devres data is freed.
-
-5. Releasing a reference to the PHY
-
-When the controller no longer needs the PHY, it has to release the reference
-to the PHY it has obtained using the APIs mentioned in the above section. The
-PHY framework provides 2 APIs to release a reference to the PHY.
-
-void phy_put(struct phy *phy);
-void devm_phy_put(struct device *dev, struct phy *phy);
-
-Both these APIs are used to release a reference to the PHY and devm_phy_put
-destroys the devres associated with this PHY.
-
-6. Destroying the PHY
-
-When the driver that created the PHY is unloaded, it should destroy the PHY it
-created using one of the following 2 APIs.
-
-void phy_destroy(struct phy *phy);
-void devm_phy_destroy(struct device *dev, struct phy *phy);
-
-Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
-associated with this PHY.
-
-7. PM Runtime
-
-This subsystem is pm runtime enabled. So while creating the PHY,
-pm_runtime_enable of the phy device created by this subsystem is called and
-while destroying the PHY, pm_runtime_disable is called. Note that the phy
-device created by this subsystem will be a child of the device that calls
-phy_create (PHY provider device).
-
-So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
-pm_runtime_get_sync of PHY provider device because of parent-child relationship.
-It should also be noted that phy_power_on and phy_power_off performs
-phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
-There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
-phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
-phy_pm_runtime_forbid for performing PM operations.
-
-8. DeviceTree Binding
-
-The documentation for PHY dt binding can be found @
-Documentation/devicetree/bindings/phy/phy-bindings.txt