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 <jjhib...@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.
+ depends on PHY
+ help
+ Support for a no-op PHY
+
+ This is useful when a driver uses the PHY framework but no driver
+ has yet been written for the PHY (or if there is no hardware PHY).
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.
+config SPL_NOOP_PHY
+ bool "no-op phy in SPL"
DTTO
+ depends on SPL_PHY
+ help
+ Support for a no-op PHY in SPL
+
+ This is useful when a driver uses the PHY framework but no driver
+ has yet been written for the PHY (or if there is no hardware PHY).
+
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 - http://www.ti.com/
+ * Written by Jean-Jacques Hiblot <jjhib...@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,
+};
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
