On 07/21/2017 02:55 PM, Jean-Jacques Hiblot wrote:
On 21/07/2017 11:03, Marek Vasut wrote:
On 07/21/2017 10:49 AM, Jean-Jacques Hiblot wrote:
The no-op phy driver is useful when a driver uses the phy framework but no PHY driver is available for the hardware (or the hardware has no PHY).
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com
Following the email thread '[PATCH 1/1] dm: phy: add missing #ifdef CONFIG_PHY', here is a patch to add support for a no-op phy.
Jean-Jacques
Documentation/devicetree/bindings/phy/no-op.txt | 16 +++++++++++++++ drivers/phy/Kconfig | 18 +++++++++++++++++ drivers/phy/Makefile | 1 + drivers/phy/noop-phy.c | 26 +++++++++++++++++++++++++ 4 files changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/no-op.txt create mode 100644 drivers/phy/noop-phy.c
diff --git a/Documentation/devicetree/bindings/phy/no-op.txt b/Documentation/devicetree/bindings/phy/no-op.txt new file mode 100644 index 0000000..eb1a562 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/no-op.txt @@ -0,0 +1,16 @@ +NO-OP Phy driver
+The driver is used to stub PHY opeartions in a driver (USB, SATA).
operations
+This is useful when the PHY driver for a particular hardware doesn't exist yet +(the hardware is initialized by the platform code).
+Required properties: +- compatible : must contain "noop-phy" +- #phy-cells : must contain <0>
+Example:
+noop_phy {
- compatible = "noop-phy";
- #phy-cells = <0>;
+}; diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 7841554..68dced7 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -41,6 +41,24 @@ config PHY_SANDBOX This select a dummy sandbox PHY driver. It used only to implement the unit tests for the phy framework +config NOOP_PHY
- bool "no-op phy"
Please fix the option description, this is quite sloppy.
It's not that I want to induce in sloppiness, but I can't come up with a better description. Suggestions are welcome.
NOP USB PHY driver or something ?
- depends on PHY
- help
Support for a no-op PHYThis is useful when a driver uses the PHY framework but no driverhas yet been written for the PHY (or if there is no hardwarePHY).
This really is only useful if there is no dedicated PHY.
Also during the transition from platform code to DM code for the PHY. It allows setting up the 'client' driver first, and then the PHY driver.
You should implement a proper driver, we should not advertise this possibility.
+config SPL_NOOP_PHY
- bool "no-op phy in SPL"
DTTO
- depends on SPL_PHY
- help
Support for a no-op PHY in SPLThis is useful when a driver uses the PHY framework but no driverhas yet been written for the PHY (or if there is no hardwarePHY).
- config PIPE3_PHY bool "Support omap's PIPE3 PHY" depends on PHY && ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 6ce96d2..f129b5c 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -6,5 +6,6 @@ # obj-$(CONFIG_$(SPL_)PHY) += phy-uclass.o +obj-$(CONFIG_$(SPL_)NOOP_PHY) += noop-phy.o obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o diff --git a/drivers/phy/noop-phy.c b/drivers/phy/noop-phy.c new file mode 100644 index 0000000..14ccf86 --- /dev/null +++ b/drivers/phy/noop-phy.c @@ -0,0 +1,26 @@ +/*
- Copyright (C) 2017 Texas Instruments Incorporated -
- Written by Jean-Jacques Hiblot jjhiblot@ti.com
- SPDX-License-Identifier: GPL-2.0+
- */
+#include <common.h> +#include <dm.h> +#include <dm/device.h> +#include <generic-phy.h>
+static const struct udevice_id noop_phy_ids[] = {
- { .compatible = "noop-phy" },
- { }
+};
+static struct phy_ops noop_phy_ops = { +};
+U_BOOT_DRIVER(noop_phy) = {
- .name = "noop_phy",
- .id = UCLASS_PHY,
- .of_match = noop_phy_ids,
- .ops = &noop_phy_ops,
+};