[PATCH v2 0/9] USB Device Controller support for BCM281xx

[PATCH v2 0/9] USB Device Controller support for BCM281xx

[Matt Porter]

Changes since v1:
	- Convert USB phy driver to generic phy subsystem
	- Add phy bus width apis
	- Drop dwc2 phy bus width DT property in favor of querying the
	  phy provider for bus width
	- Add generic phy/clock properties to dwc2 DT binding
	- Add generic phy subsystem support to s3c-hsotg with the
	  existing usb phy and pdata phy methods as a fallback
	- Split bindings out to separate patches to match the latest
	  DT binding review guidelines

This series adds USB Device Controller support for the Broadcom
BCM281xx family of parts. BCM281xx contains a DWC2 OTG block and
s3c-hsotg is used to support UDC operation.

Part 1 adds phy bus width support to the generic phy subsystem

Parts 2-6 allows s3c-hsotg to build on non-Samsung platforms, supports
the dwc2 binding, and enables generic phy support to support fetching
of the phy bus width.

Part 7-8 add a generic phy binding and driver for the BCM Kona USB PHY.

Part 9 adds the DT nodes to enable UDC support on both BCM281xx boards
in the kernel.

This series depends on the "Update Kona drivers to use clocks" series
(https://lkml.org/lkml/2013/10/3/645). The dependencies noted for that
series are already queued for 3.13. It also depends on the generic PHY
subsystem which has also been queued for 3.13.

Matt Porter (9):
  phy: add phy_get_bus_width()/phy_set_bus_width() calls
  staging: dwc2: update DT binding to add generic clock/phy properties
  usb: gadget: s3c-hsotg: enable build for other platforms
  usb: gadget: s3c-hsotg: add snps,dwc2 compatible string
  usb: gadget: s3c-hsotg: enable generic phy support
  usb: gadget: s3c-hsotg: get phy bus width from phy subsystem
  phy: add Broadcom Kona USB2 PHY DT binding
  phy: add Broadcom Kona USB2 PHY driver
  ARM: dts: add usb udc support to bcm281xx

 .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt  |  15 ++
 Documentation/devicetree/bindings/staging/dwc2.txt |  12 ++
 arch/arm/boot/dts/bcm11351-brt.dts                 |   6 +
 arch/arm/boot/dts/bcm11351.dtsi                    |  18 +++
 arch/arm/boot/dts/bcm28155-ap.dts                  |   8 +
 drivers/phy/Kconfig                                |   6 +
 drivers/phy/Makefile                               |   2 +
 drivers/phy/phy-bcm-kona-usb2.c                    | 161 +++++++++++++++++++++
 drivers/usb/gadget/Kconfig                         |   7 +-
 drivers/usb/gadget/s3c-hsotg.c                     |  71 ++++++---
 drivers/usb/gadget/s3c-hsotg.h                     |   1 +
 include/linux/phy/phy.h                            |  16 ++
 12 files changed, 298 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
 create mode 100644 drivers/phy/phy-bcm-kona-usb2.c

-- 
1.8.4

[PATCH v2 0/9] USB Device Controller support for BCM281xx

[Matt Porter]

Changes since v1:
	- Convert USB phy driver to generic phy subsystem
	- Add phy bus width apis
	- Drop dwc2 phy bus width DT property in favor of querying the
	  phy provider for bus width
	- Add generic phy/clock properties to dwc2 DT binding
	- Add generic phy subsystem support to s3c-hsotg with the
	  existing usb phy and pdata phy methods as a fallback
	- Split bindings out to separate patches to match the latest
	  DT binding review guidelines

This series adds USB Device Controller support for the Broadcom
BCM281xx family of parts. BCM281xx contains a DWC2 OTG block and
s3c-hsotg is used to support UDC operation.

Part 1 adds phy bus width support to the generic phy subsystem

Parts 2-6 allows s3c-hsotg to build on non-Samsung platforms, supports
the dwc2 binding, and enables generic phy support to support fetching
of the phy bus width.

Part 7-8 add a generic phy binding and driver for the BCM Kona USB PHY.

Part 9 adds the DT nodes to enable UDC support on both BCM281xx boards
in the kernel.

This series depends on the "Update Kona drivers to use clocks" series
(https://lkml.org/lkml/2013/10/3/645). The dependencies noted for that
series are already queued for 3.13. It also depends on the generic PHY
subsystem which has also been queued for 3.13.

Matt Porter (9):
  phy: add phy_get_bus_width()/phy_set_bus_width() calls
  staging: dwc2: update DT binding to add generic clock/phy properties
  usb: gadget: s3c-hsotg: enable build for other platforms
  usb: gadget: s3c-hsotg: add snps,dwc2 compatible string
  usb: gadget: s3c-hsotg: enable generic phy support
  usb: gadget: s3c-hsotg: get phy bus width from phy subsystem
  phy: add Broadcom Kona USB2 PHY DT binding
  phy: add Broadcom Kona USB2 PHY driver
  ARM: dts: add usb udc support to bcm281xx

 .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt  |  15 ++
 Documentation/devicetree/bindings/staging/dwc2.txt |  12 ++
 arch/arm/boot/dts/bcm11351-brt.dts                 |   6 +
 arch/arm/boot/dts/bcm11351.dtsi                    |  18 +++
 arch/arm/boot/dts/bcm28155-ap.dts                  |   8 +
 drivers/phy/Kconfig                                |   6 +
 drivers/phy/Makefile                               |   2 +
 drivers/phy/phy-bcm-kona-usb2.c                    | 161 +++++++++++++++++++++
 drivers/usb/gadget/Kconfig                         |   7 +-
 drivers/usb/gadget/s3c-hsotg.c                     |  71 ++++++---
 drivers/usb/gadget/s3c-hsotg.h                     |   1 +
 include/linux/phy/phy.h                            |  16 ++
 12 files changed, 298 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
 create mode 100644 drivers/phy/phy-bcm-kona-usb2.c

-- 
1.8.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/9] USB Device Controller support for BCM281xx

[Matt Porter]

Changes since v1:
	- Convert USB phy driver to generic phy subsystem
	- Add phy bus width apis
	- Drop dwc2 phy bus width DT property in favor of querying the
	  phy provider for bus width
	- Add generic phy/clock properties to dwc2 DT binding
	- Add generic phy subsystem support to s3c-hsotg with the
	  existing usb phy and pdata phy methods as a fallback
	- Split bindings out to separate patches to match the latest
	  DT binding review guidelines

This series adds USB Device Controller support for the Broadcom
BCM281xx family of parts. BCM281xx contains a DWC2 OTG block and
s3c-hsotg is used to support UDC operation.

Part 1 adds phy bus width support to the generic phy subsystem

Parts 2-6 allows s3c-hsotg to build on non-Samsung platforms, supports
the dwc2 binding, and enables generic phy support to support fetching
of the phy bus width.

Part 7-8 add a generic phy binding and driver for the BCM Kona USB PHY.

Part 9 adds the DT nodes to enable UDC support on both BCM281xx boards
in the kernel.

This series depends on the "Update Kona drivers to use clocks" series
(https://lkml.org/lkml/2013/10/3/645). The dependencies noted for that
series are already queued for 3.13. It also depends on the generic PHY
subsystem which has also been queued for 3.13.

Matt Porter (9):
  phy: add phy_get_bus_width()/phy_set_bus_width() calls
  staging: dwc2: update DT binding to add generic clock/phy properties
  usb: gadget: s3c-hsotg: enable build for other platforms
  usb: gadget: s3c-hsotg: add snps,dwc2 compatible string
  usb: gadget: s3c-hsotg: enable generic phy support
  usb: gadget: s3c-hsotg: get phy bus width from phy subsystem
  phy: add Broadcom Kona USB2 PHY DT binding
  phy: add Broadcom Kona USB2 PHY driver
  ARM: dts: add usb udc support to bcm281xx

 .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt  |  15 ++
 Documentation/devicetree/bindings/staging/dwc2.txt |  12 ++
 arch/arm/boot/dts/bcm11351-brt.dts                 |   6 +
 arch/arm/boot/dts/bcm11351.dtsi                    |  18 +++
 arch/arm/boot/dts/bcm28155-ap.dts                  |   8 +
 drivers/phy/Kconfig                                |   6 +
 drivers/phy/Makefile                               |   2 +
 drivers/phy/phy-bcm-kona-usb2.c                    | 161 +++++++++++++++++++++
 drivers/usb/gadget/Kconfig                         |   7 +-
 drivers/usb/gadget/s3c-hsotg.c                     |  71 ++++++---
 drivers/usb/gadget/s3c-hsotg.h                     |   1 +
 include/linux/phy/phy.h                            |  16 ++
 12 files changed, 298 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
 create mode 100644 drivers/phy/phy-bcm-kona-usb2.c

-- 
1.8.4

[PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Matt Porter]

This adds a pair of APIs that allows the generic PHY subsystem to
provide information on the PHY bus width. The PHY provider driver may
use phy_set_bus_width() to set the bus width that the PHY supports.
The controller driver may then use phy_get_bus_width() to fetch the
PHY bus width in order to properly configure the controller.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 include/linux/phy/phy.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 6d72269..e858ce1 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -46,6 +46,7 @@ struct phy_ops {
  * @mutex: mutex to protect phy_ops
  * @init_count: used to protect when the PHY is used by multiple consumers
  * @power_count: used to protect when the PHY is used by multiple consumers
+ * @bus_width: used to specify data width of the PHY bus
  */
 struct phy {
 	struct device		dev;
@@ -55,6 +56,7 @@ struct phy {
 	struct mutex		mutex;
 	int			init_count;
 	int			power_count;
+	int			bus_width;
 };
 
 /**
@@ -127,6 +129,12 @@ int phy_init(struct phy *phy);
 int phy_exit(struct phy *phy);
 int phy_power_on(struct phy *phy);
 int phy_power_off(struct phy *phy);
+static inline int phy_get_bus_width(struct phy *phy) {
+	return phy->bus_width;
+};
+static inline void phy_set_bus_width(struct phy *phy, int bus_width) {
+	phy->bus_width = bus_width;
+};
 struct phy *phy_get(struct device *dev, const char *string);
 struct phy *devm_phy_get(struct device *dev, const char *string);
 void phy_put(struct phy *phy);
@@ -199,6 +207,14 @@ static inline int phy_power_off(struct phy *phy)
 	return -ENOSYS;
 }
 
+static inline int phy_get_bus_width(struct phy *phy) {
+	return -ENOSYS;
+};
+
+static inline void phy_set_bus_width(struct phy *phy, bus_width) {
+	return;
+};
+
 static inline struct phy *phy_get(struct device *dev, const char *string)
 {
 	return ERR_PTR(-ENOSYS);
-- 
1.8.4

[PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Matt Porter]

This adds a pair of APIs that allows the generic PHY subsystem to
provide information on the PHY bus width. The PHY provider driver may
use phy_set_bus_width() to set the bus width that the PHY supports.
The controller driver may then use phy_get_bus_width() to fetch the
PHY bus width in order to properly configure the controller.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 include/linux/phy/phy.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 6d72269..e858ce1 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -46,6 +46,7 @@ struct phy_ops {
  * @mutex: mutex to protect phy_ops
  * @init_count: used to protect when the PHY is used by multiple consumers
  * @power_count: used to protect when the PHY is used by multiple consumers
+ * @bus_width: used to specify data width of the PHY bus
  */
 struct phy {
 	struct device		dev;
@@ -55,6 +56,7 @@ struct phy {
 	struct mutex		mutex;
 	int			init_count;
 	int			power_count;
+	int			bus_width;
 };
 
 /**
@@ -127,6 +129,12 @@ int phy_init(struct phy *phy);
 int phy_exit(struct phy *phy);
 int phy_power_on(struct phy *phy);
 int phy_power_off(struct phy *phy);
+static inline int phy_get_bus_width(struct phy *phy) {
+	return phy->bus_width;
+};
+static inline void phy_set_bus_width(struct phy *phy, int bus_width) {
+	phy->bus_width = bus_width;
+};
 struct phy *phy_get(struct device *dev, const char *string);
 struct phy *devm_phy_get(struct device *dev, const char *string);
 void phy_put(struct phy *phy);
@@ -199,6 +207,14 @@ static inline int phy_power_off(struct phy *phy)
 	return -ENOSYS;
 }
 
+static inline int phy_get_bus_width(struct phy *phy) {
+	return -ENOSYS;
+};
+
+static inline void phy_set_bus_width(struct phy *phy, bus_width) {
+	return;
+};
+
 static inline struct phy *phy_get(struct device *dev, const char *string)
 {
 	return ERR_PTR(-ENOSYS);
-- 
1.8.4

[PATCH v2 2/9] staging: dwc2: update DT binding to add generic clock/phy properties

[Matt Porter]

dwc2/s3c-hsotg require a single clock to be specified and optionally
a generic phy. On the s3c-hsotg driver old style USB phy support is
present as a fallback so the generic phy properties are optional.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 Documentation/devicetree/bindings/staging/dwc2.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt
index 1a1b7cf..f60477e 100644
--- a/Documentation/devicetree/bindings/staging/dwc2.txt
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -5,6 +5,14 @@ Required properties:
 - compatible : "snps,dwc2"
 - reg : Should contain 1 register range (address and length)
 - interrupts : Should contain 1 interrupt
+- clocks: clock provider specifier
+- clock-names: shall be "otg"
+Refer to clk/clock-bindings.txt for generic clock consumer properties
+
+Optional properties:
+- phys: phy provider specifier
+- phy-names: shall be "usb2-phy"
+Refer to phy/phy-bindings.txt for generic phy consumer properties
 
 Example:
 
@@ -12,4 +20,8 @@ Example:
                 compatible = "ralink,rt3050-usb, snps,dwc2";
                 reg = <0x101c0000 40000>;
                 interrupts = <18>;
+		clocks = <&usb_otg_ahb_clk>;
+		clock-names = "otg";
+		phys = <&usbphy>;
+		phy-names = "usb2-phy";
         };
-- 
1.8.4

[PATCH v2 2/9] staging: dwc2: update DT binding to add generic clock/phy properties

[Matt Porter]

dwc2/s3c-hsotg require a single clock to be specified and optionally
a generic phy. On the s3c-hsotg driver old style USB phy support is
present as a fallback so the generic phy properties are optional.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 Documentation/devicetree/bindings/staging/dwc2.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt
index 1a1b7cf..f60477e 100644
--- a/Documentation/devicetree/bindings/staging/dwc2.txt
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -5,6 +5,14 @@ Required properties:
 - compatible : "snps,dwc2"
 - reg : Should contain 1 register range (address and length)
 - interrupts : Should contain 1 interrupt
+- clocks: clock provider specifier
+- clock-names: shall be "otg"
+Refer to clk/clock-bindings.txt for generic clock consumer properties
+
+Optional properties:
+- phys: phy provider specifier
+- phy-names: shall be "usb2-phy"
+Refer to phy/phy-bindings.txt for generic phy consumer properties
 
 Example:
 
@@ -12,4 +20,8 @@ Example:
                 compatible = "ralink,rt3050-usb, snps,dwc2";
                 reg = <0x101c0000 40000>;
                 interrupts = <18>;
+		clocks = <&usb_otg_ahb_clk>;
+		clock-names = "otg";
+		phys = <&usbphy>;
+		phy-names = "usb2-phy";
         };
-- 
1.8.4

[PATCH v2 2/9] staging: dwc2: update DT binding to add generic clock/phy properties

[Matt Porter]

dwc2/s3c-hsotg require a single clock to be specified and optionally
a generic phy. On the s3c-hsotg driver old style USB phy support is
present as a fallback so the generic phy properties are optional.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 Documentation/devicetree/bindings/staging/dwc2.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt
index 1a1b7cf..f60477e 100644
--- a/Documentation/devicetree/bindings/staging/dwc2.txt
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -5,6 +5,14 @@ Required properties:
 - compatible : "snps,dwc2"
 - reg : Should contain 1 register range (address and length)
 - interrupts : Should contain 1 interrupt
+- clocks: clock provider specifier
+- clock-names: shall be "otg"
+Refer to clk/clock-bindings.txt for generic clock consumer properties
+
+Optional properties:
+- phys: phy provider specifier
+- phy-names: shall be "usb2-phy"
+Refer to phy/phy-bindings.txt for generic phy consumer properties
 
 Example:
 
@@ -12,4 +20,8 @@ Example:
                 compatible = "ralink,rt3050-usb, snps,dwc2";
                 reg = <0x101c0000 40000>;
                 interrupts = <18>;
+		clocks = <&usb_otg_ahb_clk>;
+		clock-names = "otg";
+		phys = <&usbphy>;
+		phy-names = "usb2-phy";
         };
-- 
1.8.4

[PATCH v2 3/9] usb: gadget: s3c-hsotg: enable build for other platforms

[Matt Porter]

Remove unused Samsung-specific machine include and Kconfig
dependency on S3C.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
---
 drivers/usb/gadget/Kconfig     | 7 +++----
 drivers/usb/gadget/s3c-hsotg.c | 2 --
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 48cddf3..2e69fa0 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -280,11 +280,10 @@ config USB_PXA27X
 	   gadget drivers to also be dynamically linked.
 
 config USB_S3C_HSOTG
-	tristate "S3C HS/OtG USB Device controller"
-	depends on S3C_DEV_USB_HSOTG
+	tristate "Designware/S3C HS/OtG USB Device controller"
 	help
-	  The Samsung S3C64XX USB2.0 high-speed gadget controller
-	  integrated into the S3C64XX series SoC.
+	  The Designware USB2.0 high-speed gadget controller
+	  integrated into the S3C64XX and BCM281xx series SoC.
 
 config USB_S3C2410
 	tristate "S3C2410 USB Device Controller"
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index a8a99e4..258bc73 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -36,8 +36,6 @@
 #include <linux/usb/phy.h>
 #include <linux/platform_data/s3c-hsotg.h>
 
-#include <mach/map.h>
-
 #include "s3c-hsotg.h"
 
 static const char * const s3c_hsotg_supply_names[] = {
-- 
1.8.4

[PATCH v2 3/9] usb: gadget: s3c-hsotg: enable build for other platforms

[Matt Porter]

Remove unused Samsung-specific machine include and Kconfig
dependency on S3C.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
---
 drivers/usb/gadget/Kconfig     | 7 +++----
 drivers/usb/gadget/s3c-hsotg.c | 2 --
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 48cddf3..2e69fa0 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -280,11 +280,10 @@ config USB_PXA27X
 	   gadget drivers to also be dynamically linked.
 
 config USB_S3C_HSOTG
-	tristate "S3C HS/OtG USB Device controller"
-	depends on S3C_DEV_USB_HSOTG
+	tristate "Designware/S3C HS/OtG USB Device controller"
 	help
-	  The Samsung S3C64XX USB2.0 high-speed gadget controller
-	  integrated into the S3C64XX series SoC.
+	  The Designware USB2.0 high-speed gadget controller
+	  integrated into the S3C64XX and BCM281xx series SoC.
 
 config USB_S3C2410
 	tristate "S3C2410 USB Device Controller"
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index a8a99e4..258bc73 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -36,8 +36,6 @@
 #include <linux/usb/phy.h>
 #include <linux/platform_data/s3c-hsotg.h>
 
-#include <mach/map.h>
-
 #include "s3c-hsotg.h"
 
 static const char * const s3c_hsotg_supply_names[] = {
-- 
1.8.4

[PATCH v2 4/9] usb: gadget: s3c-hsotg: add snps,dwc2 compatible string

[Matt Porter]

Enable support for the dwc2 binding.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/usb/gadget/s3c-hsotg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 258bc73..3e0c124 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -3645,6 +3645,7 @@ static int s3c_hsotg_remove(struct platform_device *pdev)
 #ifdef CONFIG_OF
 static const struct of_device_id s3c_hsotg_of_ids[] = {
 	{ .compatible = "samsung,s3c6400-hsotg", },
+	{ .compatible = "snps,dwc2", },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, s3c_hsotg_of_ids);
-- 
1.8.4

[PATCH v2 4/9] usb: gadget: s3c-hsotg: add snps, dwc2 compatible string

[Matt Porter]

Enable support for the dwc2 binding.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/usb/gadget/s3c-hsotg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 258bc73..3e0c124 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -3645,6 +3645,7 @@ static int s3c_hsotg_remove(struct platform_device *pdev)
 #ifdef CONFIG_OF
 static const struct of_device_id s3c_hsotg_of_ids[] = {
 	{ .compatible = "samsung,s3c6400-hsotg", },
+	{ .compatible = "snps,dwc2", },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, s3c_hsotg_of_ids);
-- 
1.8.4

[PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support

[Matt Porter]

Adds support for the generic PHY subsystem. Generic PHY
support is probed and then the driver falls back to checking
for an old style USB PHY and pdata if not found.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/usb/gadget/s3c-hsotg.c | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 3e0c124..f97978b 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -34,6 +34,7 @@
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>
 #include <linux/usb/phy.h>
+#include <linux/phy/phy.h>
 #include <linux/platform_data/s3c-hsotg.h>
 
 #include "s3c-hsotg.h"
@@ -131,7 +132,8 @@ struct s3c_hsotg_ep {
  * struct s3c_hsotg - driver state.
  * @dev: The parent device supplied to the probe function
  * @driver: USB gadget driver
- * @phy: The otg phy transceiver structure for phy control.
+ * @phy: The otg phy transceiver structure for old USB phy control.
+ * @gphy: The otg phy transceiver structure for generic phy control.
  * @plat: The platform specific configuration data. This can be removed once
  * all SoCs support usb transceiver.
  * @regs: The memory area mapped for accessing registers.
@@ -154,6 +156,7 @@ struct s3c_hsotg {
 	struct device		 *dev;
 	struct usb_gadget_driver *driver;
 	struct usb_phy		*phy;
+	struct phy		*gphy;
 	struct s3c_hsotg_plat	 *plat;
 
 	spinlock_t              lock;
@@ -2820,9 +2823,12 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg *hsotg)
 
 	dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
 
-	if (hsotg->phy)
+	if (hsotg->gphy) {
+		phy_init(hsotg->gphy);
+		phy_power_on(hsotg->gphy);
+	} else if (hsotg->phy) {
 		usb_phy_init(hsotg->phy);
-	else if (hsotg->plat->phy_init)
+	} else if (hsotg->plat->phy_init)
 		hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
 }
 
@@ -2837,9 +2843,12 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg *hsotg)
 {
 	struct platform_device *pdev = to_platform_device(hsotg->dev);
 
-	if (hsotg->phy)
+	if (hsotg->gphy) {
+		phy_power_off(hsotg->gphy);
+		phy_exit(hsotg->gphy);
+	} else if (hsotg->phy) {
 		usb_phy_shutdown(hsotg->phy);
-	else if (hsotg->plat->phy_exit)
+	} else if (hsotg->plat->phy_exit)
 		hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
 }
 
@@ -3446,6 +3455,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
 {
 	struct s3c_hsotg_plat *plat = dev_get_platdata(&pdev->dev);
 	struct usb_phy *phy;
+	struct phy *gphy;
 	struct device *dev = &pdev->dev;
 	struct s3c_hsotg_ep *eps;
 	struct s3c_hsotg *hsotg;
@@ -3460,19 +3470,27 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-	if (IS_ERR(phy)) {
-		/* Fallback for pdata */
-		plat = dev_get_platdata(&pdev->dev);
-		if (!plat) {
-			dev_err(&pdev->dev, "no platform data or transceiver defined\n");
-			return -EPROBE_DEFER;
-		} else {
-			hsotg->plat = plat;
-		}
-	} else {
-		hsotg->phy = phy;
-	}
+	/*
+	 * Attempt to find a generic PHY, then look for an old style
+	 *  USB PHY, finally fall back to pdata
+	 */
+	gphy = devm_phy_get(dev, "usb2-phy");
+	if (IS_ERR(gphy)) {
+		phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+		if (IS_ERR(phy)) {
+			/* Fallback for pdata */
+			plat = dev_get_platdata(&pdev->dev);
+			if (!plat) {
+				dev_err(&pdev->dev,
+					"no platform data or transceiver defined\n");
+				return -EPROBE_DEFER;
+			} else {
+				hsotg->plat = plat;
+			}
+		} else
+			hsotg->phy = phy;
+	} else
+		hsotg->gphy = gphy;
 
 	hsotg->dev = dev;
 
-- 
1.8.4

[PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support

[Matt Porter]

Adds support for the generic PHY subsystem. Generic PHY
support is probed and then the driver falls back to checking
for an old style USB PHY and pdata if not found.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/usb/gadget/s3c-hsotg.c | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 3e0c124..f97978b 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -34,6 +34,7 @@
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>
 #include <linux/usb/phy.h>
+#include <linux/phy/phy.h>
 #include <linux/platform_data/s3c-hsotg.h>
 
 #include "s3c-hsotg.h"
@@ -131,7 +132,8 @@ struct s3c_hsotg_ep {
  * struct s3c_hsotg - driver state.
  * @dev: The parent device supplied to the probe function
  * @driver: USB gadget driver
- * @phy: The otg phy transceiver structure for phy control.
+ * @phy: The otg phy transceiver structure for old USB phy control.
+ * @gphy: The otg phy transceiver structure for generic phy control.
  * @plat: The platform specific configuration data. This can be removed once
  * all SoCs support usb transceiver.
  * @regs: The memory area mapped for accessing registers.
@@ -154,6 +156,7 @@ struct s3c_hsotg {
 	struct device		 *dev;
 	struct usb_gadget_driver *driver;
 	struct usb_phy		*phy;
+	struct phy		*gphy;
 	struct s3c_hsotg_plat	 *plat;
 
 	spinlock_t              lock;
@@ -2820,9 +2823,12 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg *hsotg)
 
 	dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
 
-	if (hsotg->phy)
+	if (hsotg->gphy) {
+		phy_init(hsotg->gphy);
+		phy_power_on(hsotg->gphy);
+	} else if (hsotg->phy) {
 		usb_phy_init(hsotg->phy);
-	else if (hsotg->plat->phy_init)
+	} else if (hsotg->plat->phy_init)
 		hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
 }
 
@@ -2837,9 +2843,12 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg *hsotg)
 {
 	struct platform_device *pdev = to_platform_device(hsotg->dev);
 
-	if (hsotg->phy)
+	if (hsotg->gphy) {
+		phy_power_off(hsotg->gphy);
+		phy_exit(hsotg->gphy);
+	} else if (hsotg->phy) {
 		usb_phy_shutdown(hsotg->phy);
-	else if (hsotg->plat->phy_exit)
+	} else if (hsotg->plat->phy_exit)
 		hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
 }
 
@@ -3446,6 +3455,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
 {
 	struct s3c_hsotg_plat *plat = dev_get_platdata(&pdev->dev);
 	struct usb_phy *phy;
+	struct phy *gphy;
 	struct device *dev = &pdev->dev;
 	struct s3c_hsotg_ep *eps;
 	struct s3c_hsotg *hsotg;
@@ -3460,19 +3470,27 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-	if (IS_ERR(phy)) {
-		/* Fallback for pdata */
-		plat = dev_get_platdata(&pdev->dev);
-		if (!plat) {
-			dev_err(&pdev->dev, "no platform data or transceiver defined\n");
-			return -EPROBE_DEFER;
-		} else {
-			hsotg->plat = plat;
-		}
-	} else {
-		hsotg->phy = phy;
-	}
+	/*
+	 * Attempt to find a generic PHY, then look for an old style
+	 *  USB PHY, finally fall back to pdata
+	 */
+	gphy = devm_phy_get(dev, "usb2-phy");
+	if (IS_ERR(gphy)) {
+		phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+		if (IS_ERR(phy)) {
+			/* Fallback for pdata */
+			plat = dev_get_platdata(&pdev->dev);
+			if (!plat) {
+				dev_err(&pdev->dev,
+					"no platform data or transceiver defined\n");
+				return -EPROBE_DEFER;
+			} else {
+				hsotg->plat = plat;
+			}
+		} else
+			hsotg->phy = phy;
+	} else
+		hsotg->gphy = gphy;
 
 	hsotg->dev = dev;
 
-- 
1.8.4

[PATCH v2 6/9] usb: gadget: s3c-hsotg: get phy bus width from phy subsystem

[Matt Porter]

Adds support for querying the phy bus width from the generic phy
subsystem. Configure UTMI bus width in GUSBCFG based on this value.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/usb/gadget/s3c-hsotg.c | 14 +++++++++++++-
 drivers/usb/gadget/s3c-hsotg.h |  1 +
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index f97978b..0be6242 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -139,6 +139,7 @@ struct s3c_hsotg_ep {
  * @regs: The memory area mapped for accessing registers.
  * @irq: The IRQ number we are using
  * @supplies: Definition of USB power supplies
+ * @phyif: PHY interface width
  * @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
  * @num_of_eps: Number of available EPs (excluding EP0)
  * @debug_root: root directrory for debugfs.
@@ -167,6 +168,7 @@ struct s3c_hsotg {
 
 	struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
 
+	u32			phyif;
 	unsigned int		dedicated_fifos:1;
 	unsigned char           num_of_eps;
 
@@ -2215,7 +2217,7 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
 	 */
 
 	/* set the PLL on, remove the HNP/SRP and set the PHY */
-	writel(GUSBCFG_PHYIf16 | GUSBCFG_TOutCal(7) |
+	writel(hsotg->phyif | GUSBCFG_TOutCal(7) |
 	       (0x5 << 10), hsotg->regs + GUSBCFG);
 
 	s3c_hsotg_init_fifo(hsotg);
@@ -3557,6 +3559,16 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
 		goto err_supplies;
 	}
 
+	/* Set default UTMI width */
+	hsotg->phyif = GUSBCFG_PHYIf16;
+
+	/*
+	 * If using the generic PHY framework, check if the PHY bus
+	 * width is 8-bit and set the phyif appropriately.
+	 */
+	if (hsotg->gphy && (phy_get_bus_width(gphy) == 8))
+		hsotg->phyif = GUSBCFG_PHYIf8;
+
 	/* usb phy enable */
 	s3c_hsotg_phy_enable(hsotg);
 
diff --git a/drivers/usb/gadget/s3c-hsotg.h b/drivers/usb/gadget/s3c-hsotg.h
index d650b12..85f549f 100644
--- a/drivers/usb/gadget/s3c-hsotg.h
+++ b/drivers/usb/gadget/s3c-hsotg.h
@@ -55,6 +55,7 @@
 #define GUSBCFG_HNPCap				(1 << 9)
 #define GUSBCFG_SRPCap				(1 << 8)
 #define GUSBCFG_PHYIf16			(1 << 3)
+#define GUSBCFG_PHYIf8				(0 << 3)
 #define GUSBCFG_TOutCal_MASK			(0x7 << 0)
 #define GUSBCFG_TOutCal_SHIFT			(0)
 #define GUSBCFG_TOutCal_LIMIT			(0x7)
-- 
1.8.4

[PATCH v2 6/9] usb: gadget: s3c-hsotg: get phy bus width from phy subsystem

[Matt Porter]

Adds support for querying the phy bus width from the generic phy
subsystem. Configure UTMI bus width in GUSBCFG based on this value.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/usb/gadget/s3c-hsotg.c | 14 +++++++++++++-
 drivers/usb/gadget/s3c-hsotg.h |  1 +
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index f97978b..0be6242 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -139,6 +139,7 @@ struct s3c_hsotg_ep {
  * @regs: The memory area mapped for accessing registers.
  * @irq: The IRQ number we are using
  * @supplies: Definition of USB power supplies
+ * @phyif: PHY interface width
  * @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
  * @num_of_eps: Number of available EPs (excluding EP0)
  * @debug_root: root directrory for debugfs.
@@ -167,6 +168,7 @@ struct s3c_hsotg {
 
 	struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
 
+	u32			phyif;
 	unsigned int		dedicated_fifos:1;
 	unsigned char           num_of_eps;
 
@@ -2215,7 +2217,7 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
 	 */
 
 	/* set the PLL on, remove the HNP/SRP and set the PHY */
-	writel(GUSBCFG_PHYIf16 | GUSBCFG_TOutCal(7) |
+	writel(hsotg->phyif | GUSBCFG_TOutCal(7) |
 	       (0x5 << 10), hsotg->regs + GUSBCFG);
 
 	s3c_hsotg_init_fifo(hsotg);
@@ -3557,6 +3559,16 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
 		goto err_supplies;
 	}
 
+	/* Set default UTMI width */
+	hsotg->phyif = GUSBCFG_PHYIf16;
+
+	/*
+	 * If using the generic PHY framework, check if the PHY bus
+	 * width is 8-bit and set the phyif appropriately.
+	 */
+	if (hsotg->gphy && (phy_get_bus_width(gphy) == 8))
+		hsotg->phyif = GUSBCFG_PHYIf8;
+
 	/* usb phy enable */
 	s3c_hsotg_phy_enable(hsotg);
 
diff --git a/drivers/usb/gadget/s3c-hsotg.h b/drivers/usb/gadget/s3c-hsotg.h
index d650b12..85f549f 100644
--- a/drivers/usb/gadget/s3c-hsotg.h
+++ b/drivers/usb/gadget/s3c-hsotg.h
@@ -55,6 +55,7 @@
 #define GUSBCFG_HNPCap				(1 << 9)
 #define GUSBCFG_SRPCap				(1 << 8)
 #define GUSBCFG_PHYIf16			(1 << 3)
+#define GUSBCFG_PHYIf8				(0 << 3)
 #define GUSBCFG_TOutCal_MASK			(0x7 << 0)
 #define GUSBCFG_TOutCal_SHIFT			(0)
 #define GUSBCFG_TOutCal_LIMIT			(0x7)
-- 
1.8.4

[PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Matt Porter]

Add a binding that describes the Broadcom Kona USB2 PHY found
on the BCM281xx family of SoCs.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
new file mode 100644
index 0000000..db309e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
@@ -0,0 +1,15 @@
+BROADCOM KONA USB2 PHY
+
+Required properties:
+ - compatible: brcm,kona-usb2-phy
+ - regs: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+	usbphy: usbphy@3f130000 {
+		compatible = "brcm,kona-usb2-phy";
+		reg = <0x3f130000 0x28>;
+		#phy-cells = <0>;
+	};
-- 
1.8.4

[PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Matt Porter]

Add a binding that describes the Broadcom Kona USB2 PHY found
on the BCM281xx family of SoCs.

Signed-off-by: Matt Porter <matt.porter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
new file mode 100644
index 0000000..db309e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
@@ -0,0 +1,15 @@
+BROADCOM KONA USB2 PHY
+
+Required properties:
+ - compatible: brcm,kona-usb2-phy
+ - regs: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+	usbphy: usbphy@3f130000 {
+		compatible = "brcm,kona-usb2-phy";
+		reg = <0x3f130000 0x28>;
+		#phy-cells = <0>;
+	};
-- 
1.8.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Matt Porter]

Add a binding that describes the Broadcom Kona USB2 PHY found
on the BCM281xx family of SoCs.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
new file mode 100644
index 0000000..db309e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
@@ -0,0 +1,15 @@
+BROADCOM KONA USB2 PHY
+
+Required properties:
+ - compatible: brcm,kona-usb2-phy
+ - regs: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+	usbphy: usbphy at 3f130000 {
+		compatible = "brcm,kona-usb2-phy";
+		reg = <0x3f130000 0x28>;
+		#phy-cells = <0>;
+	};
-- 
1.8.4

[PATCH v2 8/9] phy: add Broadcom Kona USB2 PHY driver

[Matt Porter]

Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/phy/Kconfig             |   6 ++
 drivers/phy/Makefile            |   2 +
 drivers/phy/phy-bcm-kona-usb2.c | 161 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 169 insertions(+)
 create mode 100644 drivers/phy/phy-bcm-kona-usb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..cedada5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,10 @@ config GENERIC_PHY
 	  phy users can obtain reference to the PHY. All the users of this
 	  framework should select this config.
 
+config BCM_KONA_USB2_PHY
+	tristate "Broadcom Kona USB2 PHY Driver"
+	depends on GENERIC_PHY
+	help
+	  Enable this to support the Broadcom Kona USB 2.0 PHY.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ce83a14 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,5 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
+
+obj-$(CONFIG_BCM_KONA_USB2_PHY)	+= phy-bcm-kona-usb2.o
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
new file mode 100644
index 0000000..1beea7f
--- /dev/null
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -0,0 +1,161 @@
+/*
+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
+ *
+ * Copyright (C) 2013 Linaro Limited
+ * Matt Porter <matt.porter@linaro.org>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/phy/phy.h>
+
+#define OTGCTL_OTGSTAT2		(1 << 31)
+#define OTGCTL_OTGSTAT1		(1 << 30)
+#define OTGCTL_PRST_N_SW	(1 << 11)
+#define OTGCTL_HRESET_N		(1 << 10)
+#define OTGCTL_UTMI_LINE_STATE1	(1 << 9)
+#define OTGCTL_UTMI_LINE_STATE0	(1 << 8)
+
+#define P1CTL_SOFT_RESET	(1 << 1)
+#define P1CTL_NON_DRIVING	(1 << 0)
+
+struct bcm_kona_usb_phy_regs {
+	u32 ctrl;
+	u32 cfg;
+	u32 p1ctl;
+	u32 status;
+	u32 bc_cfg;
+	u32 tp_in;
+	u32 tp_out;
+	u32 phy_ctrl;
+	u32 usbreg;
+	u32 usbproben;
+};
+
+struct bcm_kona_usb {
+	struct bcm_kona_usb_phy_regs *regs;
+};
+
+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
+{
+	u32 val;
+
+	val = readl(&phy->regs->ctrl);
+	if (on) {
+		/* Configure and power PHY */
+		val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
+			 OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
+		val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
+		writel(val, &phy->regs->ctrl);
+
+		/* Soft reset PHY */
+		val = readl(&phy->regs->p1ctl);
+		val &= ~P1CTL_NON_DRIVING;
+		val |= P1CTL_SOFT_RESET;
+		writel(val, &phy->regs->p1ctl);
+		writel(val & ~P1CTL_SOFT_RESET, &phy->regs->p1ctl);
+		/* Reset needs to be asserted for 2ms */
+		mdelay(2);
+		writel(val | P1CTL_SOFT_RESET, &phy->regs->p1ctl);
+	} else {
+		val &= ~(OTGCTL_PRST_N_SW | OTGCTL_HRESET_N);
+		writel(val, &phy->regs->ctrl);
+	}
+}
+
+static int bcm_kona_usb_phy_power_on(struct phy *gphy)
+{
+	struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+	bcm_kona_usb_phy_power(phy, 1);
+
+	return 0;
+}
+
+static int bcm_kona_usb_phy_power_off(struct phy *gphy)
+{
+	struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+	bcm_kona_usb_phy_power(phy, 0);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= bcm_kona_usb_phy_power_on,
+	.power_off	= bcm_kona_usb_phy_power_off,
+	.owner = THIS_MODULE,
+};
+
+static int bcm_kona_usb2_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct bcm_kona_usb *phy;
+	struct resource *res;
+	struct phy *gphy;
+	struct phy_provider *phy_provider;
+
+	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+	if (!phy)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	phy->regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(phy->regs))
+		return PTR_ERR(phy->regs);
+
+	platform_set_drvdata(pdev, phy);
+
+	phy_provider = devm_of_phy_provider_register(dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	gphy = devm_phy_create(dev, &ops, NULL);
+	if (IS_ERR(gphy))
+		return PTR_ERR(gphy);
+
+	/* The Kona PHY supports an 8-bit wide UTMI interface */
+	phy_set_bus_width(gphy, 8);
+
+	phy_set_drvdata(gphy, phy);
+
+	return 0;
+}
+
+static const struct of_device_id bcm_kona_usb2_dt_ids[] = {
+	{ .compatible = "brcm,kona-usb2-phy" },
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, bcm_kona_usb2_dt_ids);
+
+static struct platform_driver bcm_kona_usb2_driver = {
+	.probe		= bcm_kona_usb2_probe,
+	.driver		= {
+		.name	= "bcm-kona-usb2",
+		.owner	= THIS_MODULE,
+		.of_match_table = bcm_kona_usb2_dt_ids,
+	},
+};
+
+module_platform_driver(bcm_kona_usb2_driver);
+
+MODULE_ALIAS("platform:bcm-kona-usb2");
+MODULE_AUTHOR("Matt Porter");
+MODULE_DESCRIPTION("BCM Kona USB 2.0 PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.4

[PATCH v2 8/9] phy: add Broadcom Kona USB2 PHY driver

[Matt Porter]

Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
---
 drivers/phy/Kconfig             |   6 ++
 drivers/phy/Makefile            |   2 +
 drivers/phy/phy-bcm-kona-usb2.c | 161 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 169 insertions(+)
 create mode 100644 drivers/phy/phy-bcm-kona-usb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..cedada5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,10 @@ config GENERIC_PHY
 	  phy users can obtain reference to the PHY. All the users of this
 	  framework should select this config.
 
+config BCM_KONA_USB2_PHY
+	tristate "Broadcom Kona USB2 PHY Driver"
+	depends on GENERIC_PHY
+	help
+	  Enable this to support the Broadcom Kona USB 2.0 PHY.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ce83a14 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,5 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
+
+obj-$(CONFIG_BCM_KONA_USB2_PHY)	+= phy-bcm-kona-usb2.o
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
new file mode 100644
index 0000000..1beea7f
--- /dev/null
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -0,0 +1,161 @@
+/*
+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
+ *
+ * Copyright (C) 2013 Linaro Limited
+ * Matt Porter <matt.porter@linaro.org>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/phy/phy.h>
+
+#define OTGCTL_OTGSTAT2		(1 << 31)
+#define OTGCTL_OTGSTAT1		(1 << 30)
+#define OTGCTL_PRST_N_SW	(1 << 11)
+#define OTGCTL_HRESET_N		(1 << 10)
+#define OTGCTL_UTMI_LINE_STATE1	(1 << 9)
+#define OTGCTL_UTMI_LINE_STATE0	(1 << 8)
+
+#define P1CTL_SOFT_RESET	(1 << 1)
+#define P1CTL_NON_DRIVING	(1 << 0)
+
+struct bcm_kona_usb_phy_regs {
+	u32 ctrl;
+	u32 cfg;
+	u32 p1ctl;
+	u32 status;
+	u32 bc_cfg;
+	u32 tp_in;
+	u32 tp_out;
+	u32 phy_ctrl;
+	u32 usbreg;
+	u32 usbproben;
+};
+
+struct bcm_kona_usb {
+	struct bcm_kona_usb_phy_regs *regs;
+};
+
+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
+{
+	u32 val;
+
+	val = readl(&phy->regs->ctrl);
+	if (on) {
+		/* Configure and power PHY */
+		val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
+			 OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
+		val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
+		writel(val, &phy->regs->ctrl);
+
+		/* Soft reset PHY */
+		val = readl(&phy->regs->p1ctl);
+		val &= ~P1CTL_NON_DRIVING;
+		val |= P1CTL_SOFT_RESET;
+		writel(val, &phy->regs->p1ctl);
+		writel(val & ~P1CTL_SOFT_RESET, &phy->regs->p1ctl);
+		/* Reset needs to be asserted for 2ms */
+		mdelay(2);
+		writel(val | P1CTL_SOFT_RESET, &phy->regs->p1ctl);
+	} else {
+		val &= ~(OTGCTL_PRST_N_SW | OTGCTL_HRESET_N);
+		writel(val, &phy->regs->ctrl);
+	}
+}
+
+static int bcm_kona_usb_phy_power_on(struct phy *gphy)
+{
+	struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+	bcm_kona_usb_phy_power(phy, 1);
+
+	return 0;
+}
+
+static int bcm_kona_usb_phy_power_off(struct phy *gphy)
+{
+	struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+	bcm_kona_usb_phy_power(phy, 0);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= bcm_kona_usb_phy_power_on,
+	.power_off	= bcm_kona_usb_phy_power_off,
+	.owner = THIS_MODULE,
+};
+
+static int bcm_kona_usb2_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct bcm_kona_usb *phy;
+	struct resource *res;
+	struct phy *gphy;
+	struct phy_provider *phy_provider;
+
+	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+	if (!phy)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	phy->regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(phy->regs))
+		return PTR_ERR(phy->regs);
+
+	platform_set_drvdata(pdev, phy);
+
+	phy_provider = devm_of_phy_provider_register(dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	gphy = devm_phy_create(dev, &ops, NULL);
+	if (IS_ERR(gphy))
+		return PTR_ERR(gphy);
+
+	/* The Kona PHY supports an 8-bit wide UTMI interface */
+	phy_set_bus_width(gphy, 8);
+
+	phy_set_drvdata(gphy, phy);
+
+	return 0;
+}
+
+static const struct of_device_id bcm_kona_usb2_dt_ids[] = {
+	{ .compatible = "brcm,kona-usb2-phy" },
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, bcm_kona_usb2_dt_ids);
+
+static struct platform_driver bcm_kona_usb2_driver = {
+	.probe		= bcm_kona_usb2_probe,
+	.driver		= {
+		.name	= "bcm-kona-usb2",
+		.owner	= THIS_MODULE,
+		.of_match_table = bcm_kona_usb2_dt_ids,
+	},
+};
+
+module_platform_driver(bcm_kona_usb2_driver);
+
+MODULE_ALIAS("platform:bcm-kona-usb2");
+MODULE_AUTHOR("Matt Porter");
+MODULE_DESCRIPTION("BCM Kona USB 2.0 PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.4

[PATCH v2 9/9] ARM: dts: add usb udc support to bcm281xx

[Matt Porter]

Adds USB OTG/PHY and clock support to BCM281xx and enables
UDC support on the bcm11351-brt and bcm28155-ap boards.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
---
 arch/arm/boot/dts/bcm11351-brt.dts |  6 ++++++
 arch/arm/boot/dts/bcm11351.dtsi    | 18 ++++++++++++++++++
 arch/arm/boot/dts/bcm28155-ap.dts  |  8 ++++++++
 3 files changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
index 9d36eb4..047c635 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -43,5 +43,11 @@
 		status = "okay";
 	};
 
+	usbotg@3f120000 {
+		status = "okay";
+	};
 
+	usbphy@3f130000 {
+		status = "okay";
+	};
 };
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 0755f43..247f9fd 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -284,4 +284,22 @@
 			#clock-cells = <0>;
 		};
 	};
+
+	usbotg: usbotg@3f120000 {
+		compatible = "snps,dwc2";
+		reg = <0x3f120000 0x10000>;
+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&usb_otg_ahb_clk>;
+		clock-names = "otg";
+		phys = <&usbphy>;
+		phy-names = "usb2-phy";
+		status = "disabled";
+	};
+
+	usbphy: usbphy@3f130000 {
+		compatible = "brcm,kona-usb2-phy";
+		reg = <0x3f130000 0x28>;
+		#phy-cells = <0>;
+		status = "disabled";
+	};
 };
diff --git a/arch/arm/boot/dts/bcm28155-ap.dts b/arch/arm/boot/dts/bcm28155-ap.dts
index bc4e62c..8347d1b 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -62,4 +62,12 @@
 		max-frequency = <48000000>;
 		status = "okay";
 	};
+
+	usbotg@3f120000 {
+		status = "okay";
+	};
+
+	usbphy@3f130000 {
+		status = "okay";
+	};
 };
-- 
1.8.4

[PATCH v2 9/9] ARM: dts: add usb udc support to bcm281xx

[Matt Porter]

Adds USB OTG/PHY and clock support to BCM281xx and enables
UDC support on the bcm11351-brt and bcm28155-ap boards.

Signed-off-by: Matt Porter <matt.porter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
---
 arch/arm/boot/dts/bcm11351-brt.dts |  6 ++++++
 arch/arm/boot/dts/bcm11351.dtsi    | 18 ++++++++++++++++++
 arch/arm/boot/dts/bcm28155-ap.dts  |  8 ++++++++
 3 files changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
index 9d36eb4..047c635 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -43,5 +43,11 @@
 		status = "okay";
 	};
 
+	usbotg at 3f120000 {
+		status = "okay";
+	};
 
+	usbphy at 3f130000 {
+		status = "okay";
+	};
 };
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 0755f43..247f9fd 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -284,4 +284,22 @@
 			#clock-cells = <0>;
 		};
 	};
+
+	usbotg: usbotg at 3f120000 {
+		compatible = "snps,dwc2";
+		reg = <0x3f120000 0x10000>;
+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&usb_otg_ahb_clk>;
+		clock-names = "otg";
+		phys = <&usbphy>;
+		phy-names = "usb2-phy";
+		status = "disabled";
+	};
+
+	usbphy: usbphy at 3f130000 {
+		compatible = "brcm,kona-usb2-phy";
+		reg = <0x3f130000 0x28>;
+		#phy-cells = <0>;
+		status = "disabled";
+	};
 };
diff --git a/arch/arm/boot/dts/bcm28155-ap.dts b/arch/arm/boot/dts/bcm28155-ap.dts
index bc4e62c..8347d1b 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -62,4 +62,12 @@
 		max-frequency = <48000000>;
 		status = "okay";
 	};
+
+	usbotg at 3f120000 {
+		status = "okay";
+	};
+
+	usbphy at 3f130000 {
+		status = "okay";
+	};
 };
-- 
1.8.4

Re: [PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Arend van Spriel]

On 11/01/2013 08:45 PM, Matt Porter wrote:
> Add a binding that describes the Broadcom Kona USB2 PHY found
> on the BCM281xx family of SoCs.
>
> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> ---
>   .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> new file mode 100644
> index 0000000..db309e2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> @@ -0,0 +1,15 @@
> +BROADCOM KONA USB2 PHY
> +
> +Required properties:
> + - compatible: brcm,kona-usb2-phy
> + - regs: offset and length of the PHY registers
> + - #phy-cells: must be 0
> +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> +
> +Example:
> +
> +	usbphy: usbphy@3f130000 {
> +		compatible = "brcm,kona-usb2-phy";
> +		reg = <0x3f130000 0x28>;

I expect 'regs' iso 'reg' in this example.

Regards,
Arend

> +		#phy-cells = <0>;
> +	};
>

[PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Arend van Spriel]

On 11/01/2013 08:45 PM, Matt Porter wrote:
> Add a binding that describes the Broadcom Kona USB2 PHY found
> on the BCM281xx family of SoCs.
>
> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> ---
>   .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> new file mode 100644
> index 0000000..db309e2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> @@ -0,0 +1,15 @@
> +BROADCOM KONA USB2 PHY
> +
> +Required properties:
> + - compatible: brcm,kona-usb2-phy
> + - regs: offset and length of the PHY registers
> + - #phy-cells: must be 0
> +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> +
> +Example:
> +
> +	usbphy: usbphy at 3f130000 {
> +		compatible = "brcm,kona-usb2-phy";
> +		reg = <0x3f130000 0x28>;

I expect 'regs' iso 'reg' in this example.

Regards,
Arend

> +		#phy-cells = <0>;
> +	};
>

Re: [PATCH v2 9/9] ARM: dts: add usb udc support to bcm281xx

[Sergei Shtylyov]

Hello.

On 11/01/2013 10:45 PM, Matt Porter wrote:

> Adds USB OTG/PHY and clock support to BCM281xx and enables
> UDC support on the bcm11351-brt and bcm28155-ap boards.

> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> ---
>   arch/arm/boot/dts/bcm11351-brt.dts |  6 ++++++
>   arch/arm/boot/dts/bcm11351.dtsi    | 18 ++++++++++++++++++
>   arch/arm/boot/dts/bcm28155-ap.dts  |  8 ++++++++
>   3 files changed, 32 insertions(+)

[...]
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 0755f43..247f9fd 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -284,4 +284,22 @@
>   			#clock-cells = <0>;
>   		};
>   	};
> +
> +	usbotg: usbotg@3f120000 {

    According to ePAPR spec [1], the node name should be "usb@3f120000".


> +		compatible = "snps,dwc2";
> +		reg = <0x3f120000 0x10000>;
> +		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&usb_otg_ahb_clk>;
> +		clock-names = "otg";
> +		phys = <&usbphy>;
> +		phy-names = "usb2-phy";
> +		status = "disabled";
> +	};
> +
> +	usbphy: usbphy@3f130000 {

    This one should probably be named "usb-phy@3f130000", just like 
"ethernet-phy" from the ePAPR spec.

> +		compatible = "brcm,kona-usb2-phy";
> +		reg = <0x3f130000 0x28>;
> +		#phy-cells = <0>;
> +		status = "disabled";
> +	};
>   };

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

Re: [PATCH v2 9/9] ARM: dts: add usb udc support to bcm281xx

[Sergei Shtylyov]

Hello.

On 11/01/2013 10:45 PM, Matt Porter wrote:

> Adds USB OTG/PHY and clock support to BCM281xx and enables
> UDC support on the bcm11351-brt and bcm28155-ap boards.

> Signed-off-by: Matt Porter <matt.porter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Markus Mayer <markus.mayer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Tim Kryger <tim.kryger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>   arch/arm/boot/dts/bcm11351-brt.dts |  6 ++++++
>   arch/arm/boot/dts/bcm11351.dtsi    | 18 ++++++++++++++++++
>   arch/arm/boot/dts/bcm28155-ap.dts  |  8 ++++++++
>   3 files changed, 32 insertions(+)

[...]
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 0755f43..247f9fd 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -284,4 +284,22 @@
>   			#clock-cells = <0>;
>   		};
>   	};
> +
> +	usbotg: usbotg@3f120000 {

    According to ePAPR spec [1], the node name should be "usb@3f120000".


> +		compatible = "snps,dwc2";
> +		reg = <0x3f120000 0x10000>;
> +		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&usb_otg_ahb_clk>;
> +		clock-names = "otg";
> +		phys = <&usbphy>;
> +		phy-names = "usb2-phy";
> +		status = "disabled";
> +	};
> +
> +	usbphy: usbphy@3f130000 {

    This one should probably be named "usb-phy@3f130000", just like 
"ethernet-phy" from the ePAPR spec.

> +		compatible = "brcm,kona-usb2-phy";
> +		reg = <0x3f130000 0x28>;
> +		#phy-cells = <0>;
> +		status = "disabled";
> +	};
>   };

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 9/9] ARM: dts: add usb udc support to bcm281xx

[Sergei Shtylyov]

Hello.

On 11/01/2013 10:45 PM, Matt Porter wrote:

> Adds USB OTG/PHY and clock support to BCM281xx and enables
> UDC support on the bcm11351-brt and bcm28155-ap boards.

> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> ---
>   arch/arm/boot/dts/bcm11351-brt.dts |  6 ++++++
>   arch/arm/boot/dts/bcm11351.dtsi    | 18 ++++++++++++++++++
>   arch/arm/boot/dts/bcm28155-ap.dts  |  8 ++++++++
>   3 files changed, 32 insertions(+)

[...]
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 0755f43..247f9fd 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -284,4 +284,22 @@
>   			#clock-cells = <0>;
>   		};
>   	};
> +
> +	usbotg: usbotg at 3f120000 {

    According to ePAPR spec [1], the node name should be "usb at 3f120000".


> +		compatible = "snps,dwc2";
> +		reg = <0x3f120000 0x10000>;
> +		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&usb_otg_ahb_clk>;
> +		clock-names = "otg";
> +		phys = <&usbphy>;
> +		phy-names = "usb2-phy";
> +		status = "disabled";
> +	};
> +
> +	usbphy: usbphy at 3f130000 {

    This one should probably be named "usb-phy at 3f130000", just like 
"ethernet-phy" from the ePAPR spec.

> +		compatible = "brcm,kona-usb2-phy";
> +		reg = <0x3f130000 0x28>;
> +		#phy-cells = <0>;
> +		status = "disabled";
> +	};
>   };

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

Re: [PATCH v2 9/9] ARM: dts: add usb udc support to bcm281xx

[Matt Porter]

On Fri, Nov 01, 2013 at 11:56:33PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/01/2013 10:45 PM, Matt Porter wrote:
> 
> >Adds USB OTG/PHY and clock support to BCM281xx and enables
> >UDC support on the bcm11351-brt and bcm28155-ap boards.
> 
> >Signed-off-by: Matt Porter <matt.porter@linaro.org>
> >Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> >Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> >---
> >  arch/arm/boot/dts/bcm11351-brt.dts |  6 ++++++
> >  arch/arm/boot/dts/bcm11351.dtsi    | 18 ++++++++++++++++++
> >  arch/arm/boot/dts/bcm28155-ap.dts  |  8 ++++++++
> >  3 files changed, 32 insertions(+)
> 
> [...]
> >diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> >index 0755f43..247f9fd 100644
> >--- a/arch/arm/boot/dts/bcm11351.dtsi
> >+++ b/arch/arm/boot/dts/bcm11351.dtsi
> >@@ -284,4 +284,22 @@
> >  			#clock-cells = <0>;
> >  		};
> >  	};
> >+
> >+	usbotg: usbotg@3f120000 {
> 
>    According to ePAPR spec [1], the node name should be "usb@3f120000".

Will address in v3.

> >+		compatible = "snps,dwc2";
> >+		reg = <0x3f120000 0x10000>;
> >+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> >+		clocks = <&usb_otg_ahb_clk>;
> >+		clock-names = "otg";
> >+		phys = <&usbphy>;
> >+		phy-names = "usb2-phy";
> >+		status = "disabled";
> >+	};
> >+
> >+	usbphy: usbphy@3f130000 {
> 
>    This one should probably be named "usb-phy@3f130000", just like
> "ethernet-phy" from the ePAPR spec.

Yes, agreed that will follow the same naming convention. I'll roll this
in v3. Thanks for the review.

-Matt

> >+		compatible = "brcm,kona-usb2-phy";
> >+		reg = <0x3f130000 0x28>;
> >+		#phy-cells = <0>;
> >+		status = "disabled";
> >+	};
> >  };
> 
> [1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
> 
> WBR, Sergei
> 

[PATCH v2 9/9] ARM: dts: add usb udc support to bcm281xx

[Matt Porter]

On Fri, Nov 01, 2013 at 11:56:33PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/01/2013 10:45 PM, Matt Porter wrote:
> 
> >Adds USB OTG/PHY and clock support to BCM281xx and enables
> >UDC support on the bcm11351-brt and bcm28155-ap boards.
> 
> >Signed-off-by: Matt Porter <matt.porter@linaro.org>
> >Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> >Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> >---
> >  arch/arm/boot/dts/bcm11351-brt.dts |  6 ++++++
> >  arch/arm/boot/dts/bcm11351.dtsi    | 18 ++++++++++++++++++
> >  arch/arm/boot/dts/bcm28155-ap.dts  |  8 ++++++++
> >  3 files changed, 32 insertions(+)
> 
> [...]
> >diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> >index 0755f43..247f9fd 100644
> >--- a/arch/arm/boot/dts/bcm11351.dtsi
> >+++ b/arch/arm/boot/dts/bcm11351.dtsi
> >@@ -284,4 +284,22 @@
> >  			#clock-cells = <0>;
> >  		};
> >  	};
> >+
> >+	usbotg: usbotg at 3f120000 {
> 
>    According to ePAPR spec [1], the node name should be "usb at 3f120000".

Will address in v3.

> >+		compatible = "snps,dwc2";
> >+		reg = <0x3f120000 0x10000>;
> >+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> >+		clocks = <&usb_otg_ahb_clk>;
> >+		clock-names = "otg";
> >+		phys = <&usbphy>;
> >+		phy-names = "usb2-phy";
> >+		status = "disabled";
> >+	};
> >+
> >+	usbphy: usbphy at 3f130000 {
> 
>    This one should probably be named "usb-phy at 3f130000", just like
> "ethernet-phy" from the ePAPR spec.

Yes, agreed that will follow the same naming convention. I'll roll this
in v3. Thanks for the review.

-Matt

> >+		compatible = "brcm,kona-usb2-phy";
> >+		reg = <0x3f130000 0x28>;
> >+		#phy-cells = <0>;
> >+		status = "disabled";
> >+	};
> >  };
> 
> [1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
> 
> WBR, Sergei
> 

Re: [PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Matt Porter]

On Fri, Nov 01, 2013 at 09:54:10PM +0100, Arend van Spriel wrote:
> On 11/01/2013 08:45 PM, Matt Porter wrote:
> >Add a binding that describes the Broadcom Kona USB2 PHY found
> >on the BCM281xx family of SoCs.
> >
> >Signed-off-by: Matt Porter <matt.porter@linaro.org>
> >---
> >  .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >
> >diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >new file mode 100644
> >index 0000000..db309e2
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >@@ -0,0 +1,15 @@
> >+BROADCOM KONA USB2 PHY
> >+
> >+Required properties:
> >+ - compatible: brcm,kona-usb2-phy
> >+ - regs: offset and length of the PHY registers
> >+ - #phy-cells: must be 0
> >+Refer to phy/phy-bindings.txt for the generic PHY binding properties
> >+
> >+Example:
> >+
> >+	usbphy: usbphy@3f130000 {
> >+		compatible = "brcm,kona-usb2-phy";
> >+		reg = <0x3f130000 0x28>;
> 
> I expect 'regs' iso 'reg' in this example.

Yes, will fix the typo in that property for v3.

Thanks,
Matt

> >+		#phy-cells = <0>;
> >+	};
> >
> 
> 

Re: [PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Matt Porter]

On Fri, Nov 01, 2013 at 09:54:10PM +0100, Arend van Spriel wrote:
> On 11/01/2013 08:45 PM, Matt Porter wrote:
> >Add a binding that describes the Broadcom Kona USB2 PHY found
> >on the BCM281xx family of SoCs.
> >
> >Signed-off-by: Matt Porter <matt.porter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >---
> >  .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >
> >diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >new file mode 100644
> >index 0000000..db309e2
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >@@ -0,0 +1,15 @@
> >+BROADCOM KONA USB2 PHY
> >+
> >+Required properties:
> >+ - compatible: brcm,kona-usb2-phy
> >+ - regs: offset and length of the PHY registers
> >+ - #phy-cells: must be 0
> >+Refer to phy/phy-bindings.txt for the generic PHY binding properties
> >+
> >+Example:
> >+
> >+	usbphy: usbphy@3f130000 {
> >+		compatible = "brcm,kona-usb2-phy";
> >+		reg = <0x3f130000 0x28>;
> 
> I expect 'regs' iso 'reg' in this example.

Yes, will fix the typo in that property for v3.

Thanks,
Matt

> >+		#phy-cells = <0>;
> >+	};
> >
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Matt Porter]

On Fri, Nov 01, 2013 at 09:54:10PM +0100, Arend van Spriel wrote:
> On 11/01/2013 08:45 PM, Matt Porter wrote:
> >Add a binding that describes the Broadcom Kona USB2 PHY found
> >on the BCM281xx family of SoCs.
> >
> >Signed-off-by: Matt Porter <matt.porter@linaro.org>
> >---
> >  .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt         | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >
> >diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >new file mode 100644
> >index 0000000..db309e2
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> >@@ -0,0 +1,15 @@
> >+BROADCOM KONA USB2 PHY
> >+
> >+Required properties:
> >+ - compatible: brcm,kona-usb2-phy
> >+ - regs: offset and length of the PHY registers
> >+ - #phy-cells: must be 0
> >+Refer to phy/phy-bindings.txt for the generic PHY binding properties
> >+
> >+Example:
> >+
> >+	usbphy: usbphy at 3f130000 {
> >+		compatible = "brcm,kona-usb2-phy";
> >+		reg = <0x3f130000 0x28>;
> 
> I expect 'regs' iso 'reg' in this example.

Yes, will fix the typo in that property for v3.

Thanks,
Matt

> >+		#phy-cells = <0>;
> >+	};
> >
> 
> 

Re: [PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support

[Tomasz Figa]

Hi Matt.

On Friday 01 of November 2013 15:45:54 Matt Porter wrote:
> Adds support for the generic PHY subsystem. Generic PHY
> support is probed and then the driver falls back to checking
> for an old style USB PHY and pdata if not found.
> 
> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> ---
>  drivers/usb/gadget/s3c-hsotg.c | 54
> ++++++++++++++++++++++++++++-------------- 1 file changed, 36
> insertions(+), 18 deletions(-)

Patches that convert the driver to generic PHY have been already posted by 
Kamil Debski, as a part of a series[1] adding generic PHY drivers for S5P 
and Exynos SoCs. After that series, there will be no need to support the 
usb_phy subsystem in this driver anymore.

[1] http://www.mail-archive.com/linux-usb@vger.kernel.org/msg31189.html

Best regards,
Tomasz

Re: [PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support

[Tomasz Figa]

Hi Matt.

On Friday 01 of November 2013 15:45:54 Matt Porter wrote:
> Adds support for the generic PHY subsystem. Generic PHY
> support is probed and then the driver falls back to checking
> for an old style USB PHY and pdata if not found.
> 
> Signed-off-by: Matt Porter <matt.porter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  drivers/usb/gadget/s3c-hsotg.c | 54
> ++++++++++++++++++++++++++++-------------- 1 file changed, 36
> insertions(+), 18 deletions(-)

Patches that convert the driver to generic PHY have been already posted by 
Kamil Debski, as a part of a series[1] adding generic PHY drivers for S5P 
and Exynos SoCs. After that series, there will be no need to support the 
usb_phy subsystem in this driver anymore.

[1] http://www.mail-archive.com/linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg31189.html

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support

[Tomasz Figa]

Hi Matt.

On Friday 01 of November 2013 15:45:54 Matt Porter wrote:
> Adds support for the generic PHY subsystem. Generic PHY
> support is probed and then the driver falls back to checking
> for an old style USB PHY and pdata if not found.
> 
> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> ---
>  drivers/usb/gadget/s3c-hsotg.c | 54
> ++++++++++++++++++++++++++++-------------- 1 file changed, 36
> insertions(+), 18 deletions(-)

Patches that convert the driver to generic PHY have been already posted by 
Kamil Debski, as a part of a series[1] adding generic PHY drivers for S5P 
and Exynos SoCs. After that series, there will be no need to support the 
usb_phy subsystem in this driver anymore.

[1] http://www.mail-archive.com/linux-usb at vger.kernel.org/msg31189.html

Best regards,
Tomasz

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Tomasz Figa]

Hi Matt,

On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> This adds a pair of APIs that allows the generic PHY subsystem to
> provide information on the PHY bus width. The PHY provider driver may
> use phy_set_bus_width() to set the bus width that the PHY supports.
> The controller driver may then use phy_get_bus_width() to fetch the
> PHY bus width in order to properly configure the controller.

I somehow does not like this. If we take this path for any further 
properties that we may need, we will end up with a lot of consumer 
specific properties stored in a PHY object having their own accessor 
functions.

Since this is just an integration detail, what about simply adding this as 
a property in device tree node of the OTG controller (and pdata if 
considering non-DT support)?

Another option would be some framework for retrieving arbitrary properties 
from the PHY, but I'm not really sure there is a need for such.

Best regards,
Tomasz

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Tomasz Figa]

Hi Matt,

On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> This adds a pair of APIs that allows the generic PHY subsystem to
> provide information on the PHY bus width. The PHY provider driver may
> use phy_set_bus_width() to set the bus width that the PHY supports.
> The controller driver may then use phy_get_bus_width() to fetch the
> PHY bus width in order to properly configure the controller.

I somehow does not like this. If we take this path for any further 
properties that we may need, we will end up with a lot of consumer 
specific properties stored in a PHY object having their own accessor 
functions.

Since this is just an integration detail, what about simply adding this as 
a property in device tree node of the OTG controller (and pdata if 
considering non-DT support)?

Another option would be some framework for retrieving arbitrary properties 
from the PHY, but I'm not really sure there is a need for such.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Tomasz Figa]

Hi Matt,

On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> This adds a pair of APIs that allows the generic PHY subsystem to
> provide information on the PHY bus width. The PHY provider driver may
> use phy_set_bus_width() to set the bus width that the PHY supports.
> The controller driver may then use phy_get_bus_width() to fetch the
> PHY bus width in order to properly configure the controller.

I somehow does not like this. If we take this path for any further 
properties that we may need, we will end up with a lot of consumer 
specific properties stored in a PHY object having their own accessor 
functions.

Since this is just an integration detail, what about simply adding this as 
a property in device tree node of the OTG controller (and pdata if 
considering non-DT support)?

Another option would be some framework for retrieving arbitrary properties 
from the PHY, but I'm not really sure there is a need for such.

Best regards,
Tomasz

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Kishon Vijay Abraham I]

Hi Tomasz,

On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> Hi Matt,
>
> On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
>> This adds a pair of APIs that allows the generic PHY subsystem to
>> provide information on the PHY bus width. The PHY provider driver may
>> use phy_set_bus_width() to set the bus width that the PHY supports.
>> The controller driver may then use phy_get_bus_width() to fetch the
>> PHY bus width in order to properly configure the controller.
>
> I somehow does not like this. If we take this path for any further
> properties that we may need, we will end up with a lot of consumer
> specific properties stored in a PHY object having their own accessor
> functions.

Only after all of us feel that a property is *generic* enough, we allow 
it to be added in the PHY object.
>
> Since this is just an integration detail, what about simply adding this as
> a property in device tree node of the OTG controller (and pdata if
> considering non-DT support)?

We already had a discussion about this and the dt maintainers suggested 
the property should be in the PHY. [1]

[1] ->  http://www.spinics.net/lists/devicetree/msg08851.html

Thanks
Kishon

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Kishon Vijay Abraham I]

Hi Tomasz,

On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> Hi Matt,
>
> On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
>> This adds a pair of APIs that allows the generic PHY subsystem to
>> provide information on the PHY bus width. The PHY provider driver may
>> use phy_set_bus_width() to set the bus width that the PHY supports.
>> The controller driver may then use phy_get_bus_width() to fetch the
>> PHY bus width in order to properly configure the controller.
>
> I somehow does not like this. If we take this path for any further
> properties that we may need, we will end up with a lot of consumer
> specific properties stored in a PHY object having their own accessor
> functions.

Only after all of us feel that a property is *generic* enough, we allow 
it to be added in the PHY object.
>
> Since this is just an integration detail, what about simply adding this as
> a property in device tree node of the OTG controller (and pdata if
> considering non-DT support)?

We already had a discussion about this and the dt maintainers suggested 
the property should be in the PHY. [1]

[1] ->  http://www.spinics.net/lists/devicetree/msg08851.html

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Kishon Vijay Abraham I]

Hi Tomasz,

On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> Hi Matt,
>
> On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
>> This adds a pair of APIs that allows the generic PHY subsystem to
>> provide information on the PHY bus width. The PHY provider driver may
>> use phy_set_bus_width() to set the bus width that the PHY supports.
>> The controller driver may then use phy_get_bus_width() to fetch the
>> PHY bus width in order to properly configure the controller.
>
> I somehow does not like this. If we take this path for any further
> properties that we may need, we will end up with a lot of consumer
> specific properties stored in a PHY object having their own accessor
> functions.

Only after all of us feel that a property is *generic* enough, we allow 
it to be added in the PHY object.
>
> Since this is just an integration detail, what about simply adding this as
> a property in device tree node of the OTG controller (and pdata if
> considering non-DT support)?

We already had a discussion about this and the dt maintainers suggested 
the property should be in the PHY. [1]

[1] ->  http://www.spinics.net/lists/devicetree/msg08851.html

Thanks
Kishon

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Matt Porter]

On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> Hi Tomasz,
> 
> On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> >Hi Matt,
> >
> >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> >>This adds a pair of APIs that allows the generic PHY subsystem to
> >>provide information on the PHY bus width. The PHY provider driver may
> >>use phy_set_bus_width() to set the bus width that the PHY supports.
> >>The controller driver may then use phy_get_bus_width() to fetch the
> >>PHY bus width in order to properly configure the controller.
> >
> >I somehow does not like this. If we take this path for any further
> >properties that we may need, we will end up with a lot of consumer
> >specific properties stored in a PHY object having their own accessor
> >functions.
> 
> Only after all of us feel that a property is *generic* enough, we
> allow it to be added in the PHY object.

I also want to note that this was discussed over in another thread [2]
where you did consider my rough stab at a more generic attribute
accessor. It was definitely my first reaction as the way to do it like
Tomasz has said. The specific accessors are more readable to me besides
the justification you mention above.

[2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html

-Matt

> >Since this is just an integration detail, what about simply adding this as
> >a property in device tree node of the OTG controller (and pdata if
> >considering non-DT support)?
> 
> We already had a discussion about this and the dt maintainers
> suggested the property should be in the PHY. [1]
> 
> [1] ->  http://www.spinics.net/lists/devicetree/msg08851.html
> 
> Thanks
> Kishon

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Matt Porter]

On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> Hi Tomasz,
> 
> On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> >Hi Matt,
> >
> >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> >>This adds a pair of APIs that allows the generic PHY subsystem to
> >>provide information on the PHY bus width. The PHY provider driver may
> >>use phy_set_bus_width() to set the bus width that the PHY supports.
> >>The controller driver may then use phy_get_bus_width() to fetch the
> >>PHY bus width in order to properly configure the controller.
> >
> >I somehow does not like this. If we take this path for any further
> >properties that we may need, we will end up with a lot of consumer
> >specific properties stored in a PHY object having their own accessor
> >functions.
> 
> Only after all of us feel that a property is *generic* enough, we
> allow it to be added in the PHY object.

I also want to note that this was discussed over in another thread [2]
where you did consider my rough stab at a more generic attribute
accessor. It was definitely my first reaction as the way to do it like
Tomasz has said. The specific accessors are more readable to me besides
the justification you mention above.

[2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html

-Matt

> >Since this is just an integration detail, what about simply adding this as
> >a property in device tree node of the OTG controller (and pdata if
> >considering non-DT support)?
> 
> We already had a discussion about this and the dt maintainers
> suggested the property should be in the PHY. [1]
> 
> [1] ->  http://www.spinics.net/lists/devicetree/msg08851.html
> 
> Thanks
> Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Matt Porter]

On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> Hi Tomasz,
> 
> On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> >Hi Matt,
> >
> >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> >>This adds a pair of APIs that allows the generic PHY subsystem to
> >>provide information on the PHY bus width. The PHY provider driver may
> >>use phy_set_bus_width() to set the bus width that the PHY supports.
> >>The controller driver may then use phy_get_bus_width() to fetch the
> >>PHY bus width in order to properly configure the controller.
> >
> >I somehow does not like this. If we take this path for any further
> >properties that we may need, we will end up with a lot of consumer
> >specific properties stored in a PHY object having their own accessor
> >functions.
> 
> Only after all of us feel that a property is *generic* enough, we
> allow it to be added in the PHY object.

I also want to note that this was discussed over in another thread [2]
where you did consider my rough stab at a more generic attribute
accessor. It was definitely my first reaction as the way to do it like
Tomasz has said. The specific accessors are more readable to me besides
the justification you mention above.

[2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html

-Matt

> >Since this is just an integration detail, what about simply adding this as
> >a property in device tree node of the OTG controller (and pdata if
> >considering non-DT support)?
> 
> We already had a discussion about this and the dt maintainers
> suggested the property should be in the PHY. [1]
> 
> [1] ->  http://www.spinics.net/lists/devicetree/msg08851.html
> 
> Thanks
> Kishon

Re: [PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support

[Matt Porter]

On Sat, Nov 02, 2013 at 02:09:21PM +0100, Tomasz Figa wrote:
> Hi Matt.
> 
> On Friday 01 of November 2013 15:45:54 Matt Porter wrote:
> > Adds support for the generic PHY subsystem. Generic PHY
> > support is probed and then the driver falls back to checking
> > for an old style USB PHY and pdata if not found.
> > 
> > Signed-off-by: Matt Porter <matt.porter@linaro.org>
> > ---
> >  drivers/usb/gadget/s3c-hsotg.c | 54
> > ++++++++++++++++++++++++++++-------------- 1 file changed, 36
> > insertions(+), 18 deletions(-)
> 
> Patches that convert the driver to generic PHY have been already posted by 
> Kamil Debski, as a part of a series[1] adding generic PHY drivers for S5P 
> and Exynos SoCs. After that series, there will be no need to support the 
> usb_phy subsystem in this driver anymore.
> 
> [1] http://www.mail-archive.com/linux-usb@vger.kernel.org/msg31189.html

Very nice...embarassing I somehow missed that last week. I deliberately
avoided removing that USB PHY support simply because I wanted to leave
the Samsung phy conversions to somebody else with hardware to test. ;)

I'll drop this patch and rebase on top of that series...thanks for
pointing it out.

-Matt

[PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support

[Matt Porter]

On Sat, Nov 02, 2013 at 02:09:21PM +0100, Tomasz Figa wrote:
> Hi Matt.
> 
> On Friday 01 of November 2013 15:45:54 Matt Porter wrote:
> > Adds support for the generic PHY subsystem. Generic PHY
> > support is probed and then the driver falls back to checking
> > for an old style USB PHY and pdata if not found.
> > 
> > Signed-off-by: Matt Porter <matt.porter@linaro.org>
> > ---
> >  drivers/usb/gadget/s3c-hsotg.c | 54
> > ++++++++++++++++++++++++++++-------------- 1 file changed, 36
> > insertions(+), 18 deletions(-)
> 
> Patches that convert the driver to generic PHY have been already posted by 
> Kamil Debski, as a part of a series[1] adding generic PHY drivers for S5P 
> and Exynos SoCs. After that series, there will be no need to support the 
> usb_phy subsystem in this driver anymore.
> 
> [1] http://www.mail-archive.com/linux-usb at vger.kernel.org/msg31189.html

Very nice...embarassing I somehow missed that last week. I deliberately
avoided removing that USB PHY support simply because I wanted to leave
the Samsung phy conversions to somebody else with hardware to test. ;)

I'll drop this patch and rebase on top of that series...thanks for
pointing it out.

-Matt

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Tomasz Figa]

On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> > Hi Tomasz,
> > 
> > On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> > >Hi Matt,
> > >
> > >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> > >>This adds a pair of APIs that allows the generic PHY subsystem to
> > >>provide information on the PHY bus width. The PHY provider driver
> > >>may
> > >>use phy_set_bus_width() to set the bus width that the PHY supports.
> > >>The controller driver may then use phy_get_bus_width() to fetch the
> > >>PHY bus width in order to properly configure the controller.
> > >
> > >I somehow does not like this. If we take this path for any further
> > >properties that we may need, we will end up with a lot of consumer
> > >specific properties stored in a PHY object having their own accessor
> > >functions.
> > 
> > Only after all of us feel that a property is *generic* enough, we
> > allow it to be added in the PHY object.
> 
> I also want to note that this was discussed over in another thread [2]
> where you did consider my rough stab at a more generic attribute
> accessor. It was definitely my first reaction as the way to do it like
> Tomasz has said. The specific accessors are more readable to me besides
> the justification you mention above.
> 
> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html

Personally I like that version much better, but still it would need to be 
polished a bit.

How I imagine such interface to be implemented:

phy.h:

struct phy {
	// ...
	const struct phy_attrs *attrs;
	// ...
};

static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
	return phy->attrs;
};

phy driver:

static const struct phy_attrs my_phy_attrs = {
	// ...
};

static int my_phy_probe(...)
{
	// ...
	phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
	// ...
}

phy consumer:

	// ...
	const struct phy_attrs *phy_attrs;

	phy_attrs = phy_get_attrs(phy);
	// ...

Why I think it is better than what I've seen in this and previous instance 
of this thread? (in random order)
 a) Only the PHY driver can set the attrs.
 b) PHY consumer has access only to a const pointer.
 c) PHY attributes can be placed in a static struct inside a driver file, 
without the need to call any functions to set particular attributes.
 d) Can be extended with more attributes easily.

Best regards,
Tomasz

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Tomasz Figa]

On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> > Hi Tomasz,
> > 
> > On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> > >Hi Matt,
> > >
> > >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> > >>This adds a pair of APIs that allows the generic PHY subsystem to
> > >>provide information on the PHY bus width. The PHY provider driver
> > >>may
> > >>use phy_set_bus_width() to set the bus width that the PHY supports.
> > >>The controller driver may then use phy_get_bus_width() to fetch the
> > >>PHY bus width in order to properly configure the controller.
> > >
> > >I somehow does not like this. If we take this path for any further
> > >properties that we may need, we will end up with a lot of consumer
> > >specific properties stored in a PHY object having their own accessor
> > >functions.
> > 
> > Only after all of us feel that a property is *generic* enough, we
> > allow it to be added in the PHY object.
> 
> I also want to note that this was discussed over in another thread [2]
> where you did consider my rough stab at a more generic attribute
> accessor. It was definitely my first reaction as the way to do it like
> Tomasz has said. The specific accessors are more readable to me besides
> the justification you mention above.
> 
> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html

Personally I like that version much better, but still it would need to be 
polished a bit.

How I imagine such interface to be implemented:

phy.h:

struct phy {
	// ...
	const struct phy_attrs *attrs;
	// ...
};

static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
	return phy->attrs;
};

phy driver:

static const struct phy_attrs my_phy_attrs = {
	// ...
};

static int my_phy_probe(...)
{
	// ...
	phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
	// ...
}

phy consumer:

	// ...
	const struct phy_attrs *phy_attrs;

	phy_attrs = phy_get_attrs(phy);
	// ...

Why I think it is better than what I've seen in this and previous instance 
of this thread? (in random order)
 a) Only the PHY driver can set the attrs.
 b) PHY consumer has access only to a const pointer.
 c) PHY attributes can be placed in a static struct inside a driver file, 
without the need to call any functions to set particular attributes.
 d) Can be extended with more attributes easily.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Tomasz Figa]

On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> > Hi Tomasz,
> > 
> > On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> > >Hi Matt,
> > >
> > >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> > >>This adds a pair of APIs that allows the generic PHY subsystem to
> > >>provide information on the PHY bus width. The PHY provider driver
> > >>may
> > >>use phy_set_bus_width() to set the bus width that the PHY supports.
> > >>The controller driver may then use phy_get_bus_width() to fetch the
> > >>PHY bus width in order to properly configure the controller.
> > >
> > >I somehow does not like this. If we take this path for any further
> > >properties that we may need, we will end up with a lot of consumer
> > >specific properties stored in a PHY object having their own accessor
> > >functions.
> > 
> > Only after all of us feel that a property is *generic* enough, we
> > allow it to be added in the PHY object.
> 
> I also want to note that this was discussed over in another thread [2]
> where you did consider my rough stab at a more generic attribute
> accessor. It was definitely my first reaction as the way to do it like
> Tomasz has said. The specific accessors are more readable to me besides
> the justification you mention above.
> 
> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html

Personally I like that version much better, but still it would need to be 
polished a bit.

How I imagine such interface to be implemented:

phy.h:

struct phy {
	// ...
	const struct phy_attrs *attrs;
	// ...
};

static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
	return phy->attrs;
};

phy driver:

static const struct phy_attrs my_phy_attrs = {
	// ...
};

static int my_phy_probe(...)
{
	// ...
	phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
	// ...
}

phy consumer:

	// ...
	const struct phy_attrs *phy_attrs;

	phy_attrs = phy_get_attrs(phy);
	// ...

Why I think it is better than what I've seen in this and previous instance 
of this thread? (in random order)
 a) Only the PHY driver can set the attrs.
 b) PHY consumer has access only to a const pointer.
 c) PHY attributes can be placed in a static struct inside a driver file, 
without the need to call any functions to set particular attributes.
 d) Can be extended with more attributes easily.

Best regards,
Tomasz

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Kishon Vijay Abraham I]

Hi,

On Saturday 02 November 2013 11:28 PM, Tomasz Figa wrote:
> On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
>> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
>>> Hi Tomasz,
>>>
>>> On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
>>>> Hi Matt,
>>>>
>>>> On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
>>>>> This adds a pair of APIs that allows the generic PHY subsystem to
>>>>> provide information on the PHY bus width. The PHY provider driver
>>>>> may
>>>>> use phy_set_bus_width() to set the bus width that the PHY supports.
>>>>> The controller driver may then use phy_get_bus_width() to fetch the
>>>>> PHY bus width in order to properly configure the controller.
>>>>
>>>> I somehow does not like this. If we take this path for any further
>>>> properties that we may need, we will end up with a lot of consumer
>>>> specific properties stored in a PHY object having their own accessor
>>>> functions.
>>>
>>> Only after all of us feel that a property is *generic* enough, we
>>> allow it to be added in the PHY object.
>>
>> I also want to note that this was discussed over in another thread [2]
>> where you did consider my rough stab at a more generic attribute
>> accessor. It was definitely my first reaction as the way to do it like
>> Tomasz has said. The specific accessors are more readable to me besides
>> the justification you mention above.
>>
>> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html
>
> Personally I like that version much better, but still it would need to be
> polished a bit.
>
> How I imagine such interface to be implemented:
>
> phy.h:
>
> struct phy {
> 	// ...
> 	const struct phy_attrs *attrs;
> 	// ...
> };
>
> static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
> 	return phy->attrs;
> };

API's like get_attrs is loosely defined. I'd prefer to have fully 
defined APIs. There might be other attributes which the consumer might 
not be interested in. Instead of returning the entire structure, it 
would be better if we have facilities for the consumer to request only 
the required attributes.
>
> phy driver:
>
> static const struct phy_attrs my_phy_attrs = {
> 	// ...
> };
>
> static int my_phy_probe(...)
> {
> 	// ...
> 	phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
> 	// ...
> }
>
> phy consumer:
>
> 	// ...
> 	const struct phy_attrs *phy_attrs;
>
> 	phy_attrs = phy_get_attrs(phy);
> 	// ...
>
> Why I think it is better than what I've seen in this and previous instance
> of this thread? (in random order)
>   a) Only the PHY driver can set the attrs.
>   b) PHY consumer has access only to a const pointer.
>   c) PHY attributes can be placed in a static struct inside a driver file,
> without the need to call any functions to set particular attributes.

Agree with all your points for setting the attributes apart from the 
fact that we won't be able to add any validation criteria for the 
attributes while setting it if needed and also there won't be symmetric 
APIs for getting and setting the attributes..

Cheers
Kishon

Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Kishon Vijay Abraham I]

Hi,

On Saturday 02 November 2013 11:28 PM, Tomasz Figa wrote:
> On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
>> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
>>> Hi Tomasz,
>>>
>>> On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
>>>> Hi Matt,
>>>>
>>>> On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
>>>>> This adds a pair of APIs that allows the generic PHY subsystem to
>>>>> provide information on the PHY bus width. The PHY provider driver
>>>>> may
>>>>> use phy_set_bus_width() to set the bus width that the PHY supports.
>>>>> The controller driver may then use phy_get_bus_width() to fetch the
>>>>> PHY bus width in order to properly configure the controller.
>>>>
>>>> I somehow does not like this. If we take this path for any further
>>>> properties that we may need, we will end up with a lot of consumer
>>>> specific properties stored in a PHY object having their own accessor
>>>> functions.
>>>
>>> Only after all of us feel that a property is *generic* enough, we
>>> allow it to be added in the PHY object.
>>
>> I also want to note that this was discussed over in another thread [2]
>> where you did consider my rough stab at a more generic attribute
>> accessor. It was definitely my first reaction as the way to do it like
>> Tomasz has said. The specific accessors are more readable to me besides
>> the justification you mention above.
>>
>> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html
>
> Personally I like that version much better, but still it would need to be
> polished a bit.
>
> How I imagine such interface to be implemented:
>
> phy.h:
>
> struct phy {
> 	// ...
> 	const struct phy_attrs *attrs;
> 	// ...
> };
>
> static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
> 	return phy->attrs;
> };

API's like get_attrs is loosely defined. I'd prefer to have fully 
defined APIs. There might be other attributes which the consumer might 
not be interested in. Instead of returning the entire structure, it 
would be better if we have facilities for the consumer to request only 
the required attributes.
>
> phy driver:
>
> static const struct phy_attrs my_phy_attrs = {
> 	// ...
> };
>
> static int my_phy_probe(...)
> {
> 	// ...
> 	phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
> 	// ...
> }
>
> phy consumer:
>
> 	// ...
> 	const struct phy_attrs *phy_attrs;
>
> 	phy_attrs = phy_get_attrs(phy);
> 	// ...
>
> Why I think it is better than what I've seen in this and previous instance
> of this thread? (in random order)
>   a) Only the PHY driver can set the attrs.
>   b) PHY consumer has access only to a const pointer.
>   c) PHY attributes can be placed in a static struct inside a driver file,
> without the need to call any functions to set particular attributes.

Agree with all your points for setting the attributes apart from the 
fact that we won't be able to add any validation criteria for the 
attributes while setting it if needed and also there won't be symmetric 
APIs for getting and setting the attributes..

Cheers
Kishon

[PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Kishon Vijay Abraham I]

Hi,

On Saturday 02 November 2013 11:28 PM, Tomasz Figa wrote:
> On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
>> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
>>> Hi Tomasz,
>>>
>>> On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
>>>> Hi Matt,
>>>>
>>>> On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
>>>>> This adds a pair of APIs that allows the generic PHY subsystem to
>>>>> provide information on the PHY bus width. The PHY provider driver
>>>>> may
>>>>> use phy_set_bus_width() to set the bus width that the PHY supports.
>>>>> The controller driver may then use phy_get_bus_width() to fetch the
>>>>> PHY bus width in order to properly configure the controller.
>>>>
>>>> I somehow does not like this. If we take this path for any further
>>>> properties that we may need, we will end up with a lot of consumer
>>>> specific properties stored in a PHY object having their own accessor
>>>> functions.
>>>
>>> Only after all of us feel that a property is *generic* enough, we
>>> allow it to be added in the PHY object.
>>
>> I also want to note that this was discussed over in another thread [2]
>> where you did consider my rough stab at a more generic attribute
>> accessor. It was definitely my first reaction as the way to do it like
>> Tomasz has said. The specific accessors are more readable to me besides
>> the justification you mention above.
>>
>> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html
>
> Personally I like that version much better, but still it would need to be
> polished a bit.
>
> How I imagine such interface to be implemented:
>
> phy.h:
>
> struct phy {
> 	// ...
> 	const struct phy_attrs *attrs;
> 	// ...
> };
>
> static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
> 	return phy->attrs;
> };

API's like get_attrs is loosely defined. I'd prefer to have fully 
defined APIs. There might be other attributes which the consumer might 
not be interested in. Instead of returning the entire structure, it 
would be better if we have facilities for the consumer to request only 
the required attributes.
>
> phy driver:
>
> static const struct phy_attrs my_phy_attrs = {
> 	// ...
> };
>
> static int my_phy_probe(...)
> {
> 	// ...
> 	phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
> 	// ...
> }
>
> phy consumer:
>
> 	// ...
> 	const struct phy_attrs *phy_attrs;
>
> 	phy_attrs = phy_get_attrs(phy);
> 	// ...
>
> Why I think it is better than what I've seen in this and previous instance
> of this thread? (in random order)
>   a) Only the PHY driver can set the attrs.
>   b) PHY consumer has access only to a const pointer.
>   c) PHY attributes can be placed in a static struct inside a driver file,
> without the need to call any functions to set particular attributes.

Agree with all your points for setting the attributes apart from the 
fact that we won't be able to add any validation criteria for the 
attributes while setting it if needed and also there won't be symmetric 
APIs for getting and setting the attributes..

Cheers
Kishon

Re: [PATCH v2 8/9] phy: add Broadcom Kona USB2 PHY driver

[Kishon Vijay Abraham I]

Hi,

On Saturday 02 November 2013 01:15 AM, Matt Porter wrote:
> Add a driver for the internal Broadcom Kona USB 2.0 PHY found
> on the BCM281xx family of SoCs.
>
> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> ---
>   drivers/phy/Kconfig             |   6 ++
>   drivers/phy/Makefile            |   2 +
>   drivers/phy/phy-bcm-kona-usb2.c | 161 ++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 169 insertions(+)
>   create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 349bef2..cedada5 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,4 +15,10 @@ config GENERIC_PHY
>   	  phy users can obtain reference to the PHY. All the users of this
>   	  framework should select this config.
>
> +config BCM_KONA_USB2_PHY
> +	tristate "Broadcom Kona USB2 PHY Driver"
> +	depends on GENERIC_PHY
> +	help
> +	  Enable this to support the Broadcom Kona USB 2.0 PHY.
> +
>   endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9e9560f..ce83a14 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -3,3 +3,5 @@
>   #
>
>   obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
> +
> +obj-$(CONFIG_BCM_KONA_USB2_PHY)	+= phy-bcm-kona-usb2.o
> diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
> new file mode 100644
> index 0000000..1beea7f
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-kona-usb2.c
> @@ -0,0 +1,161 @@
> +/*
> + * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
> + *
> + * Copyright (C) 2013 Linaro Limited
> + * Matt Porter <matt.porter@linaro.org>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/delay.h>
> +#include <linux/platform_device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/phy/phy.h>
> +
> +#define OTGCTL_OTGSTAT2		(1 << 31)
> +#define OTGCTL_OTGSTAT1		(1 << 30)
> +#define OTGCTL_PRST_N_SW	(1 << 11)
> +#define OTGCTL_HRESET_N		(1 << 10)
> +#define OTGCTL_UTMI_LINE_STATE1	(1 << 9)
> +#define OTGCTL_UTMI_LINE_STATE0	(1 << 8)
> +
> +#define P1CTL_SOFT_RESET	(1 << 1)
> +#define P1CTL_NON_DRIVING	(1 << 0)
> +
> +struct bcm_kona_usb_phy_regs {
> +	u32 ctrl;
> +	u32 cfg;
> +	u32 p1ctl;
> +	u32 status;
> +	u32 bc_cfg;
> +	u32 tp_in;
> +	u32 tp_out;
> +	u32 phy_ctrl;
> +	u32 usbreg;
> +	u32 usbproben;
> +};

I would prefer to have constant macros for register offset unless you 
have a good reason to do otherwise.
> +
> +struct bcm_kona_usb {
> +	struct bcm_kona_usb_phy_regs *regs;
> +};
> +
> +static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
> +{
> +	u32 val;
> +
> +	val = readl(&phy->regs->ctrl);
> +	if (on) {
> +		/* Configure and power PHY */
> +		val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
> +			 OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
> +		val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
> +		writel(val, &phy->regs->ctrl);
> +
> +		/* Soft reset PHY */
> +		val = readl(&phy->regs->p1ctl);
> +		val &= ~P1CTL_NON_DRIVING;
> +		val |= P1CTL_SOFT_RESET;
> +		writel(val, &phy->regs->p1ctl);
> +		writel(val & ~P1CTL_SOFT_RESET, &phy->regs->p1ctl);
> +		/* Reset needs to be asserted for 2ms */
> +		mdelay(2);
> +		writel(val | P1CTL_SOFT_RESET, &phy->regs->p1ctl);

Is soft reset needed for every power-on? Shouldn't soft reset be present 
in phy_init?

Cheers
Kishon

[PATCH v2 8/9] phy: add Broadcom Kona USB2 PHY driver

[Kishon Vijay Abraham I]

Hi,

On Saturday 02 November 2013 01:15 AM, Matt Porter wrote:
> Add a driver for the internal Broadcom Kona USB 2.0 PHY found
> on the BCM281xx family of SoCs.
>
> Signed-off-by: Matt Porter <matt.porter@linaro.org>
> ---
>   drivers/phy/Kconfig             |   6 ++
>   drivers/phy/Makefile            |   2 +
>   drivers/phy/phy-bcm-kona-usb2.c | 161 ++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 169 insertions(+)
>   create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 349bef2..cedada5 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,4 +15,10 @@ config GENERIC_PHY
>   	  phy users can obtain reference to the PHY. All the users of this
>   	  framework should select this config.
>
> +config BCM_KONA_USB2_PHY
> +	tristate "Broadcom Kona USB2 PHY Driver"
> +	depends on GENERIC_PHY
> +	help
> +	  Enable this to support the Broadcom Kona USB 2.0 PHY.
> +
>   endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9e9560f..ce83a14 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -3,3 +3,5 @@
>   #
>
>   obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
> +
> +obj-$(CONFIG_BCM_KONA_USB2_PHY)	+= phy-bcm-kona-usb2.o
> diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
> new file mode 100644
> index 0000000..1beea7f
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-kona-usb2.c
> @@ -0,0 +1,161 @@
> +/*
> + * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
> + *
> + * Copyright (C) 2013 Linaro Limited
> + * Matt Porter <matt.porter@linaro.org>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/delay.h>
> +#include <linux/platform_device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/phy/phy.h>
> +
> +#define OTGCTL_OTGSTAT2		(1 << 31)
> +#define OTGCTL_OTGSTAT1		(1 << 30)
> +#define OTGCTL_PRST_N_SW	(1 << 11)
> +#define OTGCTL_HRESET_N		(1 << 10)
> +#define OTGCTL_UTMI_LINE_STATE1	(1 << 9)
> +#define OTGCTL_UTMI_LINE_STATE0	(1 << 8)
> +
> +#define P1CTL_SOFT_RESET	(1 << 1)
> +#define P1CTL_NON_DRIVING	(1 << 0)
> +
> +struct bcm_kona_usb_phy_regs {
> +	u32 ctrl;
> +	u32 cfg;
> +	u32 p1ctl;
> +	u32 status;
> +	u32 bc_cfg;
> +	u32 tp_in;
> +	u32 tp_out;
> +	u32 phy_ctrl;
> +	u32 usbreg;
> +	u32 usbproben;
> +};

I would prefer to have constant macros for register offset unless you 
have a good reason to do otherwise.
> +
> +struct bcm_kona_usb {
> +	struct bcm_kona_usb_phy_regs *regs;
> +};
> +
> +static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
> +{
> +	u32 val;
> +
> +	val = readl(&phy->regs->ctrl);
> +	if (on) {
> +		/* Configure and power PHY */
> +		val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
> +			 OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
> +		val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
> +		writel(val, &phy->regs->ctrl);
> +
> +		/* Soft reset PHY */
> +		val = readl(&phy->regs->p1ctl);
> +		val &= ~P1CTL_NON_DRIVING;
> +		val |= P1CTL_SOFT_RESET;
> +		writel(val, &phy->regs->p1ctl);
> +		writel(val & ~P1CTL_SOFT_RESET, &phy->regs->p1ctl);
> +		/* Reset needs to be asserted for 2ms */
> +		mdelay(2);
> +		writel(val | P1CTL_SOFT_RESET, &phy->regs->p1ctl);

Is soft reset needed for every power-on? Shouldn't soft reset be present 
in phy_init?

Cheers
Kishon

Re: [PATCH v2 8/9] phy: add Broadcom Kona USB2 PHY driver

[Matt Porter]

On Mon, Nov 04, 2013 at 11:57:10AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Saturday 02 November 2013 01:15 AM, Matt Porter wrote:
> >Add a driver for the internal Broadcom Kona USB 2.0 PHY found
> >on the BCM281xx family of SoCs.
> >
> >Signed-off-by: Matt Porter <matt.porter@linaro.org>
> >---
> >  drivers/phy/Kconfig             |   6 ++
> >  drivers/phy/Makefile            |   2 +
> >  drivers/phy/phy-bcm-kona-usb2.c | 161 ++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 169 insertions(+)
> >  create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
> >
> >diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> >index 349bef2..cedada5 100644
> >--- a/drivers/phy/Kconfig
> >+++ b/drivers/phy/Kconfig
> >@@ -15,4 +15,10 @@ config GENERIC_PHY
> >  	  phy users can obtain reference to the PHY. All the users of this
> >  	  framework should select this config.
> >
> >+config BCM_KONA_USB2_PHY
> >+	tristate "Broadcom Kona USB2 PHY Driver"
> >+	depends on GENERIC_PHY
> >+	help
> >+	  Enable this to support the Broadcom Kona USB 2.0 PHY.
> >+
> >  endmenu
> >diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> >index 9e9560f..ce83a14 100644
> >--- a/drivers/phy/Makefile
> >+++ b/drivers/phy/Makefile
> >@@ -3,3 +3,5 @@
> >  #
> >
> >  obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
> >+
> >+obj-$(CONFIG_BCM_KONA_USB2_PHY)	+= phy-bcm-kona-usb2.o
> >diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
> >new file mode 100644
> >index 0000000..1beea7f
> >--- /dev/null
> >+++ b/drivers/phy/phy-bcm-kona-usb2.c
> >@@ -0,0 +1,161 @@
> >+/*
> >+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
> >+ *
> >+ * Copyright (C) 2013 Linaro Limited
> >+ * Matt Porter <matt.porter@linaro.org>
> >+ *
> >+ * This software is licensed under the terms of the GNU General Public
> >+ * License version 2, as published by the Free Software Foundation, and
> >+ * may be copied, distributed, and modified under those terms.
> >+ *
> >+ * This program is distributed in the hope that it will be useful,
> >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >+ * GNU General Public License for more details.
> >+ */
> >+
> >+#include <linux/module.h>
> >+#include <linux/of.h>
> >+#include <linux/delay.h>
> >+#include <linux/platform_device.h>
> >+#include <linux/err.h>
> >+#include <linux/io.h>
> >+#include <linux/clk.h>
> >+#include <linux/phy/phy.h>
> >+
> >+#define OTGCTL_OTGSTAT2		(1 << 31)
> >+#define OTGCTL_OTGSTAT1		(1 << 30)
> >+#define OTGCTL_PRST_N_SW	(1 << 11)
> >+#define OTGCTL_HRESET_N		(1 << 10)
> >+#define OTGCTL_UTMI_LINE_STATE1	(1 << 9)
> >+#define OTGCTL_UTMI_LINE_STATE0	(1 << 8)
> >+
> >+#define P1CTL_SOFT_RESET	(1 << 1)
> >+#define P1CTL_NON_DRIVING	(1 << 0)
> >+
> >+struct bcm_kona_usb_phy_regs {
> >+	u32 ctrl;
> >+	u32 cfg;
> >+	u32 p1ctl;
> >+	u32 status;
> >+	u32 bc_cfg;
> >+	u32 tp_in;
> >+	u32 tp_out;
> >+	u32 phy_ctrl;
> >+	u32 usbreg;
> >+	u32 usbproben;
> >+};
> 
> I would prefer to have constant macros for register offset unless
> you have a good reason to do otherwise.

I'll switch to constant macros in v3. It's just my personal preference
for style.

> >+
> >+struct bcm_kona_usb {
> >+	struct bcm_kona_usb_phy_regs *regs;
> >+};
> >+
> >+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
> >+{
> >+	u32 val;
> >+
> >+	val = readl(&phy->regs->ctrl);
> >+	if (on) {
> >+		/* Configure and power PHY */
> >+		val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
> >+			 OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
> >+		val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
> >+		writel(val, &phy->regs->ctrl);
> >+
> >+		/* Soft reset PHY */
> >+		val = readl(&phy->regs->p1ctl);
> >+		val &= ~P1CTL_NON_DRIVING;
> >+		val |= P1CTL_SOFT_RESET;
> >+		writel(val, &phy->regs->p1ctl);
> >+		writel(val & ~P1CTL_SOFT_RESET, &phy->regs->p1ctl);
> >+		/* Reset needs to be asserted for 2ms */
> >+		mdelay(2);
> >+		writel(val | P1CTL_SOFT_RESET, &phy->regs->p1ctl);
> 
> Is soft reset needed for every power-on? Shouldn't soft reset be
> present in phy_init?

Not needed for every power-on. Yes, I've addressed that now for v3,
thanks.

-Matt

[PATCH v2 8/9] phy: add Broadcom Kona USB2 PHY driver

[Matt Porter]

On Mon, Nov 04, 2013 at 11:57:10AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Saturday 02 November 2013 01:15 AM, Matt Porter wrote:
> >Add a driver for the internal Broadcom Kona USB 2.0 PHY found
> >on the BCM281xx family of SoCs.
> >
> >Signed-off-by: Matt Porter <matt.porter@linaro.org>
> >---
> >  drivers/phy/Kconfig             |   6 ++
> >  drivers/phy/Makefile            |   2 +
> >  drivers/phy/phy-bcm-kona-usb2.c | 161 ++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 169 insertions(+)
> >  create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
> >
> >diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> >index 349bef2..cedada5 100644
> >--- a/drivers/phy/Kconfig
> >+++ b/drivers/phy/Kconfig
> >@@ -15,4 +15,10 @@ config GENERIC_PHY
> >  	  phy users can obtain reference to the PHY. All the users of this
> >  	  framework should select this config.
> >
> >+config BCM_KONA_USB2_PHY
> >+	tristate "Broadcom Kona USB2 PHY Driver"
> >+	depends on GENERIC_PHY
> >+	help
> >+	  Enable this to support the Broadcom Kona USB 2.0 PHY.
> >+
> >  endmenu
> >diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> >index 9e9560f..ce83a14 100644
> >--- a/drivers/phy/Makefile
> >+++ b/drivers/phy/Makefile
> >@@ -3,3 +3,5 @@
> >  #
> >
> >  obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
> >+
> >+obj-$(CONFIG_BCM_KONA_USB2_PHY)	+= phy-bcm-kona-usb2.o
> >diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
> >new file mode 100644
> >index 0000000..1beea7f
> >--- /dev/null
> >+++ b/drivers/phy/phy-bcm-kona-usb2.c
> >@@ -0,0 +1,161 @@
> >+/*
> >+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
> >+ *
> >+ * Copyright (C) 2013 Linaro Limited
> >+ * Matt Porter <matt.porter@linaro.org>
> >+ *
> >+ * This software is licensed under the terms of the GNU General Public
> >+ * License version 2, as published by the Free Software Foundation, and
> >+ * may be copied, distributed, and modified under those terms.
> >+ *
> >+ * This program is distributed in the hope that it will be useful,
> >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >+ * GNU General Public License for more details.
> >+ */
> >+
> >+#include <linux/module.h>
> >+#include <linux/of.h>
> >+#include <linux/delay.h>
> >+#include <linux/platform_device.h>
> >+#include <linux/err.h>
> >+#include <linux/io.h>
> >+#include <linux/clk.h>
> >+#include <linux/phy/phy.h>
> >+
> >+#define OTGCTL_OTGSTAT2		(1 << 31)
> >+#define OTGCTL_OTGSTAT1		(1 << 30)
> >+#define OTGCTL_PRST_N_SW	(1 << 11)
> >+#define OTGCTL_HRESET_N		(1 << 10)
> >+#define OTGCTL_UTMI_LINE_STATE1	(1 << 9)
> >+#define OTGCTL_UTMI_LINE_STATE0	(1 << 8)
> >+
> >+#define P1CTL_SOFT_RESET	(1 << 1)
> >+#define P1CTL_NON_DRIVING	(1 << 0)
> >+
> >+struct bcm_kona_usb_phy_regs {
> >+	u32 ctrl;
> >+	u32 cfg;
> >+	u32 p1ctl;
> >+	u32 status;
> >+	u32 bc_cfg;
> >+	u32 tp_in;
> >+	u32 tp_out;
> >+	u32 phy_ctrl;
> >+	u32 usbreg;
> >+	u32 usbproben;
> >+};
> 
> I would prefer to have constant macros for register offset unless
> you have a good reason to do otherwise.

I'll switch to constant macros in v3. It's just my personal preference
for style.

> >+
> >+struct bcm_kona_usb {
> >+	struct bcm_kona_usb_phy_regs *regs;
> >+};
> >+
> >+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
> >+{
> >+	u32 val;
> >+
> >+	val = readl(&phy->regs->ctrl);
> >+	if (on) {
> >+		/* Configure and power PHY */
> >+		val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
> >+			 OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
> >+		val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
> >+		writel(val, &phy->regs->ctrl);
> >+
> >+		/* Soft reset PHY */
> >+		val = readl(&phy->regs->p1ctl);
> >+		val &= ~P1CTL_NON_DRIVING;
> >+		val |= P1CTL_SOFT_RESET;
> >+		writel(val, &phy->regs->p1ctl);
> >+		writel(val & ~P1CTL_SOFT_RESET, &phy->regs->p1ctl);
> >+		/* Reset needs to be asserted for 2ms */
> >+		mdelay(2);
> >+		writel(val | P1CTL_SOFT_RESET, &phy->regs->p1ctl);
> 
> Is soft reset needed for every power-on? Shouldn't soft reset be
> present in phy_init?

Not needed for every power-on. Yes, I've addressed that now for v3,
thanks.

-Matt