[PATCH v6 0/8] power: add power sequence library

[PATCH v6 0/8] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
  the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support multiple input clocks [Patch 2/6]
- Add Rob Herring's ack for DT changes
- Add Joshua Clayton's Tested-by

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
  at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
  add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
  layer's at core's probe

Joshua Clayton (2):
  ARM: dts: imx6qdl: Enable usb node children with <reg>
  ARM: dts: imx6q-evi: Fix onboard hub reset line

Peter Chen (6):
  binding-doc: power: pwrseq-generic: add binding doc for generic power
    sequence library
  power: add power sequence library
  binding-doc: usb: usb-device: add optional properties for power
    sequence
  usb: core: add power sequence handling for USB devices
  usb: chipidea: let chipidea core device of_node equal's glue layer
    device of_node
  ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

 .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 ++++++
 .../devicetree/bindings/usb/usb-device.txt         |  10 +-
 MAINTAINERS                                        |   9 ++
 arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
 arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++--
 arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
 drivers/power/Kconfig                              |   1 +
 drivers/power/Makefile                             |   1 +
 drivers/power/pwrseq/Kconfig                       |  20 +++
 drivers/power/pwrseq/Makefile                      |   2 +
 drivers/power/pwrseq/core.c                        |  62 ++++++++
 drivers/power/pwrseq/pwrseq_generic.c              | 168 +++++++++++++++++++++
 drivers/usb/chipidea/core.c                        |  27 +++-
 drivers/usb/core/Makefile                          |   1 +
 drivers/usb/core/hub.c                             |  12 +-
 drivers/usb/core/hub.h                             |  12 ++
 drivers/usb/core/pwrseq.c                          | 100 ++++++++++++
 include/linux/power/pwrseq.h                       |  47 ++++++
 18 files changed, 536 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 drivers/usb/core/pwrseq.c
 create mode 100644 include/linux/power/pwrseq.h

-- 
1.9.1

[PATCH v6 0/8] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
  the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support multiple input clocks [Patch 2/6]
- Add Rob Herring's ack for DT changes
- Add Joshua Clayton's Tested-by

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
  at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
  add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
  layer's at core's probe

Joshua Clayton (2):
  ARM: dts: imx6qdl: Enable usb node children with <reg>
  ARM: dts: imx6q-evi: Fix onboard hub reset line

Peter Chen (6):
  binding-doc: power: pwrseq-generic: add binding doc for generic power
    sequence library
  power: add power sequence library
  binding-doc: usb: usb-device: add optional properties for power
    sequence
  usb: core: add power sequence handling for USB devices
  usb: chipidea: let chipidea core device of_node equal's glue layer
    device of_node
  ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

 .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 ++++++
 .../devicetree/bindings/usb/usb-device.txt         |  10 +-
 MAINTAINERS                                        |   9 ++
 arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
 arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++--
 arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
 drivers/power/Kconfig                              |   1 +
 drivers/power/Makefile                             |   1 +
 drivers/power/pwrseq/Kconfig                       |  20 +++
 drivers/power/pwrseq/Makefile                      |   2 +
 drivers/power/pwrseq/core.c                        |  62 ++++++++
 drivers/power/pwrseq/pwrseq_generic.c              | 168 +++++++++++++++++++++
 drivers/usb/chipidea/core.c                        |  27 +++-
 drivers/usb/core/Makefile                          |   1 +
 drivers/usb/core/hub.c                             |  12 +-
 drivers/usb/core/hub.h                             |  12 ++
 drivers/usb/core/pwrseq.c                          | 100 ++++++++++++
 include/linux/power/pwrseq.h                       |  47 ++++++
 18 files changed, 536 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 drivers/usb/core/pwrseq.c
 create mode 100644 include/linux/power/pwrseq.h

-- 
1.9.1

--
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 v6 0/8] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
  the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support multiple input clocks [Patch 2/6]
- Add Rob Herring's ack for DT changes
- Add Joshua Clayton's Tested-by

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
  at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
  add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
  layer's at core's probe

Joshua Clayton (2):
  ARM: dts: imx6qdl: Enable usb node children with <reg>
  ARM: dts: imx6q-evi: Fix onboard hub reset line

Peter Chen (6):
  binding-doc: power: pwrseq-generic: add binding doc for generic power
    sequence library
  power: add power sequence library
  binding-doc: usb: usb-device: add optional properties for power
    sequence
  usb: core: add power sequence handling for USB devices
  usb: chipidea: let chipidea core device of_node equal's glue layer
    device of_node
  ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

 .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 ++++++
 .../devicetree/bindings/usb/usb-device.txt         |  10 +-
 MAINTAINERS                                        |   9 ++
 arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
 arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++--
 arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
 drivers/power/Kconfig                              |   1 +
 drivers/power/Makefile                             |   1 +
 drivers/power/pwrseq/Kconfig                       |  20 +++
 drivers/power/pwrseq/Makefile                      |   2 +
 drivers/power/pwrseq/core.c                        |  62 ++++++++
 drivers/power/pwrseq/pwrseq_generic.c              | 168 +++++++++++++++++++++
 drivers/usb/chipidea/core.c                        |  27 +++-
 drivers/usb/core/Makefile                          |   1 +
 drivers/usb/core/hub.c                             |  12 +-
 drivers/usb/core/hub.h                             |  12 ++
 drivers/usb/core/pwrseq.c                          | 100 ++++++++++++
 include/linux/power/pwrseq.h                       |  47 ++++++
 18 files changed, 536 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 drivers/usb/core/pwrseq.c
 create mode 100644 include/linux/power/pwrseq.h

-- 
1.9.1

[PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 0000000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+&usbotg1 {
+	vbus-supply = <&reg_usb_otg1_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb_otg1_id>;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+	genesys: hub@1 {
+		compatible = "usb5e3,608";
+		reg = <1>;
+
+		clocks = <&clks IMX6SX_CLK_CKO>;
+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+		reset-duration-us = <10>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+		asix: ethernet@1 {
+			compatible = "usbb95,1708";
+			reg = <1>;
+
+			clocks = <&clks IMX6SX_CLK_IPG>;
+			reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* ethernet_rst */
+			reset-duration-us = <15>;
+		};
+	};
+};
-- 
1.9.1

[PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 0000000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+&usbotg1 {
+	vbus-supply = <&reg_usb_otg1_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb_otg1_id>;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+	genesys: hub@1 {
+		compatible = "usb5e3,608";
+		reg = <1>;
+
+		clocks = <&clks IMX6SX_CLK_CKO>;
+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+		reset-duration-us = <10>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+		asix: ethernet@1 {
+			compatible = "usbb95,1708";
+			reg = <1>;
+
+			clocks = <&clks IMX6SX_CLK_IPG>;
+			reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* ethernet_rst */
+			reset-duration-us = <15>;
+		};
+	};
+};
-- 
1.9.1

[PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 0000000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+&usbotg1 {
+	vbus-supply = <&reg_usb_otg1_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb_otg1_id>;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+	genesys: hub at 1 {
+		compatible = "usb5e3,608";
+		reg = <1>;
+
+		clocks = <&clks IMX6SX_CLK_CKO>;
+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+		reset-duration-us = <10>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+		asix: ethernet at 1 {
+			compatible = "usbb95,1708";
+			reg = <1>;
+
+			clocks = <&clks IMX6SX_CLK_IPG>;
+			reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* ethernet_rst */
+			reset-duration-us = <15>;
+		};
+	};
+};
-- 
1.9.1

[PATCH v6 2/8] power: add power sequence library

[Peter Chen]

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover regulator and pinctrl
in future. The host driver calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
---
 MAINTAINERS                           |   9 ++
 drivers/power/Kconfig                 |   1 +
 drivers/power/Makefile                |   1 +
 drivers/power/pwrseq/Kconfig          |  20 ++++
 drivers/power/pwrseq/Makefile         |   2 +
 drivers/power/pwrseq/core.c           |  62 +++++++++++++
 drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
 include/linux/power/pwrseq.h          |  47 ++++++++++
 8 files changed, 310 insertions(+)
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ae6c84..407254b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
 F:	include/linux/powercap.h
 F:	drivers/powercap/
 
+POWER SEQUENCE LIBRARY
+M:	Peter Chen <Peter.Chen@nxp.com>
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L:	linux-pm@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/power/pwrseq/
+F:	drivers/power/pwrseq/
+F:	include/linux/power/pwrseq.h/
+
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
 M:	Sebastian Reichel <sre@kernel.org>
 M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
 
 source "drivers/power/reset/Kconfig"
 source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)	+= reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 0000000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+config POWER_SEQUENCE
+	bool
+
+menu "Power Sequence Support"
+
+config PWRSEQ_GENERIC
+	bool "Generic power sequence control"
+	depends on OF
+	select POWER_SEQUENCE
+	help
+	  It is used for drivers which needs to do power sequence
+	  (eg, turn on clock, toggle reset gpio) before the related
+	  devices can be found by hardware. This generic one can be
+	  used for common power sequence control.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 0000000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 0000000..dcf96c4
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,62 @@
+/*
+ * core.c	power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/power/pwrseq.h>
+
+static DEFINE_MUTEX(pwrseq_list_mutex);
+static LIST_HEAD(pwrseq_list);
+
+int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+	if (p && p->get)
+		return p->get(np, p);
+
+	return -ENOTSUPP;
+}
+EXPORT_SYMBOL(pwrseq_get);
+
+int pwrseq_on(struct device_node *np, struct pwrseq *p)
+{
+	if (p && p->on)
+		return p->on(np, p);
+
+	return -ENOTSUPP;
+}
+EXPORT_SYMBOL(pwrseq_on);
+
+void pwrseq_off(struct pwrseq *p)
+{
+	if (p && p->off)
+		p->off(p);
+}
+EXPORT_SYMBOL(pwrseq_off);
+
+void pwrseq_put(struct pwrseq *p)
+{
+	if (p && p->put)
+		p->put(p);
+}
+EXPORT_SYMBOL(pwrseq_put);
+
+void pwrseq_free(struct pwrseq *p)
+{
+	if (p && p->free)
+		p->free(p);
+}
+EXPORT_SYMBOL(pwrseq_free);
diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
new file mode 100644
index 0000000..8af626f
--- /dev/null
+++ b/drivers/power/pwrseq/pwrseq_generic.c
@@ -0,0 +1,168 @@
+/*
+ * pwrseq_generic.c	Generic power sequence handling
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/slab.h>
+
+#include <linux/power/pwrseq.h>
+
+struct pwrseq_generic {
+	struct pwrseq pwrseq;
+	struct gpio_desc *gpiod_reset;
+	struct clk *clks[PWRSEQ_MAX_CLKS];
+};
+
+#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
+
+static void pwrseq_generic_free(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+
+	kfree(pwrseq_gen);
+}
+
+static void pwrseq_generic_put(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk;
+
+	if (pwrseq_gen->gpiod_reset)
+		gpiod_put(pwrseq_gen->gpiod_reset);
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
+		clk_put(pwrseq_gen->clks[clk]);
+}
+
+static void pwrseq_generic_off(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk;
+
+	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
+}
+
+static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk, ret = 0;
+	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
+		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
+		if (ret) {
+			pr_err("Can't enable clock on %s: %d\n",
+				np->full_name, ret);
+			goto err_disable_clks;
+		}
+	}
+
+	if (gpiod_reset) {
+		u32 duration_us = 50;
+
+		of_property_read_u32(np, "reset-duration-us",
+				&duration_us);
+		if (duration_us <= 10)
+			udelay(10);
+		else
+			usleep_range(duration_us, duration_us + 100);
+		gpiod_set_value(gpiod_reset, 0);
+	}
+
+	return ret;
+
+err_disable_clks:
+	while (--clk >= 0)
+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
+
+	return ret;
+}
+
+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	enum of_gpio_flags flags;
+	int reset_gpio, clk, ret = 0;
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
+		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
+		if (IS_ERR(pwrseq_gen->clks[clk])) {
+			ret = PTR_ERR(pwrseq_gen->clks[clk]);
+			if (ret == -EPROBE_DEFER)
+				goto err_put_clks;
+			pwrseq_gen->clks[clk] = NULL;
+			break;
+		}
+	}
+
+	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
+	if (gpio_is_valid(reset_gpio)) {
+		unsigned long gpio_flags;
+
+		if (flags & OF_GPIO_ACTIVE_LOW)
+			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
+		else
+			gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+		ret = gpio_request_one(reset_gpio, gpio_flags,
+				"pwrseq-reset-gpios");
+		if (ret)
+			goto err_put_clks;
+
+		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
+	} else {
+		if (reset_gpio == -ENOENT)
+			return 0;
+
+		ret = reset_gpio;
+		pr_err("Failed to get reset gpio on %s, err = %d\n",
+				np->full_name, reset_gpio);
+		goto err_put_clks;
+	}
+
+	return ret;
+
+err_put_clks:
+	while (--clk >= 0)
+		clk_put(pwrseq_gen->clks[clk]);
+	return ret;
+}
+
+struct pwrseq *pwrseq_alloc_generic(void)
+{
+	struct pwrseq_generic *pwrseq_gen;
+
+	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
+	if (!pwrseq_gen)
+		return ERR_PTR(-ENOMEM);
+
+	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
+	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
+	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
+	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
+	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
+
+	return &pwrseq_gen->pwrseq;
+}
+EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
new file mode 100644
index 0000000..ebb2280
--- /dev/null
+++ b/include/linux/power/pwrseq.h
@@ -0,0 +1,47 @@
+#ifndef __LINUX_PWRSEQ_H
+#define __LINUX_PWRSEQ_H
+
+#include <linux/of.h>
+
+#define PWRSEQ_MAX_CLKS		3
+
+struct pwrseq {
+	char *name;
+	struct list_head node;
+	int (*get)(struct device_node *np, struct pwrseq *p);
+	int (*on)(struct device_node *np, struct pwrseq *p);
+	void (*off)(struct pwrseq *p);
+	void (*put)(struct pwrseq *p);
+	void (*free)(struct pwrseq *p);
+};
+
+#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
+int pwrseq_get(struct device_node *np, struct pwrseq *p);
+int pwrseq_on(struct device_node *np, struct pwrseq *p);
+void pwrseq_off(struct pwrseq *p);
+void pwrseq_put(struct pwrseq *p);
+void pwrseq_free(struct pwrseq *p);
+#else
+static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+	return 0;
+}
+static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
+{
+	return 0;
+}
+static inline void pwrseq_off(struct pwrseq *p) {}
+static inline void pwrseq_put(struct pwrseq *p) {}
+static inline void pwrseq_free(struct pwrseq *p) {}
+#endif /* CONFIG_POWER_SEQUENCE */
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+struct pwrseq *pwrseq_alloc_generic(void);
+#else
+static inline struct pwrseq *pwrseq_alloc_generic(void)
+{
+	return NULL;
+}
+#endif /* CONFIG_PWRSEQ_GENERIC */
+
+#endif  /* __LINUX_PWRSEQ_H */
-- 
1.9.1

[PATCH v6 2/8] power: add power sequence library

[Peter Chen]

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover regulator and pinctrl
in future. The host driver calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
---
 MAINTAINERS                           |   9 ++
 drivers/power/Kconfig                 |   1 +
 drivers/power/Makefile                |   1 +
 drivers/power/pwrseq/Kconfig          |  20 ++++
 drivers/power/pwrseq/Makefile         |   2 +
 drivers/power/pwrseq/core.c           |  62 +++++++++++++
 drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
 include/linux/power/pwrseq.h          |  47 ++++++++++
 8 files changed, 310 insertions(+)
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ae6c84..407254b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
 F:	include/linux/powercap.h
 F:	drivers/powercap/
 
+POWER SEQUENCE LIBRARY
+M:	Peter Chen <Peter.Chen@nxp.com>
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L:	linux-pm@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/power/pwrseq/
+F:	drivers/power/pwrseq/
+F:	include/linux/power/pwrseq.h/
+
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
 M:	Sebastian Reichel <sre@kernel.org>
 M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
 
 source "drivers/power/reset/Kconfig"
 source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)	+= reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 0000000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+config POWER_SEQUENCE
+	bool
+
+menu "Power Sequence Support"
+
+config PWRSEQ_GENERIC
+	bool "Generic power sequence control"
+	depends on OF
+	select POWER_SEQUENCE
+	help
+	  It is used for drivers which needs to do power sequence
+	  (eg, turn on clock, toggle reset gpio) before the related
+	  devices can be found by hardware. This generic one can be
+	  used for common power sequence control.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 0000000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 0000000..dcf96c4
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,62 @@
+/*
+ * core.c	power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/power/pwrseq.h>
+
+static DEFINE_MUTEX(pwrseq_list_mutex);
+static LIST_HEAD(pwrseq_list);
+
+int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+	if (p && p->get)
+		return p->get(np, p);
+
+	return -ENOTSUPP;
+}
+EXPORT_SYMBOL(pwrseq_get);
+
+int pwrseq_on(struct device_node *np, struct pwrseq *p)
+{
+	if (p && p->on)
+		return p->on(np, p);
+
+	return -ENOTSUPP;
+}
+EXPORT_SYMBOL(pwrseq_on);
+
+void pwrseq_off(struct pwrseq *p)
+{
+	if (p && p->off)
+		p->off(p);
+}
+EXPORT_SYMBOL(pwrseq_off);
+
+void pwrseq_put(struct pwrseq *p)
+{
+	if (p && p->put)
+		p->put(p);
+}
+EXPORT_SYMBOL(pwrseq_put);
+
+void pwrseq_free(struct pwrseq *p)
+{
+	if (p && p->free)
+		p->free(p);
+}
+EXPORT_SYMBOL(pwrseq_free);
diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
new file mode 100644
index 0000000..8af626f
--- /dev/null
+++ b/drivers/power/pwrseq/pwrseq_generic.c
@@ -0,0 +1,168 @@
+/*
+ * pwrseq_generic.c	Generic power sequence handling
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/slab.h>
+
+#include <linux/power/pwrseq.h>
+
+struct pwrseq_generic {
+	struct pwrseq pwrseq;
+	struct gpio_desc *gpiod_reset;
+	struct clk *clks[PWRSEQ_MAX_CLKS];
+};
+
+#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
+
+static void pwrseq_generic_free(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+
+	kfree(pwrseq_gen);
+}
+
+static void pwrseq_generic_put(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk;
+
+	if (pwrseq_gen->gpiod_reset)
+		gpiod_put(pwrseq_gen->gpiod_reset);
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
+		clk_put(pwrseq_gen->clks[clk]);
+}
+
+static void pwrseq_generic_off(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk;
+
+	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
+}
+
+static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk, ret = 0;
+	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
+		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
+		if (ret) {
+			pr_err("Can't enable clock on %s: %d\n",
+				np->full_name, ret);
+			goto err_disable_clks;
+		}
+	}
+
+	if (gpiod_reset) {
+		u32 duration_us = 50;
+
+		of_property_read_u32(np, "reset-duration-us",
+				&duration_us);
+		if (duration_us <= 10)
+			udelay(10);
+		else
+			usleep_range(duration_us, duration_us + 100);
+		gpiod_set_value(gpiod_reset, 0);
+	}
+
+	return ret;
+
+err_disable_clks:
+	while (--clk >= 0)
+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
+
+	return ret;
+}
+
+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	enum of_gpio_flags flags;
+	int reset_gpio, clk, ret = 0;
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
+		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
+		if (IS_ERR(pwrseq_gen->clks[clk])) {
+			ret = PTR_ERR(pwrseq_gen->clks[clk]);
+			if (ret == -EPROBE_DEFER)
+				goto err_put_clks;
+			pwrseq_gen->clks[clk] = NULL;
+			break;
+		}
+	}
+
+	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
+	if (gpio_is_valid(reset_gpio)) {
+		unsigned long gpio_flags;
+
+		if (flags & OF_GPIO_ACTIVE_LOW)
+			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
+		else
+			gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+		ret = gpio_request_one(reset_gpio, gpio_flags,
+				"pwrseq-reset-gpios");
+		if (ret)
+			goto err_put_clks;
+
+		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
+	} else {
+		if (reset_gpio == -ENOENT)
+			return 0;
+
+		ret = reset_gpio;
+		pr_err("Failed to get reset gpio on %s, err = %d\n",
+				np->full_name, reset_gpio);
+		goto err_put_clks;
+	}
+
+	return ret;
+
+err_put_clks:
+	while (--clk >= 0)
+		clk_put(pwrseq_gen->clks[clk]);
+	return ret;
+}
+
+struct pwrseq *pwrseq_alloc_generic(void)
+{
+	struct pwrseq_generic *pwrseq_gen;
+
+	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
+	if (!pwrseq_gen)
+		return ERR_PTR(-ENOMEM);
+
+	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
+	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
+	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
+	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
+	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
+
+	return &pwrseq_gen->pwrseq;
+}
+EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
new file mode 100644
index 0000000..ebb2280
--- /dev/null
+++ b/include/linux/power/pwrseq.h
@@ -0,0 +1,47 @@
+#ifndef __LINUX_PWRSEQ_H
+#define __LINUX_PWRSEQ_H
+
+#include <linux/of.h>
+
+#define PWRSEQ_MAX_CLKS		3
+
+struct pwrseq {
+	char *name;
+	struct list_head node;
+	int (*get)(struct device_node *np, struct pwrseq *p);
+	int (*on)(struct device_node *np, struct pwrseq *p);
+	void (*off)(struct pwrseq *p);
+	void (*put)(struct pwrseq *p);
+	void (*free)(struct pwrseq *p);
+};
+
+#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
+int pwrseq_get(struct device_node *np, struct pwrseq *p);
+int pwrseq_on(struct device_node *np, struct pwrseq *p);
+void pwrseq_off(struct pwrseq *p);
+void pwrseq_put(struct pwrseq *p);
+void pwrseq_free(struct pwrseq *p);
+#else
+static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+	return 0;
+}
+static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
+{
+	return 0;
+}
+static inline void pwrseq_off(struct pwrseq *p) {}
+static inline void pwrseq_put(struct pwrseq *p) {}
+static inline void pwrseq_free(struct pwrseq *p) {}
+#endif /* CONFIG_POWER_SEQUENCE */
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+struct pwrseq *pwrseq_alloc_generic(void);
+#else
+static inline struct pwrseq *pwrseq_alloc_generic(void)
+{
+	return NULL;
+}
+#endif /* CONFIG_PWRSEQ_GENERIC */
+
+#endif  /* __LINUX_PWRSEQ_H */
-- 
1.9.1

[PATCH v6 2/8] power: add power sequence library

[Peter Chen]

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover regulator and pinctrl
in future. The host driver calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
---
 MAINTAINERS                           |   9 ++
 drivers/power/Kconfig                 |   1 +
 drivers/power/Makefile                |   1 +
 drivers/power/pwrseq/Kconfig          |  20 ++++
 drivers/power/pwrseq/Makefile         |   2 +
 drivers/power/pwrseq/core.c           |  62 +++++++++++++
 drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
 include/linux/power/pwrseq.h          |  47 ++++++++++
 8 files changed, 310 insertions(+)
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ae6c84..407254b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
 F:	include/linux/powercap.h
 F:	drivers/powercap/
 
+POWER SEQUENCE LIBRARY
+M:	Peter Chen <Peter.Chen@nxp.com>
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L:	linux-pm at vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/power/pwrseq/
+F:	drivers/power/pwrseq/
+F:	include/linux/power/pwrseq.h/
+
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
 M:	Sebastian Reichel <sre@kernel.org>
 M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
 
 source "drivers/power/reset/Kconfig"
 source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)	+= reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 0000000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+config POWER_SEQUENCE
+	bool
+
+menu "Power Sequence Support"
+
+config PWRSEQ_GENERIC
+	bool "Generic power sequence control"
+	depends on OF
+	select POWER_SEQUENCE
+	help
+	  It is used for drivers which needs to do power sequence
+	  (eg, turn on clock, toggle reset gpio) before the related
+	  devices can be found by hardware. This generic one can be
+	  used for common power sequence control.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 0000000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 0000000..dcf96c4
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,62 @@
+/*
+ * core.c	power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/power/pwrseq.h>
+
+static DEFINE_MUTEX(pwrseq_list_mutex);
+static LIST_HEAD(pwrseq_list);
+
+int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+	if (p && p->get)
+		return p->get(np, p);
+
+	return -ENOTSUPP;
+}
+EXPORT_SYMBOL(pwrseq_get);
+
+int pwrseq_on(struct device_node *np, struct pwrseq *p)
+{
+	if (p && p->on)
+		return p->on(np, p);
+
+	return -ENOTSUPP;
+}
+EXPORT_SYMBOL(pwrseq_on);
+
+void pwrseq_off(struct pwrseq *p)
+{
+	if (p && p->off)
+		p->off(p);
+}
+EXPORT_SYMBOL(pwrseq_off);
+
+void pwrseq_put(struct pwrseq *p)
+{
+	if (p && p->put)
+		p->put(p);
+}
+EXPORT_SYMBOL(pwrseq_put);
+
+void pwrseq_free(struct pwrseq *p)
+{
+	if (p && p->free)
+		p->free(p);
+}
+EXPORT_SYMBOL(pwrseq_free);
diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
new file mode 100644
index 0000000..8af626f
--- /dev/null
+++ b/drivers/power/pwrseq/pwrseq_generic.c
@@ -0,0 +1,168 @@
+/*
+ * pwrseq_generic.c	Generic power sequence handling
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/slab.h>
+
+#include <linux/power/pwrseq.h>
+
+struct pwrseq_generic {
+	struct pwrseq pwrseq;
+	struct gpio_desc *gpiod_reset;
+	struct clk *clks[PWRSEQ_MAX_CLKS];
+};
+
+#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
+
+static void pwrseq_generic_free(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+
+	kfree(pwrseq_gen);
+}
+
+static void pwrseq_generic_put(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk;
+
+	if (pwrseq_gen->gpiod_reset)
+		gpiod_put(pwrseq_gen->gpiod_reset);
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
+		clk_put(pwrseq_gen->clks[clk]);
+}
+
+static void pwrseq_generic_off(struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk;
+
+	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
+}
+
+static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	int clk, ret = 0;
+	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
+		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
+		if (ret) {
+			pr_err("Can't enable clock on %s: %d\n",
+				np->full_name, ret);
+			goto err_disable_clks;
+		}
+	}
+
+	if (gpiod_reset) {
+		u32 duration_us = 50;
+
+		of_property_read_u32(np, "reset-duration-us",
+				&duration_us);
+		if (duration_us <= 10)
+			udelay(10);
+		else
+			usleep_range(duration_us, duration_us + 100);
+		gpiod_set_value(gpiod_reset, 0);
+	}
+
+	return ret;
+
+err_disable_clks:
+	while (--clk >= 0)
+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
+
+	return ret;
+}
+
+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
+{
+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
+	enum of_gpio_flags flags;
+	int reset_gpio, clk, ret = 0;
+
+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
+		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
+		if (IS_ERR(pwrseq_gen->clks[clk])) {
+			ret = PTR_ERR(pwrseq_gen->clks[clk]);
+			if (ret == -EPROBE_DEFER)
+				goto err_put_clks;
+			pwrseq_gen->clks[clk] = NULL;
+			break;
+		}
+	}
+
+	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
+	if (gpio_is_valid(reset_gpio)) {
+		unsigned long gpio_flags;
+
+		if (flags & OF_GPIO_ACTIVE_LOW)
+			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
+		else
+			gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+		ret = gpio_request_one(reset_gpio, gpio_flags,
+				"pwrseq-reset-gpios");
+		if (ret)
+			goto err_put_clks;
+
+		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
+	} else {
+		if (reset_gpio == -ENOENT)
+			return 0;
+
+		ret = reset_gpio;
+		pr_err("Failed to get reset gpio on %s, err = %d\n",
+				np->full_name, reset_gpio);
+		goto err_put_clks;
+	}
+
+	return ret;
+
+err_put_clks:
+	while (--clk >= 0)
+		clk_put(pwrseq_gen->clks[clk]);
+	return ret;
+}
+
+struct pwrseq *pwrseq_alloc_generic(void)
+{
+	struct pwrseq_generic *pwrseq_gen;
+
+	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
+	if (!pwrseq_gen)
+		return ERR_PTR(-ENOMEM);
+
+	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
+	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
+	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
+	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
+	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
+
+	return &pwrseq_gen->pwrseq;
+}
+EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
new file mode 100644
index 0000000..ebb2280
--- /dev/null
+++ b/include/linux/power/pwrseq.h
@@ -0,0 +1,47 @@
+#ifndef __LINUX_PWRSEQ_H
+#define __LINUX_PWRSEQ_H
+
+#include <linux/of.h>
+
+#define PWRSEQ_MAX_CLKS		3
+
+struct pwrseq {
+	char *name;
+	struct list_head node;
+	int (*get)(struct device_node *np, struct pwrseq *p);
+	int (*on)(struct device_node *np, struct pwrseq *p);
+	void (*off)(struct pwrseq *p);
+	void (*put)(struct pwrseq *p);
+	void (*free)(struct pwrseq *p);
+};
+
+#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
+int pwrseq_get(struct device_node *np, struct pwrseq *p);
+int pwrseq_on(struct device_node *np, struct pwrseq *p);
+void pwrseq_off(struct pwrseq *p);
+void pwrseq_put(struct pwrseq *p);
+void pwrseq_free(struct pwrseq *p);
+#else
+static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+	return 0;
+}
+static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
+{
+	return 0;
+}
+static inline void pwrseq_off(struct pwrseq *p) {}
+static inline void pwrseq_put(struct pwrseq *p) {}
+static inline void pwrseq_free(struct pwrseq *p) {}
+#endif /* CONFIG_POWER_SEQUENCE */
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+struct pwrseq *pwrseq_alloc_generic(void);
+#else
+static inline struct pwrseq *pwrseq_alloc_generic(void)
+{
+	return NULL;
+}
+#endif /* CONFIG_PWRSEQ_GENERIC */
+
+#endif  /* __LINUX_PWRSEQ_H */
-- 
1.9.1

[PATCH v6 3/8] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
 &usb1 {
@@ -21,8 +25,12 @@ Example:
 	#address-cells = <1>;
 	#size-cells = <0>;
 
-	hub: genesys@1 {
+	genesys: hub@1 {
 		compatible = "usb5e3,608";
 		reg = <1>;
+
+		clocks = <&clks IMX6SX_CLK_CKO>;
+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+		reset-duration-us = <10>;
 	};
 }
-- 
1.9.1

[PATCH v6 3/8] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
 &usb1 {
@@ -21,8 +25,12 @@ Example:
 	#address-cells = <1>;
 	#size-cells = <0>;
 
-	hub: genesys@1 {
+	genesys: hub@1 {
 		compatible = "usb5e3,608";
 		reg = <1>;
+
+		clocks = <&clks IMX6SX_CLK_CKO>;
+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+		reset-duration-us = <10>;
 	};
 }
-- 
1.9.1

--
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 v6 3/8] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
 &usb1 {
@@ -21,8 +25,12 @@ Example:
 	#address-cells = <1>;
 	#size-cells = <0>;
 
-	hub: genesys at 1 {
+	genesys: hub at 1 {
 		compatible = "usb5e3,608";
 		reg = <1>;
+
+		clocks = <&clks IMX6SX_CLK_CKO>;
+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+		reset-duration-us = <10>;
 	};
 }
-- 
1.9.1

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then it will do power
on sequence at hub's probe for all devices under this hub
(includes root hub).

At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
---
 drivers/usb/core/Makefile |   1 +
 drivers/usb/core/hub.c    |  12 ++++--
 drivers/usb/core/hub.h    |  12 ++++++
 drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..39f2149 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)		+= hcd-pci.o
 usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
 
 obj-$(CONFIG_USB)		+= usbcore.o
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
 	hub->error = 0;
 	hub_quiesce(hub, HUB_DISCONNECT);
 
+	hub_pwrseq_off(hub);
 	mutex_lock(&usb_port_peer_mutex);
 
 	/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
 	struct usb_endpoint_descriptor *endpoint;
 	struct usb_device *hdev;
 	struct usb_hub *hub;
+	int ret = -ENODEV;
 
 	desc = intf->cur_altsetting;
 	hdev = interface_to_usbdev(intf);
@@ -1839,6 +1841,7 @@ descriptor_error:
 	INIT_DELAYED_WORK(&hub->leds, led_work);
 	INIT_DELAYED_WORK(&hub->init_work, NULL);
 	INIT_WORK(&hub->events, hub_event);
+	INIT_LIST_HEAD(&hub->pwrseq_on_list);
 	usb_get_intf(intf);
 	usb_get_dev(hdev);
 
@@ -1852,11 +1855,14 @@ descriptor_error:
 	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
 		hub->quirk_check_port_auto_suspend = 1;
 
-	if (hub_configure(hub, endpoint) >= 0)
-		return 0;
+	if (hub_configure(hub, endpoint) >= 0) {
+		ret = hub_pwrseq_on(hub);
+		if (!ret)
+			return 0;
+	}
 
 	hub_disconnect(intf);
-	return -ENODEV;
+	return ret;
 }
 
 static int
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
 	struct delayed_work	init_work;
 	struct work_struct      events;
 	struct usb_port		**ports;
+	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
 };
 
 /**
@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
 {
 	return hub_port_debounce(hub, port1, false);
 }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+	return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 0000000..837fe66
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,100 @@
+/*
+ * pwrseq.c	USB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/power/pwrseq.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+	struct pwrseq *pwrseq;
+	struct list_head list;
+};
+
+static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
+{
+	struct pwrseq *pwrseq;
+	struct usb_pwrseq_node *pwrseq_node;
+	int ret;
+
+	pwrseq = pwrseq_alloc_generic();
+	if (IS_ERR(pwrseq))
+		return PTR_ERR(pwrseq);
+
+	ret = pwrseq_get(np, pwrseq);
+	if (ret)
+		goto pwr_free;
+
+	ret = pwrseq_on(np, pwrseq);
+	if (ret)
+		goto pwr_put;
+
+	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
+	pwrseq_node->pwrseq = pwrseq;
+	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
+
+	return 0;
+
+pwr_put:
+	pwrseq_put(pwrseq);
+pwr_free:
+	pwrseq_free(pwrseq);
+	return ret;
+}
+
+int hub_pwrseq_on(struct usb_hub *hub)
+{
+	struct device *parent;
+	struct usb_device *hdev = hub->hdev;
+	struct device_node *np;
+	int ret;
+
+	if (hdev->parent)
+		parent = &hdev->dev;
+	else
+		parent = bus_to_hcd(hdev->bus)->self.controller;
+
+	for_each_child_of_node(parent->of_node, np) {
+		ret = hub_of_pwrseq_on(np, hub);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+void hub_pwrseq_off(struct usb_hub *hub)
+{
+	struct pwrseq *pwrseq;
+	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
+
+	list_for_each_entry_safe(pwrseq_node, tmp_node,
+			&hub->pwrseq_on_list, list) {
+		pwrseq = pwrseq_node->pwrseq;
+		pwrseq_off(pwrseq);
+		pwrseq_put(pwrseq);
+		pwrseq_free(pwrseq);
+		list_del(&pwrseq_node->list);
+		kfree(pwrseq_node);
+	}
+}
-- 
1.9.1

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then it will do power
on sequence at hub's probe for all devices under this hub
(includes root hub).

At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
---
 drivers/usb/core/Makefile |   1 +
 drivers/usb/core/hub.c    |  12 ++++--
 drivers/usb/core/hub.h    |  12 ++++++
 drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..39f2149 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)		+= hcd-pci.o
 usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
 
 obj-$(CONFIG_USB)		+= usbcore.o
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
 	hub->error = 0;
 	hub_quiesce(hub, HUB_DISCONNECT);
 
+	hub_pwrseq_off(hub);
 	mutex_lock(&usb_port_peer_mutex);
 
 	/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
 	struct usb_endpoint_descriptor *endpoint;
 	struct usb_device *hdev;
 	struct usb_hub *hub;
+	int ret = -ENODEV;
 
 	desc = intf->cur_altsetting;
 	hdev = interface_to_usbdev(intf);
@@ -1839,6 +1841,7 @@ descriptor_error:
 	INIT_DELAYED_WORK(&hub->leds, led_work);
 	INIT_DELAYED_WORK(&hub->init_work, NULL);
 	INIT_WORK(&hub->events, hub_event);
+	INIT_LIST_HEAD(&hub->pwrseq_on_list);
 	usb_get_intf(intf);
 	usb_get_dev(hdev);
 
@@ -1852,11 +1855,14 @@ descriptor_error:
 	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
 		hub->quirk_check_port_auto_suspend = 1;
 
-	if (hub_configure(hub, endpoint) >= 0)
-		return 0;
+	if (hub_configure(hub, endpoint) >= 0) {
+		ret = hub_pwrseq_on(hub);
+		if (!ret)
+			return 0;
+	}
 
 	hub_disconnect(intf);
-	return -ENODEV;
+	return ret;
 }
 
 static int
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
 	struct delayed_work	init_work;
 	struct work_struct      events;
 	struct usb_port		**ports;
+	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
 };
 
 /**
@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
 {
 	return hub_port_debounce(hub, port1, false);
 }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+	return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 0000000..837fe66
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,100 @@
+/*
+ * pwrseq.c	USB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/power/pwrseq.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+	struct pwrseq *pwrseq;
+	struct list_head list;
+};
+
+static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
+{
+	struct pwrseq *pwrseq;
+	struct usb_pwrseq_node *pwrseq_node;
+	int ret;
+
+	pwrseq = pwrseq_alloc_generic();
+	if (IS_ERR(pwrseq))
+		return PTR_ERR(pwrseq);
+
+	ret = pwrseq_get(np, pwrseq);
+	if (ret)
+		goto pwr_free;
+
+	ret = pwrseq_on(np, pwrseq);
+	if (ret)
+		goto pwr_put;
+
+	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
+	pwrseq_node->pwrseq = pwrseq;
+	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
+
+	return 0;
+
+pwr_put:
+	pwrseq_put(pwrseq);
+pwr_free:
+	pwrseq_free(pwrseq);
+	return ret;
+}
+
+int hub_pwrseq_on(struct usb_hub *hub)
+{
+	struct device *parent;
+	struct usb_device *hdev = hub->hdev;
+	struct device_node *np;
+	int ret;
+
+	if (hdev->parent)
+		parent = &hdev->dev;
+	else
+		parent = bus_to_hcd(hdev->bus)->self.controller;
+
+	for_each_child_of_node(parent->of_node, np) {
+		ret = hub_of_pwrseq_on(np, hub);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+void hub_pwrseq_off(struct usb_hub *hub)
+{
+	struct pwrseq *pwrseq;
+	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
+
+	list_for_each_entry_safe(pwrseq_node, tmp_node,
+			&hub->pwrseq_on_list, list) {
+		pwrseq = pwrseq_node->pwrseq;
+		pwrseq_off(pwrseq);
+		pwrseq_put(pwrseq);
+		pwrseq_free(pwrseq);
+		list_del(&pwrseq_node->list);
+		kfree(pwrseq_node);
+	}
+}
-- 
1.9.1

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then it will do power
on sequence at hub's probe for all devices under this hub
(includes root hub).

At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
---
 drivers/usb/core/Makefile |   1 +
 drivers/usb/core/hub.c    |  12 ++++--
 drivers/usb/core/hub.h    |  12 ++++++
 drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..39f2149 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)		+= hcd-pci.o
 usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
 
 obj-$(CONFIG_USB)		+= usbcore.o
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
 	hub->error = 0;
 	hub_quiesce(hub, HUB_DISCONNECT);
 
+	hub_pwrseq_off(hub);
 	mutex_lock(&usb_port_peer_mutex);
 
 	/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
 	struct usb_endpoint_descriptor *endpoint;
 	struct usb_device *hdev;
 	struct usb_hub *hub;
+	int ret = -ENODEV;
 
 	desc = intf->cur_altsetting;
 	hdev = interface_to_usbdev(intf);
@@ -1839,6 +1841,7 @@ descriptor_error:
 	INIT_DELAYED_WORK(&hub->leds, led_work);
 	INIT_DELAYED_WORK(&hub->init_work, NULL);
 	INIT_WORK(&hub->events, hub_event);
+	INIT_LIST_HEAD(&hub->pwrseq_on_list);
 	usb_get_intf(intf);
 	usb_get_dev(hdev);
 
@@ -1852,11 +1855,14 @@ descriptor_error:
 	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
 		hub->quirk_check_port_auto_suspend = 1;
 
-	if (hub_configure(hub, endpoint) >= 0)
-		return 0;
+	if (hub_configure(hub, endpoint) >= 0) {
+		ret = hub_pwrseq_on(hub);
+		if (!ret)
+			return 0;
+	}
 
 	hub_disconnect(intf);
-	return -ENODEV;
+	return ret;
 }
 
 static int
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
 	struct delayed_work	init_work;
 	struct work_struct      events;
 	struct usb_port		**ports;
+	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
 };
 
 /**
@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
 {
 	return hub_port_debounce(hub, port1, false);
 }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+	return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 0000000..837fe66
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,100 @@
+/*
+ * pwrseq.c	USB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen@nxp.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/power/pwrseq.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+	struct pwrseq *pwrseq;
+	struct list_head list;
+};
+
+static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
+{
+	struct pwrseq *pwrseq;
+	struct usb_pwrseq_node *pwrseq_node;
+	int ret;
+
+	pwrseq = pwrseq_alloc_generic();
+	if (IS_ERR(pwrseq))
+		return PTR_ERR(pwrseq);
+
+	ret = pwrseq_get(np, pwrseq);
+	if (ret)
+		goto pwr_free;
+
+	ret = pwrseq_on(np, pwrseq);
+	if (ret)
+		goto pwr_put;
+
+	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
+	pwrseq_node->pwrseq = pwrseq;
+	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
+
+	return 0;
+
+pwr_put:
+	pwrseq_put(pwrseq);
+pwr_free:
+	pwrseq_free(pwrseq);
+	return ret;
+}
+
+int hub_pwrseq_on(struct usb_hub *hub)
+{
+	struct device *parent;
+	struct usb_device *hdev = hub->hdev;
+	struct device_node *np;
+	int ret;
+
+	if (hdev->parent)
+		parent = &hdev->dev;
+	else
+		parent = bus_to_hcd(hdev->bus)->self.controller;
+
+	for_each_child_of_node(parent->of_node, np) {
+		ret = hub_of_pwrseq_on(np, hub);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+void hub_pwrseq_off(struct usb_hub *hub)
+{
+	struct pwrseq *pwrseq;
+	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
+
+	list_for_each_entry_safe(pwrseq_node, tmp_node,
+			&hub->pwrseq_on_list, list) {
+		pwrseq = pwrseq_node->pwrseq;
+		pwrseq_off(pwrseq);
+		pwrseq_put(pwrseq);
+		pwrseq_free(pwrseq);
+		list_del(&pwrseq_node->list);
+		kfree(pwrseq_node);
+	}
+}
-- 
1.9.1

[PATCH v6 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

From: Peter Chen <peter.chen@freescale.com>

At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
---
 drivers/usb/chipidea/core.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..6839e19 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -927,6 +927,16 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	/*
+	 * At device tree, we have no device node for chipidea core,
+	 * the glue layer's node is the parent node for host and udc
+	 * device. But in related driver, the parent device is chipidea
+	 * core. So, in order to let the common driver get parent's node,
+	 * we let the core's device node equals glue layer's node.
+	 */
+	if (dev->parent && dev->parent->of_node)
+		dev->of_node = dev->parent->of_node;
+
 	if (ci->platdata->phy) {
 		ci->phy = ci->platdata->phy;
 	} else if (ci->platdata->usb_phy) {
@@ -937,11 +947,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 		/* if both generic PHY and USB PHY layers aren't enabled */
 		if (PTR_ERR(ci->phy) == -ENOSYS &&
-				PTR_ERR(ci->usb_phy) == -ENXIO)
-			return -ENXIO;
+				PTR_ERR(ci->usb_phy) == -ENXIO) {
+			ret = -ENXIO;
+			goto clear_of_node;
+		}
 
-		if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy))
-			return -EPROBE_DEFER;
+		if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy)) {
+			ret = -EPROBE_DEFER;
+			goto clear_of_node;
+		}
 
 		if (IS_ERR(ci->phy))
 			ci->phy = NULL;
@@ -952,7 +966,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	ret = ci_usb_phy_init(ci);
 	if (ret) {
 		dev_err(dev, "unable to init phy: %d\n", ret);
-		return ret;
+		goto clear_of_node;
 	}
 
 	ci->hw_bank.phys = res->start;
@@ -1058,6 +1072,8 @@ stop:
 	ci_role_destroy(ci);
 deinit_phy:
 	ci_usb_phy_exit(ci);
+clear_of_node:
+	dev->of_node = NULL;
 
 	return ret;
 }
@@ -1076,6 +1092,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 	ci_extcon_unregister(ci);
 	ci_role_destroy(ci);
 	ci_hdrc_enter_lpm(ci, true);
+	ci->dev->of_node = NULL;
 	ci_usb_phy_exit(ci);
 
 	return 0;
-- 
1.9.1

[PATCH v6 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

From: Peter Chen <peter.chen@freescale.com>

At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
---
 drivers/usb/chipidea/core.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..6839e19 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -927,6 +927,16 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	/*
+	 * At device tree, we have no device node for chipidea core,
+	 * the glue layer's node is the parent node for host and udc
+	 * device. But in related driver, the parent device is chipidea
+	 * core. So, in order to let the common driver get parent's node,
+	 * we let the core's device node equals glue layer's node.
+	 */
+	if (dev->parent && dev->parent->of_node)
+		dev->of_node = dev->parent->of_node;
+
 	if (ci->platdata->phy) {
 		ci->phy = ci->platdata->phy;
 	} else if (ci->platdata->usb_phy) {
@@ -937,11 +947,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 		/* if both generic PHY and USB PHY layers aren't enabled */
 		if (PTR_ERR(ci->phy) == -ENOSYS &&
-				PTR_ERR(ci->usb_phy) == -ENXIO)
-			return -ENXIO;
+				PTR_ERR(ci->usb_phy) == -ENXIO) {
+			ret = -ENXIO;
+			goto clear_of_node;
+		}
 
-		if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy))
-			return -EPROBE_DEFER;
+		if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy)) {
+			ret = -EPROBE_DEFER;
+			goto clear_of_node;
+		}
 
 		if (IS_ERR(ci->phy))
 			ci->phy = NULL;
@@ -952,7 +966,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	ret = ci_usb_phy_init(ci);
 	if (ret) {
 		dev_err(dev, "unable to init phy: %d\n", ret);
-		return ret;
+		goto clear_of_node;
 	}
 
 	ci->hw_bank.phys = res->start;
@@ -1058,6 +1072,8 @@ stop:
 	ci_role_destroy(ci);
 deinit_phy:
 	ci_usb_phy_exit(ci);
+clear_of_node:
+	dev->of_node = NULL;
 
 	return ret;
 }
@@ -1076,6 +1092,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 	ci_extcon_unregister(ci);
 	ci_role_destroy(ci);
 	ci_hdrc_enter_lpm(ci, true);
+	ci->dev->of_node = NULL;
 	ci_usb_phy_exit(ci);
 
 	return 0;
-- 
1.9.1

[PATCH v6 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

From: Peter Chen <peter.chen@freescale.com>

At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Tested-by Joshua Clayton <stillcompiling@gmail.com>
---
 drivers/usb/chipidea/core.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..6839e19 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -927,6 +927,16 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	/*
+	 * At device tree, we have no device node for chipidea core,
+	 * the glue layer's node is the parent node for host and udc
+	 * device. But in related driver, the parent device is chipidea
+	 * core. So, in order to let the common driver get parent's node,
+	 * we let the core's device node equals glue layer's node.
+	 */
+	if (dev->parent && dev->parent->of_node)
+		dev->of_node = dev->parent->of_node;
+
 	if (ci->platdata->phy) {
 		ci->phy = ci->platdata->phy;
 	} else if (ci->platdata->usb_phy) {
@@ -937,11 +947,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 		/* if both generic PHY and USB PHY layers aren't enabled */
 		if (PTR_ERR(ci->phy) == -ENOSYS &&
-				PTR_ERR(ci->usb_phy) == -ENXIO)
-			return -ENXIO;
+				PTR_ERR(ci->usb_phy) == -ENXIO) {
+			ret = -ENXIO;
+			goto clear_of_node;
+		}
 
-		if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy))
-			return -EPROBE_DEFER;
+		if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy)) {
+			ret = -EPROBE_DEFER;
+			goto clear_of_node;
+		}
 
 		if (IS_ERR(ci->phy))
 			ci->phy = NULL;
@@ -952,7 +966,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	ret = ci_usb_phy_init(ci);
 	if (ret) {
 		dev_err(dev, "unable to init phy: %d\n", ret);
-		return ret;
+		goto clear_of_node;
 	}
 
 	ci->hw_bank.phys = res->start;
@@ -1058,6 +1072,8 @@ stop:
 	ci_role_destroy(ci);
 deinit_phy:
 	ci_usb_phy_exit(ci);
+clear_of_node:
+	dev->of_node = NULL;
 
 	return ret;
 }
@@ -1076,6 +1092,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 	ci_extcon_unregister(ci);
 	ci_role_destroy(ci);
 	ci_hdrc_enter_lpm(ci, true);
+	ci->dev->of_node = NULL;
 	ci_usb_phy_exit(ci);
 
 	return 0;
-- 
1.9.1

[PATCH v6 6/8] ARM: dts: imx6qdl: Enable usb node children with <reg>

[Peter Chen]

From: Joshua Clayton <stillcompiling@gmail.com>

Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a <reg> attribute

Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b620ac8..379ace5 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -935,6 +935,8 @@
 
 			usbh1: usb@02184200 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184200 0x200>;
 				interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -949,6 +951,8 @@
 
 			usbh2: usb@02184400 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184400 0x200>;
 				interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -962,6 +966,8 @@
 
 			usbh3: usb@02184600 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184600 0x200>;
 				interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
-- 
1.9.1

[PATCH v6 6/8] ARM: dts: imx6qdl: Enable usb node children with <reg>

[Peter Chen]

From: Joshua Clayton <stillcompiling@gmail.com>

Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a <reg> attribute

Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b620ac8..379ace5 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -935,6 +935,8 @@
 
 			usbh1: usb@02184200 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184200 0x200>;
 				interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -949,6 +951,8 @@
 
 			usbh2: usb@02184400 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184400 0x200>;
 				interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -962,6 +966,8 @@
 
 			usbh3: usb@02184600 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184600 0x200>;
 				interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
-- 
1.9.1

[PATCH v6 6/8] ARM: dts: imx6qdl: Enable usb node children with <reg>

[Peter Chen]

From: Joshua Clayton <stillcompiling@gmail.com>

Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a <reg> attribute

Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b620ac8..379ace5 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -935,6 +935,8 @@
 
 			usbh1: usb at 02184200 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184200 0x200>;
 				interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -949,6 +951,8 @@
 
 			usbh2: usb at 02184400 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184400 0x200>;
 				interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -962,6 +966,8 @@
 
 			usbh3: usb at 02184600 {
 				compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x02184600 0x200>;
 				interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX6QDL_CLK_USBOH3>;
-- 
1.9.1

[PATCH v6 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 3bee2f9..87fe31f 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include <dt-bindings/gpio/gpio.h>
+
 / {
 	aliases {
 		backlight = &backlight;
@@ -58,17 +60,6 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		reg_usb_h1_vbus: regulator@0 {
-			compatible = "regulator-fixed";
-			reg = <0>;
-			regulator-name = "usb_h1_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			startup-delay-us = <2>; /* USB2415 requires a POR of 1 us minimum */
-			gpio = <&gpio7 12 0>;
-		};
-
 		reg_panel: regulator@1 {
 			compatible = "regulator-fixed";
 			reg = <1>;
@@ -188,7 +179,7 @@
 
 		pinctrl_usbh: usbhgrp {
 			fsl,pins = <
-				MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x80000000
+				MX6QDL_PAD_GPIO_17__GPIO7_IO12	0x1b0b0
 				MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
 			>;
 		};
@@ -259,9 +250,16 @@
 &usbh1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usbh>;
-	vbus-supply = <&reg_usb_h1_vbus>;
-	clocks = <&clks IMX6QDL_CLK_CKO>;
 	status = "okay";
+
+	usb2415: hub@1 {
+		compatible = "usb424,2514";
+		reg = <1>;
+
+		clocks = <&clks IMX6QDL_CLK_CKO>;
+		reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+		reset-duration-us = <3000>;
+	};
 };
 
 &usdhc3 {
-- 
1.9.1

[PATCH v6 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.

Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 3bee2f9..87fe31f 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include <dt-bindings/gpio/gpio.h>
+
 / {
 	aliases {
 		backlight = &backlight;
@@ -58,17 +60,6 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		reg_usb_h1_vbus: regulator@0 {
-			compatible = "regulator-fixed";
-			reg = <0>;
-			regulator-name = "usb_h1_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			startup-delay-us = <2>; /* USB2415 requires a POR of 1 us minimum */
-			gpio = <&gpio7 12 0>;
-		};
-
 		reg_panel: regulator@1 {
 			compatible = "regulator-fixed";
 			reg = <1>;
@@ -188,7 +179,7 @@
 
 		pinctrl_usbh: usbhgrp {
 			fsl,pins = <
-				MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x80000000
+				MX6QDL_PAD_GPIO_17__GPIO7_IO12	0x1b0b0
 				MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
 			>;
 		};
@@ -259,9 +250,16 @@
 &usbh1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usbh>;
-	vbus-supply = <&reg_usb_h1_vbus>;
-	clocks = <&clks IMX6QDL_CLK_CKO>;
 	status = "okay";
+
+	usb2415: hub@1 {
+		compatible = "usb424,2514";
+		reg = <1>;
+
+		clocks = <&clks IMX6QDL_CLK_CKO>;
+		reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+		reset-duration-us = <3000>;
+	};
 };
 
 &usdhc3 {
-- 
1.9.1

--
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 v6 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 3bee2f9..87fe31f 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include <dt-bindings/gpio/gpio.h>
+
 / {
 	aliases {
 		backlight = &backlight;
@@ -58,17 +60,6 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		reg_usb_h1_vbus: regulator at 0 {
-			compatible = "regulator-fixed";
-			reg = <0>;
-			regulator-name = "usb_h1_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			startup-delay-us = <2>; /* USB2415 requires a POR of 1 us minimum */
-			gpio = <&gpio7 12 0>;
-		};
-
 		reg_panel: regulator at 1 {
 			compatible = "regulator-fixed";
 			reg = <1>;
@@ -188,7 +179,7 @@
 
 		pinctrl_usbh: usbhgrp {
 			fsl,pins = <
-				MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x80000000
+				MX6QDL_PAD_GPIO_17__GPIO7_IO12	0x1b0b0
 				MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
 			>;
 		};
@@ -259,9 +250,16 @@
 &usbh1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usbh>;
-	vbus-supply = <&reg_usb_h1_vbus>;
-	clocks = <&clks IMX6QDL_CLK_CKO>;
 	status = "okay";
+
+	usb2415: hub at 1 {
+		compatible = "usb424,2514";
+		reg = <1>;
+
+		clocks = <&clks IMX6QDL_CLK_CKO>;
+		reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+		reset-duration-us = <3000>;
+	};
 };
 
 &usdhc3 {
-- 
1.9.1

[PATCH v6 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line

[Peter Chen]

From: Joshua Clayton <stillcompiling@gmail.com>

Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group

Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
 arch/arm/boot/dts/imx6q-evi.dts | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 4fa5601..49c6f61 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
 		reg = <0x10000000 0x40000000>;
 	};
 
-	reg_usbh1_vbus: regulator-usbhubreset {
-		compatible = "regulator-fixed";
-		regulator-name = "usbh1_vbus";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		enable-active-high;
-		startup-delay-us = <2>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbh1_hubreset>;
-		gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
-	};
-
 	reg_usb_otg_vbus: regulator-usbotgvbus {
 		compatible = "regulator-fixed";
 		regulator-name = "usb_otg_vbus";
@@ -204,12 +192,18 @@
 };
 
 &usbh1 {
-	vbus-supply = <&reg_usbh1_vbus>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usbh1>;
 	dr_mode = "host";
 	disable-over-current;
 	status = "okay";
+
+	usb2415host: hub@1 {
+		compatible = "usb424,2513";
+		reg = <1>;
+		reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+		reset-duration-us = <3000>;
+	};
 };
 
 &usbotg {
@@ -467,11 +461,6 @@
 			MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
 			/* usbh1_b OC */
 			MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
-		>;
-	};
-
-	pinctrl_usbh1_hubreset: usbh1hubresetgrp {
-		fsl,pins = <
 			MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
 		>;
 	};
-- 
1.9.1

[PATCH v6 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line

[Peter Chen]

From: Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group

Signed-off-by: Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
---
 arch/arm/boot/dts/imx6q-evi.dts | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 4fa5601..49c6f61 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
 		reg = <0x10000000 0x40000000>;
 	};
 
-	reg_usbh1_vbus: regulator-usbhubreset {
-		compatible = "regulator-fixed";
-		regulator-name = "usbh1_vbus";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		enable-active-high;
-		startup-delay-us = <2>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbh1_hubreset>;
-		gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
-	};
-
 	reg_usb_otg_vbus: regulator-usbotgvbus {
 		compatible = "regulator-fixed";
 		regulator-name = "usb_otg_vbus";
@@ -204,12 +192,18 @@
 };
 
 &usbh1 {
-	vbus-supply = <&reg_usbh1_vbus>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usbh1>;
 	dr_mode = "host";
 	disable-over-current;
 	status = "okay";
+
+	usb2415host: hub@1 {
+		compatible = "usb424,2513";
+		reg = <1>;
+		reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+		reset-duration-us = <3000>;
+	};
 };
 
 &usbotg {
@@ -467,11 +461,6 @@
 			MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
 			/* usbh1_b OC */
 			MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
-		>;
-	};
-
-	pinctrl_usbh1_hubreset: usbh1hubresetgrp {
-		fsl,pins = <
 			MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
 		>;
 	};
-- 
1.9.1

--
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 v6 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line

[Peter Chen]

From: Joshua Clayton <stillcompiling@gmail.com>

Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group

Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
 arch/arm/boot/dts/imx6q-evi.dts | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 4fa5601..49c6f61 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
 		reg = <0x10000000 0x40000000>;
 	};
 
-	reg_usbh1_vbus: regulator-usbhubreset {
-		compatible = "regulator-fixed";
-		regulator-name = "usbh1_vbus";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		enable-active-high;
-		startup-delay-us = <2>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbh1_hubreset>;
-		gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
-	};
-
 	reg_usb_otg_vbus: regulator-usbotgvbus {
 		compatible = "regulator-fixed";
 		regulator-name = "usb_otg_vbus";
@@ -204,12 +192,18 @@
 };
 
 &usbh1 {
-	vbus-supply = <&reg_usbh1_vbus>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usbh1>;
 	dr_mode = "host";
 	disable-over-current;
 	status = "okay";
+
+	usb2415host: hub at 1 {
+		compatible = "usb424,2513";
+		reg = <1>;
+		reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+		reset-duration-us = <3000>;
+	};
 };
 
 &usbotg {
@@ -467,11 +461,6 @@
 			MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
 			/* usbh1_b OC */
 			MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
-		>;
-	};
-
-	pinctrl_usbh1_hubreset: usbh1hubresetgrp {
-		fsl,pins = <
 			MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
 		>;
 	};
-- 
1.9.1

Re: [PATCH v6 2/8] power: add power sequence library

[Peter Chen]

On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
> 
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
> 
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver calls pwrseq_alloc_generic to create
> an generic pwrseq instance.
> 
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>

Hi Greg, Sebastian, Dmitry, and David

I find the code under drivers/power have several subsystems.
Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
Or can go the Greg's tree?

Peter

> ---
>  MAINTAINERS                           |   9 ++
>  drivers/power/Kconfig                 |   1 +
>  drivers/power/Makefile                |   1 +
>  drivers/power/pwrseq/Kconfig          |  20 ++++
>  drivers/power/pwrseq/Makefile         |   2 +
>  drivers/power/pwrseq/core.c           |  62 +++++++++++++
>  drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
>  include/linux/power/pwrseq.h          |  47 ++++++++++
>  8 files changed, 310 insertions(+)
>  create mode 100644 drivers/power/pwrseq/Kconfig
>  create mode 100644 drivers/power/pwrseq/Makefile
>  create mode 100644 drivers/power/pwrseq/core.c
>  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>  create mode 100644 include/linux/power/pwrseq.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ae6c84..407254b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
>  F:	include/linux/powercap.h
>  F:	drivers/powercap/
>  
> +POWER SEQUENCE LIBRARY
> +M:	Peter Chen <Peter.Chen@nxp.com>
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L:	linux-pm@vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/power/pwrseq/
> +F:	drivers/power/pwrseq/
> +F:	include/linux/power/pwrseq.h/
> +
>  POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
>  M:	Sebastian Reichel <sre@kernel.org>
>  M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index acd4a15..f6aa4fd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -515,3 +515,4 @@ endif # POWER_SUPPLY
>  
>  source "drivers/power/reset/Kconfig"
>  source "drivers/power/avs/Kconfig"
> +source "drivers/power/pwrseq/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..4ed2e12 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
>  obj-$(CONFIG_POWER_RESET)	+= reset/
>  obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>  obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
> +obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..188729e
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,20 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> +	bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> +	bool "Generic power sequence control"
> +	depends on OF
> +	select POWER_SEQUENCE
> +	help
> +	  It is used for drivers which needs to do power sequence
> +	  (eg, turn on clock, toggle reset gpio) before the related
> +	  devices can be found by hardware. This generic one can be
> +	  used for common power sequence control.
> +
> +endmenu
> diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
> new file mode 100644
> index 0000000..ad82389
> --- /dev/null
> +++ b/drivers/power/pwrseq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQUENCE) += core.o
> +obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
> diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
> new file mode 100644
> index 0000000..dcf96c4
> --- /dev/null
> +++ b/drivers/power/pwrseq/core.c
> @@ -0,0 +1,62 @@
> +/*
> + * core.c	power sequence core file
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/power/pwrseq.h>
> +
> +static DEFINE_MUTEX(pwrseq_list_mutex);
> +static LIST_HEAD(pwrseq_list);
> +
> +int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->get)
> +		return p->get(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_get);
> +
> +int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->on)
> +		return p->on(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_on);
> +
> +void pwrseq_off(struct pwrseq *p)
> +{
> +	if (p && p->off)
> +		p->off(p);
> +}
> +EXPORT_SYMBOL(pwrseq_off);
> +
> +void pwrseq_put(struct pwrseq *p)
> +{
> +	if (p && p->put)
> +		p->put(p);
> +}
> +EXPORT_SYMBOL(pwrseq_put);
> +
> +void pwrseq_free(struct pwrseq *p)
> +{
> +	if (p && p->free)
> +		p->free(p);
> +}
> +EXPORT_SYMBOL(pwrseq_free);
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
> new file mode 100644
> index 0000000..8af626f
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
> @@ -0,0 +1,168 @@
> +/*
> + * pwrseq_generic.c	Generic power sequence handling
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/slab.h>
> +
> +#include <linux/power/pwrseq.h>
> +
> +struct pwrseq_generic {
> +	struct pwrseq pwrseq;
> +	struct gpio_desc *gpiod_reset;
> +	struct clk *clks[PWRSEQ_MAX_CLKS];
> +};
> +
> +#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
> +
> +static void pwrseq_generic_free(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +
> +	kfree(pwrseq_gen);
> +}
> +
> +static void pwrseq_generic_put(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	if (pwrseq_gen->gpiod_reset)
> +		gpiod_put(pwrseq_gen->gpiod_reset);
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
> +		clk_put(pwrseq_gen->clks[clk]);
> +}
> +
> +static void pwrseq_generic_off(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +}
> +
> +static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk, ret = 0;
> +	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
> +		if (ret) {
> +			pr_err("Can't enable clock on %s: %d\n",
> +				np->full_name, ret);
> +			goto err_disable_clks;
> +		}
> +	}
> +
> +	if (gpiod_reset) {
> +		u32 duration_us = 50;
> +
> +		of_property_read_u32(np, "reset-duration-us",
> +				&duration_us);
> +		if (duration_us <= 10)
> +			udelay(10);
> +		else
> +			usleep_range(duration_us, duration_us + 100);
> +		gpiod_set_value(gpiod_reset, 0);
> +	}
> +
> +	return ret;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +
> +	return ret;
> +}
> +
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	enum of_gpio_flags flags;
> +	int reset_gpio, clk, ret = 0;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> +		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> +		if (IS_ERR(pwrseq_gen->clks[clk])) {
> +			ret = PTR_ERR(pwrseq_gen->clks[clk]);
> +			if (ret == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			pwrseq_gen->clks[clk] = NULL;
> +			break;
> +		}
> +	}
> +
> +	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> +	if (gpio_is_valid(reset_gpio)) {
> +		unsigned long gpio_flags;
> +
> +		if (flags & OF_GPIO_ACTIVE_LOW)
> +			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> +		else
> +			gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> +		ret = gpio_request_one(reset_gpio, gpio_flags,
> +				"pwrseq-reset-gpios");
> +		if (ret)
> +			goto err_put_clks;
> +
> +		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> +	} else {
> +		if (reset_gpio == -ENOENT)
> +			return 0;
> +
> +		ret = reset_gpio;
> +		pr_err("Failed to get reset gpio on %s, err = %d\n",
> +				np->full_name, reset_gpio);
> +		goto err_put_clks;
> +	}
> +
> +	return ret;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(pwrseq_gen->clks[clk]);
> +	return ret;
> +}
> +
> +struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	struct pwrseq_generic *pwrseq_gen;
> +
> +	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> +	if (!pwrseq_gen)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> +	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> +	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> +	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> +	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> +	return &pwrseq_gen->pwrseq;
> +}
> +EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
> diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
> new file mode 100644
> index 0000000..ebb2280
> --- /dev/null
> +++ b/include/linux/power/pwrseq.h
> @@ -0,0 +1,47 @@
> +#ifndef __LINUX_PWRSEQ_H
> +#define __LINUX_PWRSEQ_H
> +
> +#include <linux/of.h>
> +
> +#define PWRSEQ_MAX_CLKS		3
> +
> +struct pwrseq {
> +	char *name;
> +	struct list_head node;
> +	int (*get)(struct device_node *np, struct pwrseq *p);
> +	int (*on)(struct device_node *np, struct pwrseq *p);
> +	void (*off)(struct pwrseq *p);
> +	void (*put)(struct pwrseq *p);
> +	void (*free)(struct pwrseq *p);
> +};
> +
> +#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
> +int pwrseq_get(struct device_node *np, struct pwrseq *p);
> +int pwrseq_on(struct device_node *np, struct pwrseq *p);
> +void pwrseq_off(struct pwrseq *p);
> +void pwrseq_put(struct pwrseq *p);
> +void pwrseq_free(struct pwrseq *p);
> +#else
> +static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline void pwrseq_off(struct pwrseq *p) {}
> +static inline void pwrseq_put(struct pwrseq *p) {}
> +static inline void pwrseq_free(struct pwrseq *p) {}
> +#endif /* CONFIG_POWER_SEQUENCE */
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +struct pwrseq *pwrseq_alloc_generic(void);
> +#else
> +static inline struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> +
> +#endif  /* __LINUX_PWRSEQ_H */
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 2/8] power: add power sequence library

[Peter Chen]

On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
> 
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
> 
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver calls pwrseq_alloc_generic to create
> an generic pwrseq instance.
> 
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>

Hi Greg, Sebastian, Dmitry, and David

I find the code under drivers/power have several subsystems.
Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
Or can go the Greg's tree?

Peter

> ---
>  MAINTAINERS                           |   9 ++
>  drivers/power/Kconfig                 |   1 +
>  drivers/power/Makefile                |   1 +
>  drivers/power/pwrseq/Kconfig          |  20 ++++
>  drivers/power/pwrseq/Makefile         |   2 +
>  drivers/power/pwrseq/core.c           |  62 +++++++++++++
>  drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
>  include/linux/power/pwrseq.h          |  47 ++++++++++
>  8 files changed, 310 insertions(+)
>  create mode 100644 drivers/power/pwrseq/Kconfig
>  create mode 100644 drivers/power/pwrseq/Makefile
>  create mode 100644 drivers/power/pwrseq/core.c
>  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>  create mode 100644 include/linux/power/pwrseq.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ae6c84..407254b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
>  F:	include/linux/powercap.h
>  F:	drivers/powercap/
>  
> +POWER SEQUENCE LIBRARY
> +M:	Peter Chen <Peter.Chen@nxp.com>
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L:	linux-pm@vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/power/pwrseq/
> +F:	drivers/power/pwrseq/
> +F:	include/linux/power/pwrseq.h/
> +
>  POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
>  M:	Sebastian Reichel <sre@kernel.org>
>  M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index acd4a15..f6aa4fd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -515,3 +515,4 @@ endif # POWER_SUPPLY
>  
>  source "drivers/power/reset/Kconfig"
>  source "drivers/power/avs/Kconfig"
> +source "drivers/power/pwrseq/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..4ed2e12 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
>  obj-$(CONFIG_POWER_RESET)	+= reset/
>  obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>  obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
> +obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..188729e
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,20 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> +	bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> +	bool "Generic power sequence control"
> +	depends on OF
> +	select POWER_SEQUENCE
> +	help
> +	  It is used for drivers which needs to do power sequence
> +	  (eg, turn on clock, toggle reset gpio) before the related
> +	  devices can be found by hardware. This generic one can be
> +	  used for common power sequence control.
> +
> +endmenu
> diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
> new file mode 100644
> index 0000000..ad82389
> --- /dev/null
> +++ b/drivers/power/pwrseq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQUENCE) += core.o
> +obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
> diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
> new file mode 100644
> index 0000000..dcf96c4
> --- /dev/null
> +++ b/drivers/power/pwrseq/core.c
> @@ -0,0 +1,62 @@
> +/*
> + * core.c	power sequence core file
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/power/pwrseq.h>
> +
> +static DEFINE_MUTEX(pwrseq_list_mutex);
> +static LIST_HEAD(pwrseq_list);
> +
> +int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->get)
> +		return p->get(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_get);
> +
> +int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->on)
> +		return p->on(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_on);
> +
> +void pwrseq_off(struct pwrseq *p)
> +{
> +	if (p && p->off)
> +		p->off(p);
> +}
> +EXPORT_SYMBOL(pwrseq_off);
> +
> +void pwrseq_put(struct pwrseq *p)
> +{
> +	if (p && p->put)
> +		p->put(p);
> +}
> +EXPORT_SYMBOL(pwrseq_put);
> +
> +void pwrseq_free(struct pwrseq *p)
> +{
> +	if (p && p->free)
> +		p->free(p);
> +}
> +EXPORT_SYMBOL(pwrseq_free);
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
> new file mode 100644
> index 0000000..8af626f
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
> @@ -0,0 +1,168 @@
> +/*
> + * pwrseq_generic.c	Generic power sequence handling
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/slab.h>
> +
> +#include <linux/power/pwrseq.h>
> +
> +struct pwrseq_generic {
> +	struct pwrseq pwrseq;
> +	struct gpio_desc *gpiod_reset;
> +	struct clk *clks[PWRSEQ_MAX_CLKS];
> +};
> +
> +#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
> +
> +static void pwrseq_generic_free(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +
> +	kfree(pwrseq_gen);
> +}
> +
> +static void pwrseq_generic_put(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	if (pwrseq_gen->gpiod_reset)
> +		gpiod_put(pwrseq_gen->gpiod_reset);
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
> +		clk_put(pwrseq_gen->clks[clk]);
> +}
> +
> +static void pwrseq_generic_off(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +}
> +
> +static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk, ret = 0;
> +	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
> +		if (ret) {
> +			pr_err("Can't enable clock on %s: %d\n",
> +				np->full_name, ret);
> +			goto err_disable_clks;
> +		}
> +	}
> +
> +	if (gpiod_reset) {
> +		u32 duration_us = 50;
> +
> +		of_property_read_u32(np, "reset-duration-us",
> +				&duration_us);
> +		if (duration_us <= 10)
> +			udelay(10);
> +		else
> +			usleep_range(duration_us, duration_us + 100);
> +		gpiod_set_value(gpiod_reset, 0);
> +	}
> +
> +	return ret;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +
> +	return ret;
> +}
> +
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	enum of_gpio_flags flags;
> +	int reset_gpio, clk, ret = 0;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> +		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> +		if (IS_ERR(pwrseq_gen->clks[clk])) {
> +			ret = PTR_ERR(pwrseq_gen->clks[clk]);
> +			if (ret == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			pwrseq_gen->clks[clk] = NULL;
> +			break;
> +		}
> +	}
> +
> +	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> +	if (gpio_is_valid(reset_gpio)) {
> +		unsigned long gpio_flags;
> +
> +		if (flags & OF_GPIO_ACTIVE_LOW)
> +			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> +		else
> +			gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> +		ret = gpio_request_one(reset_gpio, gpio_flags,
> +				"pwrseq-reset-gpios");
> +		if (ret)
> +			goto err_put_clks;
> +
> +		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> +	} else {
> +		if (reset_gpio == -ENOENT)
> +			return 0;
> +
> +		ret = reset_gpio;
> +		pr_err("Failed to get reset gpio on %s, err = %d\n",
> +				np->full_name, reset_gpio);
> +		goto err_put_clks;
> +	}
> +
> +	return ret;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(pwrseq_gen->clks[clk]);
> +	return ret;
> +}
> +
> +struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	struct pwrseq_generic *pwrseq_gen;
> +
> +	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> +	if (!pwrseq_gen)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> +	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> +	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> +	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> +	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> +	return &pwrseq_gen->pwrseq;
> +}
> +EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
> diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
> new file mode 100644
> index 0000000..ebb2280
> --- /dev/null
> +++ b/include/linux/power/pwrseq.h
> @@ -0,0 +1,47 @@
> +#ifndef __LINUX_PWRSEQ_H
> +#define __LINUX_PWRSEQ_H
> +
> +#include <linux/of.h>
> +
> +#define PWRSEQ_MAX_CLKS		3
> +
> +struct pwrseq {
> +	char *name;
> +	struct list_head node;
> +	int (*get)(struct device_node *np, struct pwrseq *p);
> +	int (*on)(struct device_node *np, struct pwrseq *p);
> +	void (*off)(struct pwrseq *p);
> +	void (*put)(struct pwrseq *p);
> +	void (*free)(struct pwrseq *p);
> +};
> +
> +#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
> +int pwrseq_get(struct device_node *np, struct pwrseq *p);
> +int pwrseq_on(struct device_node *np, struct pwrseq *p);
> +void pwrseq_off(struct pwrseq *p);
> +void pwrseq_put(struct pwrseq *p);
> +void pwrseq_free(struct pwrseq *p);
> +#else
> +static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline void pwrseq_off(struct pwrseq *p) {}
> +static inline void pwrseq_put(struct pwrseq *p) {}
> +static inline void pwrseq_free(struct pwrseq *p) {}
> +#endif /* CONFIG_POWER_SEQUENCE */
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +struct pwrseq *pwrseq_alloc_generic(void);
> +#else
> +static inline struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> +
> +#endif  /* __LINUX_PWRSEQ_H */
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[PATCH v6 2/8] power: add power sequence library

[Peter Chen]

On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
> 
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
> 
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver calls pwrseq_alloc_generic to create
> an generic pwrseq instance.
> 
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>

Hi Greg, Sebastian, Dmitry, and David

I find the code under drivers/power have several subsystems.
Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
Or can go the Greg's tree?

Peter

> ---
>  MAINTAINERS                           |   9 ++
>  drivers/power/Kconfig                 |   1 +
>  drivers/power/Makefile                |   1 +
>  drivers/power/pwrseq/Kconfig          |  20 ++++
>  drivers/power/pwrseq/Makefile         |   2 +
>  drivers/power/pwrseq/core.c           |  62 +++++++++++++
>  drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
>  include/linux/power/pwrseq.h          |  47 ++++++++++
>  8 files changed, 310 insertions(+)
>  create mode 100644 drivers/power/pwrseq/Kconfig
>  create mode 100644 drivers/power/pwrseq/Makefile
>  create mode 100644 drivers/power/pwrseq/core.c
>  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>  create mode 100644 include/linux/power/pwrseq.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ae6c84..407254b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
>  F:	include/linux/powercap.h
>  F:	drivers/powercap/
>  
> +POWER SEQUENCE LIBRARY
> +M:	Peter Chen <Peter.Chen@nxp.com>
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L:	linux-pm at vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/power/pwrseq/
> +F:	drivers/power/pwrseq/
> +F:	include/linux/power/pwrseq.h/
> +
>  POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
>  M:	Sebastian Reichel <sre@kernel.org>
>  M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index acd4a15..f6aa4fd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -515,3 +515,4 @@ endif # POWER_SUPPLY
>  
>  source "drivers/power/reset/Kconfig"
>  source "drivers/power/avs/Kconfig"
> +source "drivers/power/pwrseq/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..4ed2e12 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
>  obj-$(CONFIG_POWER_RESET)	+= reset/
>  obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>  obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
> +obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..188729e
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,20 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> +	bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> +	bool "Generic power sequence control"
> +	depends on OF
> +	select POWER_SEQUENCE
> +	help
> +	  It is used for drivers which needs to do power sequence
> +	  (eg, turn on clock, toggle reset gpio) before the related
> +	  devices can be found by hardware. This generic one can be
> +	  used for common power sequence control.
> +
> +endmenu
> diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
> new file mode 100644
> index 0000000..ad82389
> --- /dev/null
> +++ b/drivers/power/pwrseq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQUENCE) += core.o
> +obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
> diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
> new file mode 100644
> index 0000000..dcf96c4
> --- /dev/null
> +++ b/drivers/power/pwrseq/core.c
> @@ -0,0 +1,62 @@
> +/*
> + * core.c	power sequence core file
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/power/pwrseq.h>
> +
> +static DEFINE_MUTEX(pwrseq_list_mutex);
> +static LIST_HEAD(pwrseq_list);
> +
> +int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->get)
> +		return p->get(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_get);
> +
> +int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->on)
> +		return p->on(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_on);
> +
> +void pwrseq_off(struct pwrseq *p)
> +{
> +	if (p && p->off)
> +		p->off(p);
> +}
> +EXPORT_SYMBOL(pwrseq_off);
> +
> +void pwrseq_put(struct pwrseq *p)
> +{
> +	if (p && p->put)
> +		p->put(p);
> +}
> +EXPORT_SYMBOL(pwrseq_put);
> +
> +void pwrseq_free(struct pwrseq *p)
> +{
> +	if (p && p->free)
> +		p->free(p);
> +}
> +EXPORT_SYMBOL(pwrseq_free);
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
> new file mode 100644
> index 0000000..8af626f
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
> @@ -0,0 +1,168 @@
> +/*
> + * pwrseq_generic.c	Generic power sequence handling
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/slab.h>
> +
> +#include <linux/power/pwrseq.h>
> +
> +struct pwrseq_generic {
> +	struct pwrseq pwrseq;
> +	struct gpio_desc *gpiod_reset;
> +	struct clk *clks[PWRSEQ_MAX_CLKS];
> +};
> +
> +#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
> +
> +static void pwrseq_generic_free(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +
> +	kfree(pwrseq_gen);
> +}
> +
> +static void pwrseq_generic_put(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	if (pwrseq_gen->gpiod_reset)
> +		gpiod_put(pwrseq_gen->gpiod_reset);
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
> +		clk_put(pwrseq_gen->clks[clk]);
> +}
> +
> +static void pwrseq_generic_off(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +}
> +
> +static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk, ret = 0;
> +	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
> +		if (ret) {
> +			pr_err("Can't enable clock on %s: %d\n",
> +				np->full_name, ret);
> +			goto err_disable_clks;
> +		}
> +	}
> +
> +	if (gpiod_reset) {
> +		u32 duration_us = 50;
> +
> +		of_property_read_u32(np, "reset-duration-us",
> +				&duration_us);
> +		if (duration_us <= 10)
> +			udelay(10);
> +		else
> +			usleep_range(duration_us, duration_us + 100);
> +		gpiod_set_value(gpiod_reset, 0);
> +	}
> +
> +	return ret;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +
> +	return ret;
> +}
> +
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	enum of_gpio_flags flags;
> +	int reset_gpio, clk, ret = 0;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> +		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> +		if (IS_ERR(pwrseq_gen->clks[clk])) {
> +			ret = PTR_ERR(pwrseq_gen->clks[clk]);
> +			if (ret == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			pwrseq_gen->clks[clk] = NULL;
> +			break;
> +		}
> +	}
> +
> +	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> +	if (gpio_is_valid(reset_gpio)) {
> +		unsigned long gpio_flags;
> +
> +		if (flags & OF_GPIO_ACTIVE_LOW)
> +			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> +		else
> +			gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> +		ret = gpio_request_one(reset_gpio, gpio_flags,
> +				"pwrseq-reset-gpios");
> +		if (ret)
> +			goto err_put_clks;
> +
> +		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> +	} else {
> +		if (reset_gpio == -ENOENT)
> +			return 0;
> +
> +		ret = reset_gpio;
> +		pr_err("Failed to get reset gpio on %s, err = %d\n",
> +				np->full_name, reset_gpio);
> +		goto err_put_clks;
> +	}
> +
> +	return ret;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(pwrseq_gen->clks[clk]);
> +	return ret;
> +}
> +
> +struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	struct pwrseq_generic *pwrseq_gen;
> +
> +	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> +	if (!pwrseq_gen)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> +	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> +	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> +	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> +	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> +	return &pwrseq_gen->pwrseq;
> +}
> +EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
> diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
> new file mode 100644
> index 0000000..ebb2280
> --- /dev/null
> +++ b/include/linux/power/pwrseq.h
> @@ -0,0 +1,47 @@
> +#ifndef __LINUX_PWRSEQ_H
> +#define __LINUX_PWRSEQ_H
> +
> +#include <linux/of.h>
> +
> +#define PWRSEQ_MAX_CLKS		3
> +
> +struct pwrseq {
> +	char *name;
> +	struct list_head node;
> +	int (*get)(struct device_node *np, struct pwrseq *p);
> +	int (*on)(struct device_node *np, struct pwrseq *p);
> +	void (*off)(struct pwrseq *p);
> +	void (*put)(struct pwrseq *p);
> +	void (*free)(struct pwrseq *p);
> +};
> +
> +#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
> +int pwrseq_get(struct device_node *np, struct pwrseq *p);
> +int pwrseq_on(struct device_node *np, struct pwrseq *p);
> +void pwrseq_off(struct pwrseq *p);
> +void pwrseq_put(struct pwrseq *p);
> +void pwrseq_free(struct pwrseq *p);
> +#else
> +static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline void pwrseq_off(struct pwrseq *p) {}
> +static inline void pwrseq_put(struct pwrseq *p) {}
> +static inline void pwrseq_free(struct pwrseq *p) {}
> +#endif /* CONFIG_POWER_SEQUENCE */
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +struct pwrseq *pwrseq_alloc_generic(void);
> +#else
> +static inline struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> +
> +#endif  /* __LINUX_PWRSEQ_H */
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

On Mon, Aug 15, 2016 at 05:13:14PM +0800, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
> 
> In this patch, it calls power sequence library APIs to finish
> the power sequence events. At first, it calls pwrseq_alloc_generic
> to create a generic power sequence instance, then it will do power
> on sequence at hub's probe for all devices under this hub
> (includes root hub).
> 
> At hub_disconnect, it will do power off sequence which is at powered
> on list.
> 
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>

Hi Alan,

The power sequence library code has been reviewed several rounds, would
you please help to review the change for USB part?

Peter

> ---
>  drivers/usb/core/Makefile |   1 +
>  drivers/usb/core/hub.c    |  12 ++++--
>  drivers/usb/core/hub.h    |  12 ++++++
>  drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 122 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/usb/core/pwrseq.c
> 
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 9780877..39f2149 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
>  
>  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
>  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
>  
>  obj-$(CONFIG_USB)		+= usbcore.o
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bee1351..a346a8b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
>  	hub->error = 0;
>  	hub_quiesce(hub, HUB_DISCONNECT);
>  
> +	hub_pwrseq_off(hub);
>  	mutex_lock(&usb_port_peer_mutex);
>  
>  	/* Avoid races with recursively_mark_NOTATTACHED() */
> @@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
>  	struct usb_endpoint_descriptor *endpoint;
>  	struct usb_device *hdev;
>  	struct usb_hub *hub;
> +	int ret = -ENODEV;
>  
>  	desc = intf->cur_altsetting;
>  	hdev = interface_to_usbdev(intf);
> @@ -1839,6 +1841,7 @@ descriptor_error:
>  	INIT_DELAYED_WORK(&hub->leds, led_work);
>  	INIT_DELAYED_WORK(&hub->init_work, NULL);
>  	INIT_WORK(&hub->events, hub_event);
> +	INIT_LIST_HEAD(&hub->pwrseq_on_list);
>  	usb_get_intf(intf);
>  	usb_get_dev(hdev);
>  
> @@ -1852,11 +1855,14 @@ descriptor_error:
>  	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
>  		hub->quirk_check_port_auto_suspend = 1;
>  
> -	if (hub_configure(hub, endpoint) >= 0)
> -		return 0;
> +	if (hub_configure(hub, endpoint) >= 0) {
> +		ret = hub_pwrseq_on(hub);
> +		if (!ret)
> +			return 0;
> +	}
>  
>  	hub_disconnect(intf);
> -	return -ENODEV;
> +	return ret;
>  }
>  
>  static int
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 34c1a7e..9473f6f 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -78,6 +78,7 @@ struct usb_hub {
>  	struct delayed_work	init_work;
>  	struct work_struct      events;
>  	struct usb_port		**ports;
> +	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
>  };
>  
>  /**
> @@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
>  {
>  	return hub_port_debounce(hub, port1, false);
>  }
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +int hub_pwrseq_on(struct usb_hub *hub);
> +void hub_pwrseq_off(struct usb_hub *hub);
> +#else
> +static inline int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	return 0;
> +}
> +static inline void hub_pwrseq_off(struct usb_hub *hub) {}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
> new file mode 100644
> index 0000000..837fe66
> --- /dev/null
> +++ b/drivers/usb/core/pwrseq.c
> @@ -0,0 +1,100 @@
> +/*
> + * pwrseq.c	USB device power sequence management
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/power/pwrseq.h>
> +#include <linux/slab.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#include "hub.h"
> +
> +struct usb_pwrseq_node {
> +	struct pwrseq *pwrseq;
> +	struct list_head list;
> +};
> +
> +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node;
> +	int ret;
> +
> +	pwrseq = pwrseq_alloc_generic();
> +	if (IS_ERR(pwrseq))
> +		return PTR_ERR(pwrseq);
> +
> +	ret = pwrseq_get(np, pwrseq);
> +	if (ret)
> +		goto pwr_free;
> +
> +	ret = pwrseq_on(np, pwrseq);
> +	if (ret)
> +		goto pwr_put;
> +
> +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
> +	pwrseq_node->pwrseq = pwrseq;
> +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> +
> +	return 0;
> +
> +pwr_put:
> +	pwrseq_put(pwrseq);
> +pwr_free:
> +	pwrseq_free(pwrseq);
> +	return ret;
> +}
> +
> +int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	struct device *parent;
> +	struct usb_device *hdev = hub->hdev;
> +	struct device_node *np;
> +	int ret;
> +
> +	if (hdev->parent)
> +		parent = &hdev->dev;
> +	else
> +		parent = bus_to_hcd(hdev->bus)->self.controller;
> +
> +	for_each_child_of_node(parent->of_node, np) {
> +		ret = hub_of_pwrseq_on(np, hub);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +void hub_pwrseq_off(struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
> +
> +	list_for_each_entry_safe(pwrseq_node, tmp_node,
> +			&hub->pwrseq_on_list, list) {
> +		pwrseq = pwrseq_node->pwrseq;
> +		pwrseq_off(pwrseq);
> +		pwrseq_put(pwrseq);
> +		pwrseq_free(pwrseq);
> +		list_del(&pwrseq_node->list);
> +		kfree(pwrseq_node);
> +	}
> +}
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

On Mon, Aug 15, 2016 at 05:13:14PM +0800, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
> 
> In this patch, it calls power sequence library APIs to finish
> the power sequence events. At first, it calls pwrseq_alloc_generic
> to create a generic power sequence instance, then it will do power
> on sequence at hub's probe for all devices under this hub
> (includes root hub).
> 
> At hub_disconnect, it will do power off sequence which is at powered
> on list.
> 
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>

Hi Alan,

The power sequence library code has been reviewed several rounds, would
you please help to review the change for USB part?

Peter

> ---
>  drivers/usb/core/Makefile |   1 +
>  drivers/usb/core/hub.c    |  12 ++++--
>  drivers/usb/core/hub.h    |  12 ++++++
>  drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 122 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/usb/core/pwrseq.c
> 
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 9780877..39f2149 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
>  
>  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
>  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
>  
>  obj-$(CONFIG_USB)		+= usbcore.o
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bee1351..a346a8b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
>  	hub->error = 0;
>  	hub_quiesce(hub, HUB_DISCONNECT);
>  
> +	hub_pwrseq_off(hub);
>  	mutex_lock(&usb_port_peer_mutex);
>  
>  	/* Avoid races with recursively_mark_NOTATTACHED() */
> @@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
>  	struct usb_endpoint_descriptor *endpoint;
>  	struct usb_device *hdev;
>  	struct usb_hub *hub;
> +	int ret = -ENODEV;
>  
>  	desc = intf->cur_altsetting;
>  	hdev = interface_to_usbdev(intf);
> @@ -1839,6 +1841,7 @@ descriptor_error:
>  	INIT_DELAYED_WORK(&hub->leds, led_work);
>  	INIT_DELAYED_WORK(&hub->init_work, NULL);
>  	INIT_WORK(&hub->events, hub_event);
> +	INIT_LIST_HEAD(&hub->pwrseq_on_list);
>  	usb_get_intf(intf);
>  	usb_get_dev(hdev);
>  
> @@ -1852,11 +1855,14 @@ descriptor_error:
>  	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
>  		hub->quirk_check_port_auto_suspend = 1;
>  
> -	if (hub_configure(hub, endpoint) >= 0)
> -		return 0;
> +	if (hub_configure(hub, endpoint) >= 0) {
> +		ret = hub_pwrseq_on(hub);
> +		if (!ret)
> +			return 0;
> +	}
>  
>  	hub_disconnect(intf);
> -	return -ENODEV;
> +	return ret;
>  }
>  
>  static int
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 34c1a7e..9473f6f 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -78,6 +78,7 @@ struct usb_hub {
>  	struct delayed_work	init_work;
>  	struct work_struct      events;
>  	struct usb_port		**ports;
> +	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
>  };
>  
>  /**
> @@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
>  {
>  	return hub_port_debounce(hub, port1, false);
>  }
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +int hub_pwrseq_on(struct usb_hub *hub);
> +void hub_pwrseq_off(struct usb_hub *hub);
> +#else
> +static inline int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	return 0;
> +}
> +static inline void hub_pwrseq_off(struct usb_hub *hub) {}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
> new file mode 100644
> index 0000000..837fe66
> --- /dev/null
> +++ b/drivers/usb/core/pwrseq.c
> @@ -0,0 +1,100 @@
> +/*
> + * pwrseq.c	USB device power sequence management
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/power/pwrseq.h>
> +#include <linux/slab.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#include "hub.h"
> +
> +struct usb_pwrseq_node {
> +	struct pwrseq *pwrseq;
> +	struct list_head list;
> +};
> +
> +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node;
> +	int ret;
> +
> +	pwrseq = pwrseq_alloc_generic();
> +	if (IS_ERR(pwrseq))
> +		return PTR_ERR(pwrseq);
> +
> +	ret = pwrseq_get(np, pwrseq);
> +	if (ret)
> +		goto pwr_free;
> +
> +	ret = pwrseq_on(np, pwrseq);
> +	if (ret)
> +		goto pwr_put;
> +
> +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
> +	pwrseq_node->pwrseq = pwrseq;
> +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> +
> +	return 0;
> +
> +pwr_put:
> +	pwrseq_put(pwrseq);
> +pwr_free:
> +	pwrseq_free(pwrseq);
> +	return ret;
> +}
> +
> +int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	struct device *parent;
> +	struct usb_device *hdev = hub->hdev;
> +	struct device_node *np;
> +	int ret;
> +
> +	if (hdev->parent)
> +		parent = &hdev->dev;
> +	else
> +		parent = bus_to_hcd(hdev->bus)->self.controller;
> +
> +	for_each_child_of_node(parent->of_node, np) {
> +		ret = hub_of_pwrseq_on(np, hub);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +void hub_pwrseq_off(struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
> +
> +	list_for_each_entry_safe(pwrseq_node, tmp_node,
> +			&hub->pwrseq_on_list, list) {
> +		pwrseq = pwrseq_node->pwrseq;
> +		pwrseq_off(pwrseq);
> +		pwrseq_put(pwrseq);
> +		pwrseq_free(pwrseq);
> +		list_del(&pwrseq_node->list);
> +		kfree(pwrseq_node);
> +	}
> +}
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 2/8] power: add power sequence library

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

Hi Peter,

On Mon, Aug 22, 2016 at 02:51:58PM +0800, Peter Chen wrote:
> On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> > We have an well-known problem that the device needs to do some power
> > sequence before it can be recognized by related host, the typical
> > example like hard-wired mmc devices and usb devices.
> > 
> > This power sequence is hard to be described at device tree and handled by
> > related host driver, so we have created a common power sequence
> > library to cover this requirement. The core code has supplied
> > some common helpers for host driver, and individual power sequence
> > libraries handle kinds of power sequence for devices.
> > 
> > pwrseq_generic is intended for general purpose of power sequence, which
> > handles gpios and clocks currently, and can cover regulator and pinctrl
> > in future. The host driver calls pwrseq_alloc_generic to create
> > an generic pwrseq instance.
> > 
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > Tested-by Joshua Clayton <stillcompiling@gmail.com>
> > Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> > Tested-by: Matthias Kaehlcke <mka@chromium.org>
> 
> Hi Greg, Sebastian, Dmitry, and David
> 
> I find the code under drivers/power have several subsystems.
> Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
> Or can go the Greg's tree?

I think this does not really fit into the power-supply tree.
I would expect this to go through Rafael's linux-pm tree.

Note: I moved all the power-supply code into drivers/power/supply/
in linux-next, among other things because of this patchset. To avoid
merge conflicts in drivers/power/Makefile and drivers/power/Kconfig
the tree pulling this patchset should also pull a (yet to be
created) immutable branch containing
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/drivers/power?h=for-next&id=8c0984e5a75337df513047ec92a6c09d78e3e5cd

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH v6 2/8] power: add power sequence library

[Sebastian Reichel]

Hi Peter,

On Mon, Aug 22, 2016 at 02:51:58PM +0800, Peter Chen wrote:
> On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> > We have an well-known problem that the device needs to do some power
> > sequence before it can be recognized by related host, the typical
> > example like hard-wired mmc devices and usb devices.
> > 
> > This power sequence is hard to be described at device tree and handled by
> > related host driver, so we have created a common power sequence
> > library to cover this requirement. The core code has supplied
> > some common helpers for host driver, and individual power sequence
> > libraries handle kinds of power sequence for devices.
> > 
> > pwrseq_generic is intended for general purpose of power sequence, which
> > handles gpios and clocks currently, and can cover regulator and pinctrl
> > in future. The host driver calls pwrseq_alloc_generic to create
> > an generic pwrseq instance.
> > 
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > Tested-by Joshua Clayton <stillcompiling@gmail.com>
> > Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> > Tested-by: Matthias Kaehlcke <mka@chromium.org>
> 
> Hi Greg, Sebastian, Dmitry, and David
> 
> I find the code under drivers/power have several subsystems.
> Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
> Or can go the Greg's tree?

I think this does not really fit into the power-supply tree.
I would expect this to go through Rafael's linux-pm tree.

Note: I moved all the power-supply code into drivers/power/supply/
in linux-next, among other things because of this patchset. To avoid
merge conflicts in drivers/power/Makefile and drivers/power/Kconfig
the tree pulling this patchset should also pull a (yet to be
created) immutable branch containing
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/drivers/power?h=for-next&id=8c0984e5a75337df513047ec92a6c09d78e3e5cd

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160822/295a0449/attachment.sig>

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Alan Stern]

On Mon, 22 Aug 2016, Peter Chen wrote:

> On Mon, Aug 15, 2016 at 05:13:14PM +0800, Peter Chen wrote:
> > Some hard-wired USB devices need to do power sequence to let the
> > device work normally, the typical power sequence like: enable USB
> > PHY clock, toggle reset pin, etc. But current Linux USB driver
> > lacks of such code to do it, it may cause some hard-wired USB devices
> > works abnormal or can't be recognized by controller at all.
> > 
> > In this patch, it calls power sequence library APIs to finish
> > the power sequence events. At first, it calls pwrseq_alloc_generic
> > to create a generic power sequence instance, then it will do power
> > on sequence at hub's probe for all devices under this hub
> > (includes root hub).
> > 
> > At hub_disconnect, it will do power off sequence which is at powered
> > on list.
> > 
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > Tested-by Joshua Clayton <stillcompiling@gmail.com>
> 
> Hi Alan,
> 
> The power sequence library code has been reviewed several rounds, would
> you please help to review the change for USB part?

Some small problems...  See below.

> > --- a/drivers/usb/core/Makefile
> > +++ b/drivers/usb/core/Makefile
> > @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
> >  
> >  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
> >  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> > +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o

Please use a tab to align this with the lines above.

> > --- /dev/null
> > +++ b/drivers/usb/core/pwrseq.c
> > @@ -0,0 +1,100 @@
> > +/*
> > + * pwrseq.c	USB device power sequence management
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Author: Peter Chen <peter.chen@nxp.com>
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2  of
> > + * the License as published by the Free Software Foundation.
> > + *
> > + * 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.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include <linux/list.h>
> > +#include <linux/of.h>
> > +#include <linux/power/pwrseq.h>
> > +#include <linux/slab.h>
> > +#include <linux/usb.h>
> > +#include <linux/usb/hcd.h>
> > +
> > +#include "hub.h"
> > +
> > +struct usb_pwrseq_node {
> > +	struct pwrseq *pwrseq;
> > +	struct list_head list;
> > +};
> > +
> > +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> > +{
> > +	struct pwrseq *pwrseq;
> > +	struct usb_pwrseq_node *pwrseq_node;
> > +	int ret;
> > +
> > +	pwrseq = pwrseq_alloc_generic();
> > +	if (IS_ERR(pwrseq))
> > +		return PTR_ERR(pwrseq);
> > +
> > +	ret = pwrseq_get(np, pwrseq);
> > +	if (ret)
> > +		goto pwr_free;
> > +
> > +	ret = pwrseq_on(np, pwrseq);
> > +	if (ret)
> > +		goto pwr_put;
> > +
> > +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);

You need to check that the kzalloc succeeded.

> > +	pwrseq_node->pwrseq = pwrseq;
> > +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> > +
> > +	return 0;
> > +
> > +pwr_put:
> > +	pwrseq_put(pwrseq);
> > +pwr_free:
> > +	pwrseq_free(pwrseq);
> > +	return ret;
> > +}

This subroutine looks very generic.  The only place where it cares that
it was called for a USB hub is the list_add(), and that could easily
become generic also (make this function take &hub->pwrseq_on_list as
its second argument, instead of hub).

It looks like this routine really belongs in the power sequence 
library.

> > +
> > +int hub_pwrseq_on(struct usb_hub *hub)
> > +{

The names of this routine and the subroutine above are too similar.  
After all, both functions require OF support.

> > +	struct device *parent;
> > +	struct usb_device *hdev = hub->hdev;
> > +	struct device_node *np;
> > +	int ret;
> > +
> > +	if (hdev->parent)
> > +		parent = &hdev->dev;
> > +	else
> > +		parent = bus_to_hcd(hdev->bus)->self.controller;
> > +
> > +	for_each_child_of_node(parent->of_node, np) {
> > +		ret = hub_of_pwrseq_on(np, hub);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +void hub_pwrseq_off(struct usb_hub *hub)
> > +{
> > +	struct pwrseq *pwrseq;
> > +	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
> > +
> > +	list_for_each_entry_safe(pwrseq_node, tmp_node,
> > +			&hub->pwrseq_on_list, list) {
> > +		pwrseq = pwrseq_node->pwrseq;
> > +		pwrseq_off(pwrseq);
> > +		pwrseq_put(pwrseq);
> > +		pwrseq_free(pwrseq);
> > +		list_del(&pwrseq_node->list);
> > +		kfree(pwrseq_node);
> > +	}
> > +}

This routine also looks like it belongs in a library.

Alan Stern

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Alan Stern]

On Mon, 22 Aug 2016, Peter Chen wrote:

> On Mon, Aug 15, 2016 at 05:13:14PM +0800, Peter Chen wrote:
> > Some hard-wired USB devices need to do power sequence to let the
> > device work normally, the typical power sequence like: enable USB
> > PHY clock, toggle reset pin, etc. But current Linux USB driver
> > lacks of such code to do it, it may cause some hard-wired USB devices
> > works abnormal or can't be recognized by controller at all.
> > 
> > In this patch, it calls power sequence library APIs to finish
> > the power sequence events. At first, it calls pwrseq_alloc_generic
> > to create a generic power sequence instance, then it will do power
> > on sequence at hub's probe for all devices under this hub
> > (includes root hub).
> > 
> > At hub_disconnect, it will do power off sequence which is at powered
> > on list.
> > 
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > Tested-by Joshua Clayton <stillcompiling@gmail.com>
> 
> Hi Alan,
> 
> The power sequence library code has been reviewed several rounds, would
> you please help to review the change for USB part?

Some small problems...  See below.

> > --- a/drivers/usb/core/Makefile
> > +++ b/drivers/usb/core/Makefile
> > @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
> >  
> >  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
> >  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> > +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o

Please use a tab to align this with the lines above.

> > --- /dev/null
> > +++ b/drivers/usb/core/pwrseq.c
> > @@ -0,0 +1,100 @@
> > +/*
> > + * pwrseq.c	USB device power sequence management
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Author: Peter Chen <peter.chen@nxp.com>
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2  of
> > + * the License as published by the Free Software Foundation.
> > + *
> > + * 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.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include <linux/list.h>
> > +#include <linux/of.h>
> > +#include <linux/power/pwrseq.h>
> > +#include <linux/slab.h>
> > +#include <linux/usb.h>
> > +#include <linux/usb/hcd.h>
> > +
> > +#include "hub.h"
> > +
> > +struct usb_pwrseq_node {
> > +	struct pwrseq *pwrseq;
> > +	struct list_head list;
> > +};
> > +
> > +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> > +{
> > +	struct pwrseq *pwrseq;
> > +	struct usb_pwrseq_node *pwrseq_node;
> > +	int ret;
> > +
> > +	pwrseq = pwrseq_alloc_generic();
> > +	if (IS_ERR(pwrseq))
> > +		return PTR_ERR(pwrseq);
> > +
> > +	ret = pwrseq_get(np, pwrseq);
> > +	if (ret)
> > +		goto pwr_free;
> > +
> > +	ret = pwrseq_on(np, pwrseq);
> > +	if (ret)
> > +		goto pwr_put;
> > +
> > +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);

You need to check that the kzalloc succeeded.

> > +	pwrseq_node->pwrseq = pwrseq;
> > +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> > +
> > +	return 0;
> > +
> > +pwr_put:
> > +	pwrseq_put(pwrseq);
> > +pwr_free:
> > +	pwrseq_free(pwrseq);
> > +	return ret;
> > +}

This subroutine looks very generic.  The only place where it cares that
it was called for a USB hub is the list_add(), and that could easily
become generic also (make this function take &hub->pwrseq_on_list as
its second argument, instead of hub).

It looks like this routine really belongs in the power sequence 
library.

> > +
> > +int hub_pwrseq_on(struct usb_hub *hub)
> > +{

The names of this routine and the subroutine above are too similar.  
After all, both functions require OF support.

> > +	struct device *parent;
> > +	struct usb_device *hdev = hub->hdev;
> > +	struct device_node *np;
> > +	int ret;
> > +
> > +	if (hdev->parent)
> > +		parent = &hdev->dev;
> > +	else
> > +		parent = bus_to_hcd(hdev->bus)->self.controller;
> > +
> > +	for_each_child_of_node(parent->of_node, np) {
> > +		ret = hub_of_pwrseq_on(np, hub);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +void hub_pwrseq_off(struct usb_hub *hub)
> > +{
> > +	struct pwrseq *pwrseq;
> > +	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
> > +
> > +	list_for_each_entry_safe(pwrseq_node, tmp_node,
> > +			&hub->pwrseq_on_list, list) {
> > +		pwrseq = pwrseq_node->pwrseq;
> > +		pwrseq_off(pwrseq);
> > +		pwrseq_put(pwrseq);
> > +		pwrseq_free(pwrseq);
> > +		list_del(&pwrseq_node->list);
> > +		kfree(pwrseq_node);
> > +	}
> > +}

This routine also looks like it belongs in a library.

Alan Stern

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Alan Stern]

On Mon, 22 Aug 2016, Peter Chen wrote:

> On Mon, Aug 15, 2016 at 05:13:14PM +0800, Peter Chen wrote:
> > Some hard-wired USB devices need to do power sequence to let the
> > device work normally, the typical power sequence like: enable USB
> > PHY clock, toggle reset pin, etc. But current Linux USB driver
> > lacks of such code to do it, it may cause some hard-wired USB devices
> > works abnormal or can't be recognized by controller at all.
> > 
> > In this patch, it calls power sequence library APIs to finish
> > the power sequence events. At first, it calls pwrseq_alloc_generic
> > to create a generic power sequence instance, then it will do power
> > on sequence at hub's probe for all devices under this hub
> > (includes root hub).
> > 
> > At hub_disconnect, it will do power off sequence which is at powered
> > on list.
> > 
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > Tested-by Joshua Clayton <stillcompiling@gmail.com>
> 
> Hi Alan,
> 
> The power sequence library code has been reviewed several rounds, would
> you please help to review the change for USB part?

Some small problems...  See below.

> > --- a/drivers/usb/core/Makefile
> > +++ b/drivers/usb/core/Makefile
> > @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
> >  
> >  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
> >  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> > +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o

Please use a tab to align this with the lines above.

> > --- /dev/null
> > +++ b/drivers/usb/core/pwrseq.c
> > @@ -0,0 +1,100 @@
> > +/*
> > + * pwrseq.c	USB device power sequence management
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Author: Peter Chen <peter.chen@nxp.com>
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2  of
> > + * the License as published by the Free Software Foundation.
> > + *
> > + * 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.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include <linux/list.h>
> > +#include <linux/of.h>
> > +#include <linux/power/pwrseq.h>
> > +#include <linux/slab.h>
> > +#include <linux/usb.h>
> > +#include <linux/usb/hcd.h>
> > +
> > +#include "hub.h"
> > +
> > +struct usb_pwrseq_node {
> > +	struct pwrseq *pwrseq;
> > +	struct list_head list;
> > +};
> > +
> > +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> > +{
> > +	struct pwrseq *pwrseq;
> > +	struct usb_pwrseq_node *pwrseq_node;
> > +	int ret;
> > +
> > +	pwrseq = pwrseq_alloc_generic();
> > +	if (IS_ERR(pwrseq))
> > +		return PTR_ERR(pwrseq);
> > +
> > +	ret = pwrseq_get(np, pwrseq);
> > +	if (ret)
> > +		goto pwr_free;
> > +
> > +	ret = pwrseq_on(np, pwrseq);
> > +	if (ret)
> > +		goto pwr_put;
> > +
> > +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);

You need to check that the kzalloc succeeded.

> > +	pwrseq_node->pwrseq = pwrseq;
> > +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> > +
> > +	return 0;
> > +
> > +pwr_put:
> > +	pwrseq_put(pwrseq);
> > +pwr_free:
> > +	pwrseq_free(pwrseq);
> > +	return ret;
> > +}

This subroutine looks very generic.  The only place where it cares that
it was called for a USB hub is the list_add(), and that could easily
become generic also (make this function take &hub->pwrseq_on_list as
its second argument, instead of hub).

It looks like this routine really belongs in the power sequence 
library.

> > +
> > +int hub_pwrseq_on(struct usb_hub *hub)
> > +{

The names of this routine and the subroutine above are too similar.  
After all, both functions require OF support.

> > +	struct device *parent;
> > +	struct usb_device *hdev = hub->hdev;
> > +	struct device_node *np;
> > +	int ret;
> > +
> > +	if (hdev->parent)
> > +		parent = &hdev->dev;
> > +	else
> > +		parent = bus_to_hcd(hdev->bus)->self.controller;
> > +
> > +	for_each_child_of_node(parent->of_node, np) {
> > +		ret = hub_of_pwrseq_on(np, hub);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +void hub_pwrseq_off(struct usb_hub *hub)
> > +{
> > +	struct pwrseq *pwrseq;
> > +	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
> > +
> > +	list_for_each_entry_safe(pwrseq_node, tmp_node,
> > +			&hub->pwrseq_on_list, list) {
> > +		pwrseq = pwrseq_node->pwrseq;
> > +		pwrseq_off(pwrseq);
> > +		pwrseq_put(pwrseq);
> > +		pwrseq_free(pwrseq);
> > +		list_del(&pwrseq_node->list);
> > +		kfree(pwrseq_node);
> > +	}
> > +}

This routine also looks like it belongs in a library.

Alan Stern

Re: [PATCH v6 2/8] power: add power sequence library

[Peter Chen]

On Mon, Aug 22, 2016 at 12:23:31PM +0200, Sebastian Reichel wrote:
> Hi Peter,
> 
> On Mon, Aug 22, 2016 at 02:51:58PM +0800, Peter Chen wrote:
> > On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> > > We have an well-known problem that the device needs to do some power
> > > sequence before it can be recognized by related host, the typical
> > > example like hard-wired mmc devices and usb devices.
> > > 
> > > This power sequence is hard to be described at device tree and handled by
> > > related host driver, so we have created a common power sequence
> > > library to cover this requirement. The core code has supplied
> > > some common helpers for host driver, and individual power sequence
> > > libraries handle kinds of power sequence for devices.
> > > 
> > > pwrseq_generic is intended for general purpose of power sequence, which
> > > handles gpios and clocks currently, and can cover regulator and pinctrl
> > > in future. The host driver calls pwrseq_alloc_generic to create
> > > an generic pwrseq instance.
> > > 
> > > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > > Tested-by Joshua Clayton <stillcompiling@gmail.com>
> > > Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> > > Tested-by: Matthias Kaehlcke <mka@chromium.org>
> > 
> > Hi Greg, Sebastian, Dmitry, and David
> > 
> > I find the code under drivers/power have several subsystems.
> > Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
> > Or can go the Greg's tree?
> 
> I think this does not really fit into the power-supply tree.
> I would expect this to go through Rafael's linux-pm tree.

Ok, thanks. Rafael, would you agree with that? If you agree, I will
update MAINTAINER file.

> 
> Note: I moved all the power-supply code into drivers/power/supply/
> in linux-next, among other things because of this patchset. To avoid
> merge conflicts in drivers/power/Makefile and drivers/power/Kconfig
> the tree pulling this patchset should also pull a (yet to be
> created) immutable branch containing
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/drivers/power?h=for-next&id=8c0984e5a75337df513047ec92a6c09d78e3e5cd
> 

Yes, I found the rebase conflict with it, I will fix it at next
revision.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 2/8] power: add power sequence library

[Peter Chen]

On Mon, Aug 22, 2016 at 12:23:31PM +0200, Sebastian Reichel wrote:
> Hi Peter,
> 
> On Mon, Aug 22, 2016 at 02:51:58PM +0800, Peter Chen wrote:
> > On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> > > We have an well-known problem that the device needs to do some power
> > > sequence before it can be recognized by related host, the typical
> > > example like hard-wired mmc devices and usb devices.
> > > 
> > > This power sequence is hard to be described at device tree and handled by
> > > related host driver, so we have created a common power sequence
> > > library to cover this requirement. The core code has supplied
> > > some common helpers for host driver, and individual power sequence
> > > libraries handle kinds of power sequence for devices.
> > > 
> > > pwrseq_generic is intended for general purpose of power sequence, which
> > > handles gpios and clocks currently, and can cover regulator and pinctrl
> > > in future. The host driver calls pwrseq_alloc_generic to create
> > > an generic pwrseq instance.
> > > 
> > > Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
> > > Tested-by Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Reviewed-by: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > Tested-by: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > 
> > Hi Greg, Sebastian, Dmitry, and David
> > 
> > I find the code under drivers/power have several subsystems.
> > Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
> > Or can go the Greg's tree?
> 
> I think this does not really fit into the power-supply tree.
> I would expect this to go through Rafael's linux-pm tree.

Ok, thanks. Rafael, would you agree with that? If you agree, I will
update MAINTAINER file.

> 
> Note: I moved all the power-supply code into drivers/power/supply/
> in linux-next, among other things because of this patchset. To avoid
> merge conflicts in drivers/power/Makefile and drivers/power/Kconfig
> the tree pulling this patchset should also pull a (yet to be
> created) immutable branch containing
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/drivers/power?h=for-next&id=8c0984e5a75337df513047ec92a6c09d78e3e5cd
> 

Yes, I found the rebase conflict with it, I will fix it at next
revision.

-- 

Best Regards,
Peter Chen
--
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 v6 2/8] power: add power sequence library

[Peter Chen]

On Mon, Aug 22, 2016 at 12:23:31PM +0200, Sebastian Reichel wrote:
> Hi Peter,
> 
> On Mon, Aug 22, 2016 at 02:51:58PM +0800, Peter Chen wrote:
> > On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> > > We have an well-known problem that the device needs to do some power
> > > sequence before it can be recognized by related host, the typical
> > > example like hard-wired mmc devices and usb devices.
> > > 
> > > This power sequence is hard to be described at device tree and handled by
> > > related host driver, so we have created a common power sequence
> > > library to cover this requirement. The core code has supplied
> > > some common helpers for host driver, and individual power sequence
> > > libraries handle kinds of power sequence for devices.
> > > 
> > > pwrseq_generic is intended for general purpose of power sequence, which
> > > handles gpios and clocks currently, and can cover regulator and pinctrl
> > > in future. The host driver calls pwrseq_alloc_generic to create
> > > an generic pwrseq instance.
> > > 
> > > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > > Tested-by Joshua Clayton <stillcompiling@gmail.com>
> > > Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> > > Tested-by: Matthias Kaehlcke <mka@chromium.org>
> > 
> > Hi Greg, Sebastian, Dmitry, and David
> > 
> > I find the code under drivers/power have several subsystems.
> > Does this power sequence patch set can go git://git.infradead.org/battery-2.6.git?
> > Or can go the Greg's tree?
> 
> I think this does not really fit into the power-supply tree.
> I would expect this to go through Rafael's linux-pm tree.

Ok, thanks. Rafael, would you agree with that? If you agree, I will
update MAINTAINER file.

> 
> Note: I moved all the power-supply code into drivers/power/supply/
> in linux-next, among other things because of this patchset. To avoid
> merge conflicts in drivers/power/Makefile and drivers/power/Kconfig
> the tree pulling this patchset should also pull a (yet to be
> created) immutable branch containing
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/drivers/power?h=for-next&id=8c0984e5a75337df513047ec92a6c09d78e3e5cd
> 

Yes, I found the rebase conflict with it, I will fix it at next
revision.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

On Mon, Aug 22, 2016 at 12:09:54PM -0400, Alan Stern wrote:
> > > +
> > > +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> > > +{
> > > +	struct pwrseq *pwrseq;
> > > +	struct usb_pwrseq_node *pwrseq_node;
> > > +	int ret;
> > > +
> > > +	pwrseq = pwrseq_alloc_generic();
> > > +	if (IS_ERR(pwrseq))
> > > +		return PTR_ERR(pwrseq);
> > > +
> > > +	ret = pwrseq_get(np, pwrseq);
> > > +	if (ret)
> > > +		goto pwr_free;
> > > +
> > > +	ret = pwrseq_on(np, pwrseq);
> > > +	if (ret)
> > > +		goto pwr_put;
> > > +
> > > +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
> 
> You need to check that the kzalloc succeeded.

Ok.

> 
> > > +	pwrseq_node->pwrseq = pwrseq;
> > > +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> > > +
> > > +	return 0;
> > > +
> > > +pwr_put:
> > > +	pwrseq_put(pwrseq);
> > > +pwr_free:
> > > +	pwrseq_free(pwrseq);
> > > +	return ret;
> > > +}
> 
> This subroutine looks very generic.  The only place where it cares that
> it was called for a USB hub is the list_add(), and that could easily
> become generic also (make this function take &hub->pwrseq_on_list as
> its second argument, instead of hub).
> 
> It looks like this routine really belongs in the power sequence 
> library.
> 

I will export below two generic functions at pwrseq library:

int generic_pwrseq_on(struct device_node *np, struct list_head *head)
void generic_pwrseq_off(struct list_head *head)

delete this file, and call above APIs at hub.c.

> > > +
> > > +int hub_pwrseq_on(struct usb_hub *hub)
> > > +{
> 
> The names of this routine and the subroutine above are too similar.  
> After all, both functions require OF support.
> 

I will add #ifdef CONFIG_OF for related code. And put the content at
hub_pwrseq_on at hub_probe directly, how about below?

hub_probe() {

	...

	if (hub_configure(hub, endpoint) >= 0) {
#ifdef CONFIG_OF
		for_each_child_of_node(parent->of_node, np) {
			ret = generic_pwrseq_on(np, hub);
			if (ret)
				return ret;
		}
#else
		return 0;
#endif
	}

	hub_disconnect(intf);
	return ret;
}

-- 

Best Regards,
Peter Chen

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

On Mon, Aug 22, 2016 at 12:09:54PM -0400, Alan Stern wrote:
> > > +
> > > +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> > > +{
> > > +	struct pwrseq *pwrseq;
> > > +	struct usb_pwrseq_node *pwrseq_node;
> > > +	int ret;
> > > +
> > > +	pwrseq = pwrseq_alloc_generic();
> > > +	if (IS_ERR(pwrseq))
> > > +		return PTR_ERR(pwrseq);
> > > +
> > > +	ret = pwrseq_get(np, pwrseq);
> > > +	if (ret)
> > > +		goto pwr_free;
> > > +
> > > +	ret = pwrseq_on(np, pwrseq);
> > > +	if (ret)
> > > +		goto pwr_put;
> > > +
> > > +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
> 
> You need to check that the kzalloc succeeded.

Ok.

> 
> > > +	pwrseq_node->pwrseq = pwrseq;
> > > +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> > > +
> > > +	return 0;
> > > +
> > > +pwr_put:
> > > +	pwrseq_put(pwrseq);
> > > +pwr_free:
> > > +	pwrseq_free(pwrseq);
> > > +	return ret;
> > > +}
> 
> This subroutine looks very generic.  The only place where it cares that
> it was called for a USB hub is the list_add(), and that could easily
> become generic also (make this function take &hub->pwrseq_on_list as
> its second argument, instead of hub).
> 
> It looks like this routine really belongs in the power sequence 
> library.
> 

I will export below two generic functions at pwrseq library:

int generic_pwrseq_on(struct device_node *np, struct list_head *head)
void generic_pwrseq_off(struct list_head *head)

delete this file, and call above APIs at hub.c.

> > > +
> > > +int hub_pwrseq_on(struct usb_hub *hub)
> > > +{
> 
> The names of this routine and the subroutine above are too similar.  
> After all, both functions require OF support.
> 

I will add #ifdef CONFIG_OF for related code. And put the content at
hub_pwrseq_on at hub_probe directly, how about below?

hub_probe() {

	...

	if (hub_configure(hub, endpoint) >= 0) {
#ifdef CONFIG_OF
		for_each_child_of_node(parent->of_node, np) {
			ret = generic_pwrseq_on(np, hub);
			if (ret)
				return ret;
		}
#else
		return 0;
#endif
	}

	hub_disconnect(intf);
	return ret;
}

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> power sequence library for parsing the power sequence elements on DT,
> and implement generic power sequence on library. The host driver
> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the generic 
library
implementation in this patch series is not going to solve many of the 
custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy 
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


                               Host
                                |
                                V
                            USB port
------------------------------------------------------------
                                |
                                V
                       USB HUB device (May need custom on/off seq)
                                |
                                V
               =============================
              |                             |
              V                             V
          Device-1                       Device-2
(Needs special power               (Needs special power
  on/off sequence.                   on/off sequence.
  Also may need custom               Also, may need custom
  sequence for                       sequence for
  suspend/resume)                    suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
           in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Thanks,
Vaibhav



> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
>    the USB device's reg has only #address-cells, but without #size-cells.
>
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
>
> Changes for v4:
> - Create the patch on next-20160722
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
>
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
>    at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
>    add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
>
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
>    layer's at core's probe
>
> Joshua Clayton (2):
>    ARM: dts: imx6qdl: Enable usb node children with <reg>
>    ARM: dts: imx6q-evi: Fix onboard hub reset line
>
> Peter Chen (6):
>    binding-doc: power: pwrseq-generic: add binding doc for generic power
>      sequence library
>    power: add power sequence library
>    binding-doc: usb: usb-device: add optional properties for power
>      sequence
>    usb: core: add power sequence handling for USB devices
>    usb: chipidea: let chipidea core device of_node equal's glue layer
>      device of_node
>    ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
>
>   .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 ++++++
>   .../devicetree/bindings/usb/usb-device.txt         |  10 +-
>   MAINTAINERS                                        |   9 ++
>   arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
>   arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++--
>   arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
>   drivers/power/Kconfig                              |   1 +
>   drivers/power/Makefile                             |   1 +
>   drivers/power/pwrseq/Kconfig                       |  20 +++
>   drivers/power/pwrseq/Makefile                      |   2 +
>   drivers/power/pwrseq/core.c                        |  62 ++++++++
>   drivers/power/pwrseq/pwrseq_generic.c              | 168 +++++++++++++++++++++
>   drivers/usb/chipidea/core.c                        |  27 +++-
>   drivers/usb/core/Makefile                          |   1 +
>   drivers/usb/core/hub.c                             |  12 +-
>   drivers/usb/core/hub.h                             |  12 ++
>   drivers/usb/core/pwrseq.c                          | 100 ++++++++++++
>   include/linux/power/pwrseq.h                       |  47 ++++++
>   18 files changed, 536 insertions(+), 41 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>   create mode 100644 drivers/power/pwrseq/Kconfig
>   create mode 100644 drivers/power/pwrseq/Makefile
>   create mode 100644 drivers/power/pwrseq/core.c
>   create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>   create mode 100644 drivers/usb/core/pwrseq.c
>   create mode 100644 include/linux/power/pwrseq.h
>

-- 
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> power sequence library for parsing the power sequence elements on DT,
> and implement generic power sequence on library. The host driver
> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the generic 
library
implementation in this patch series is not going to solve many of the 
custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy 
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


                               Host
                                |
                                V
                            USB port
------------------------------------------------------------
                                |
                                V
                       USB HUB device (May need custom on/off seq)
                                |
                                V
               =============================
              |                             |
              V                             V
          Device-1                       Device-2
(Needs special power               (Needs special power
  on/off sequence.                   on/off sequence.
  Also may need custom               Also, may need custom
  sequence for                       sequence for
  suspend/resume)                    suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
           in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Thanks,
Vaibhav



> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
>    the USB device's reg has only #address-cells, but without #size-cells.
>
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
>
> Changes for v4:
> - Create the patch on next-20160722
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
>
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
>    at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
>    add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
>
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
>    layer's at core's probe
>
> Joshua Clayton (2):
>    ARM: dts: imx6qdl: Enable usb node children with <reg>
>    ARM: dts: imx6q-evi: Fix onboard hub reset line
>
> Peter Chen (6):
>    binding-doc: power: pwrseq-generic: add binding doc for generic power
>      sequence library
>    power: add power sequence library
>    binding-doc: usb: usb-device: add optional properties for power
>      sequence
>    usb: core: add power sequence handling for USB devices
>    usb: chipidea: let chipidea core device of_node equal's glue layer
>      device of_node
>    ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
>
>   .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 ++++++
>   .../devicetree/bindings/usb/usb-device.txt         |  10 +-
>   MAINTAINERS                                        |   9 ++
>   arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
>   arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++--
>   arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
>   drivers/power/Kconfig                              |   1 +
>   drivers/power/Makefile                             |   1 +
>   drivers/power/pwrseq/Kconfig                       |  20 +++
>   drivers/power/pwrseq/Makefile                      |   2 +
>   drivers/power/pwrseq/core.c                        |  62 ++++++++
>   drivers/power/pwrseq/pwrseq_generic.c              | 168 +++++++++++++++++++++
>   drivers/usb/chipidea/core.c                        |  27 +++-
>   drivers/usb/core/Makefile                          |   1 +
>   drivers/usb/core/hub.c                             |  12 +-
>   drivers/usb/core/hub.h                             |  12 ++
>   drivers/usb/core/pwrseq.c                          | 100 ++++++++++++
>   include/linux/power/pwrseq.h                       |  47 ++++++
>   18 files changed, 536 insertions(+), 41 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>   create mode 100644 drivers/power/pwrseq/Kconfig
>   create mode 100644 drivers/power/pwrseq/Makefile
>   create mode 100644 drivers/power/pwrseq/core.c
>   create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>   create mode 100644 drivers/usb/core/pwrseq.c
>   create mode 100644 include/linux/power/pwrseq.h
>

-- 
Thanks,
Vaibhav

[PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> power sequence library for parsing the power sequence elements on DT,
> and implement generic power sequence on library. The host driver
> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the generic 
library
implementation in this patch series is not going to solve many of the 
custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy 
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


                               Host
                                |
                                V
                            USB port
------------------------------------------------------------
                                |
                                V
                       USB HUB device (May need custom on/off seq)
                                |
                                V
               =============================
              |                             |
              V                             V
          Device-1                       Device-2
(Needs special power               (Needs special power
  on/off sequence.                   on/off sequence.
  Also may need custom               Also, may need custom
  sequence for                       sequence for
  suspend/resume)                    suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
           in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Thanks,
Vaibhav



> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
>    the USB device's reg has only #address-cells, but without #size-cells.
>
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
>
> Changes for v4:
> - Create the patch on next-20160722
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
>
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
>    at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
>    add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
>
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
>    layer's at core's probe
>
> Joshua Clayton (2):
>    ARM: dts: imx6qdl: Enable usb node children with <reg>
>    ARM: dts: imx6q-evi: Fix onboard hub reset line
>
> Peter Chen (6):
>    binding-doc: power: pwrseq-generic: add binding doc for generic power
>      sequence library
>    power: add power sequence library
>    binding-doc: usb: usb-device: add optional properties for power
>      sequence
>    usb: core: add power sequence handling for USB devices
>    usb: chipidea: let chipidea core device of_node equal's glue layer
>      device of_node
>    ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
>
>   .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 ++++++
>   .../devicetree/bindings/usb/usb-device.txt         |  10 +-
>   MAINTAINERS                                        |   9 ++
>   arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
>   arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++--
>   arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
>   drivers/power/Kconfig                              |   1 +
>   drivers/power/Makefile                             |   1 +
>   drivers/power/pwrseq/Kconfig                       |  20 +++
>   drivers/power/pwrseq/Makefile                      |   2 +
>   drivers/power/pwrseq/core.c                        |  62 ++++++++
>   drivers/power/pwrseq/pwrseq_generic.c              | 168 +++++++++++++++++++++
>   drivers/usb/chipidea/core.c                        |  27 +++-
>   drivers/usb/core/Makefile                          |   1 +
>   drivers/usb/core/hub.c                             |  12 +-
>   drivers/usb/core/hub.h                             |  12 ++
>   drivers/usb/core/pwrseq.c                          | 100 ++++++++++++
>   include/linux/power/pwrseq.h                       |  47 ++++++
>   18 files changed, 536 insertions(+), 41 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>   create mode 100644 drivers/power/pwrseq/Kconfig
>   create mode 100644 drivers/power/pwrseq/Makefile
>   create mode 100644 drivers/power/pwrseq/core.c
>   create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>   create mode 100644 drivers/usb/core/pwrseq.c
>   create mode 100644 include/linux/power/pwrseq.h
>

-- 
Thanks,
Vaibhav

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Alan Stern]

On Tue, 23 Aug 2016, Peter Chen wrote:

> I will add #ifdef CONFIG_OF for related code. And put the content at
> hub_pwrseq_on at hub_probe directly, how about below?
> 
> hub_probe() {
> 
> 	...
> 
> 	if (hub_configure(hub, endpoint) >= 0) {
> #ifdef CONFIG_OF
> 		for_each_child_of_node(parent->of_node, np) {
> 			ret = generic_pwrseq_on(np, hub);
> 			if (ret)
> 				return ret;
> 		}
> #else
> 		return 0;
> #endif
> 	}

Please make this a separate subroutine like you had before, but now in 
hub.c:

#ifdef CONFIG_OF
static int hub_of_pwrseq_on(struct usb_hub *hub)
{
...
}

#else
static inline int hub_of_pwrseq_on(struct usb_hub *hub)
{
	return 0;
}
#endif /* CONFIG_OF */


Alan Stern

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Alan Stern]

On Tue, 23 Aug 2016, Peter Chen wrote:

> I will add #ifdef CONFIG_OF for related code. And put the content at
> hub_pwrseq_on at hub_probe directly, how about below?
> 
> hub_probe() {
> 
> 	...
> 
> 	if (hub_configure(hub, endpoint) >= 0) {
> #ifdef CONFIG_OF
> 		for_each_child_of_node(parent->of_node, np) {
> 			ret = generic_pwrseq_on(np, hub);
> 			if (ret)
> 				return ret;
> 		}
> #else
> 		return 0;
> #endif
> 	}

Please make this a separate subroutine like you had before, but now in 
hub.c:

#ifdef CONFIG_OF
static int hub_of_pwrseq_on(struct usb_hub *hub)
{
...
}

#else
static inline int hub_of_pwrseq_on(struct usb_hub *hub)
{
	return 0;
}
#endif /* CONFIG_OF */


Alan Stern

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Alan Stern]

On Tue, 23 Aug 2016, Peter Chen wrote:

> I will add #ifdef CONFIG_OF for related code. And put the content at
> hub_pwrseq_on at hub_probe directly, how about below?
> 
> hub_probe() {
> 
> 	...
> 
> 	if (hub_configure(hub, endpoint) >= 0) {
> #ifdef CONFIG_OF
> 		for_each_child_of_node(parent->of_node, np) {
> 			ret = generic_pwrseq_on(np, hub);
> 			if (ret)
> 				return ret;
> 		}
> #else
> 		return 0;
> #endif
> 	}

Please make this a separate subroutine like you had before, but now in 
hub.c:

#ifdef CONFIG_OF
static int hub_of_pwrseq_on(struct usb_hub *hub)
{
...
}

#else
static inline int hub_of_pwrseq_on(struct usb_hub *hub)
{
	return 0;
}
#endif /* CONFIG_OF */


Alan Stern

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Hi all,
> >
> >This is a follow-up for my last power sequence framework patch set [1].
> >According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >power sequence library for parsing the power sequence elements on DT,
> >and implement generic power sequence on library. The host driver
> >can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >
> >In future, if there are special power sequence requirements, the special
> >power sequence library can be created.
> >
> >This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >two hot-plug devices to simulate this use case, the related binding
> >change is updated at patch [1/6], The udoo board changes were tested
> >using my last power sequence patch set.[3]
> >
> >Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >need to power on itself before it can be found by ULPI bus.
> >
> >[1] http://www.spinics.net/lists/linux-usb/msg142755.html
> >[2] http://www.spinics.net/lists/linux-usb/msg143106.html
> >[3] http://www.spinics.net/lists/linux-usb/msg142815.html
> (Please ignore my response on V2)
> 
> Sorry being so late in the discussion...
> 
> If I am not missing anything, then I am afraid to say that the
> generic library
> implementation in this patch series is not going to solve many of
> the custom
> requirement of power on, off, etc...
> I know you mentioned about adding another library when we come
> across such platforms, but should we not keep provision (or easy
> hooks/path)
> to enable that ?
> 
> Let me bring in the use case I am dealing with,
> 
> 
>                               Host
>                                |
>                                V
>                            USB port
> ------------------------------------------------------------
>                                |
>                                V
>                       USB HUB device (May need custom on/off seq)
>                                |
>                                V
>               =============================
>              |                             |
>              V                             V
>          Device-1                       Device-2
> (Needs special power               (Needs special power
>  on/off sequence.                   on/off sequence.
>  Also may need custom               Also, may need custom
>  sequence for                       sequence for
>  suspend/resume)                    suspend/resume)
> 
> 
> Note: Both Devices are connected to HUB via HSIC and may differ
>           in terms of functionality, features they support.
> 
> In the above case, both Device-1 and Device-2, need separate
> power on/off sequence. So generic library currently we have in this
> patch series is not going to satisfy the need here.
> 
> I looked at all 6 revisions of this patch-series, went through the
> review comments, and looked at MMC power sequence code;
> what I can say here is, we need something similar to
> MMC power sequence here, where every device can have its own
> power sequence (if needed).
> 
> I know Rob is not in favor of creating platform device for
> this, and I understand his comment.
> If not platform device, but atleast we need mechanism to
> connect each device back to its of_node and its respective
> driver/library fns. For example, the Devices may support different
> boot modes, and platform driver needs to make sure that
> the right sequence is followed for booting.
> 
> Peter, My apologies for taking you back again on this series.
> I am OK, if you wish to address this in incremental addition,
> but my point is, we know that the current generic way is not
> enough for us, so I think we should try to fix it in initial phase only.
> 

Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Hi all,
> >
> >This is a follow-up for my last power sequence framework patch set [1].
> >According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >power sequence library for parsing the power sequence elements on DT,
> >and implement generic power sequence on library. The host driver
> >can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >
> >In future, if there are special power sequence requirements, the special
> >power sequence library can be created.
> >
> >This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >two hot-plug devices to simulate this use case, the related binding
> >change is updated at patch [1/6], The udoo board changes were tested
> >using my last power sequence patch set.[3]
> >
> >Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >need to power on itself before it can be found by ULPI bus.
> >
> >[1] http://www.spinics.net/lists/linux-usb/msg142755.html
> >[2] http://www.spinics.net/lists/linux-usb/msg143106.html
> >[3] http://www.spinics.net/lists/linux-usb/msg142815.html
> (Please ignore my response on V2)
> 
> Sorry being so late in the discussion...
> 
> If I am not missing anything, then I am afraid to say that the
> generic library
> implementation in this patch series is not going to solve many of
> the custom
> requirement of power on, off, etc...
> I know you mentioned about adding another library when we come
> across such platforms, but should we not keep provision (or easy
> hooks/path)
> to enable that ?
> 
> Let me bring in the use case I am dealing with,
> 
> 
>                               Host
>                                |
>                                V
>                            USB port
> ------------------------------------------------------------
>                                |
>                                V
>                       USB HUB device (May need custom on/off seq)
>                                |
>                                V
>               =============================
>              |                             |
>              V                             V
>          Device-1                       Device-2
> (Needs special power               (Needs special power
>  on/off sequence.                   on/off sequence.
>  Also may need custom               Also, may need custom
>  sequence for                       sequence for
>  suspend/resume)                    suspend/resume)
> 
> 
> Note: Both Devices are connected to HUB via HSIC and may differ
>           in terms of functionality, features they support.
> 
> In the above case, both Device-1 and Device-2, need separate
> power on/off sequence. So generic library currently we have in this
> patch series is not going to satisfy the need here.
> 
> I looked at all 6 revisions of this patch-series, went through the
> review comments, and looked at MMC power sequence code;
> what I can say here is, we need something similar to
> MMC power sequence here, where every device can have its own
> power sequence (if needed).
> 
> I know Rob is not in favor of creating platform device for
> this, and I understand his comment.
> If not platform device, but atleast we need mechanism to
> connect each device back to its of_node and its respective
> driver/library fns. For example, the Devices may support different
> boot modes, and platform driver needs to make sure that
> the right sequence is followed for booting.
> 
> Peter, My apologies for taking you back again on this series.
> I am OK, if you wish to address this in incremental addition,
> but my point is, we know that the current generic way is not
> enough for us, so I think we should try to fix it in initial phase only.
> 

Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.

-- 

Best Regards,
Peter Chen
--
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 v6 0/8] power: add power sequence library

[Peter Chen]

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Hi all,
> >
> >This is a follow-up for my last power sequence framework patch set [1].
> >According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >power sequence library for parsing the power sequence elements on DT,
> >and implement generic power sequence on library. The host driver
> >can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >
> >In future, if there are special power sequence requirements, the special
> >power sequence library can be created.
> >
> >This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >two hot-plug devices to simulate this use case, the related binding
> >change is updated at patch [1/6], The udoo board changes were tested
> >using my last power sequence patch set.[3]
> >
> >Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >need to power on itself before it can be found by ULPI bus.
> >
> >[1] http://www.spinics.net/lists/linux-usb/msg142755.html
> >[2] http://www.spinics.net/lists/linux-usb/msg143106.html
> >[3] http://www.spinics.net/lists/linux-usb/msg142815.html
> (Please ignore my response on V2)
> 
> Sorry being so late in the discussion...
> 
> If I am not missing anything, then I am afraid to say that the
> generic library
> implementation in this patch series is not going to solve many of
> the custom
> requirement of power on, off, etc...
> I know you mentioned about adding another library when we come
> across such platforms, but should we not keep provision (or easy
> hooks/path)
> to enable that ?
> 
> Let me bring in the use case I am dealing with,
> 
> 
>                               Host
>                                |
>                                V
>                            USB port
> ------------------------------------------------------------
>                                |
>                                V
>                       USB HUB device (May need custom on/off seq)
>                                |
>                                V
>               =============================
>              |                             |
>              V                             V
>          Device-1                       Device-2
> (Needs special power               (Needs special power
>  on/off sequence.                   on/off sequence.
>  Also may need custom               Also, may need custom
>  sequence for                       sequence for
>  suspend/resume)                    suspend/resume)
> 
> 
> Note: Both Devices are connected to HUB via HSIC and may differ
>           in terms of functionality, features they support.
> 
> In the above case, both Device-1 and Device-2, need separate
> power on/off sequence. So generic library currently we have in this
> patch series is not going to satisfy the need here.
> 
> I looked at all 6 revisions of this patch-series, went through the
> review comments, and looked at MMC power sequence code;
> what I can say here is, we need something similar to
> MMC power sequence here, where every device can have its own
> power sequence (if needed).
> 
> I know Rob is not in favor of creating platform device for
> this, and I understand his comment.
> If not platform device, but atleast we need mechanism to
> connect each device back to its of_node and its respective
> driver/library fns. For example, the Devices may support different
> boot modes, and platform driver needs to make sure that
> the right sequence is followed for booting.
> 
> Peter, My apologies for taking you back again on this series.
> I am OK, if you wish to address this in incremental addition,
> but my point is, we know that the current generic way is not
> enough for us, so I think we should try to fix it in initial phase only.
> 

Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> > 
> > 
> > On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> > >Hi all,
> > >
> > >This is a follow-up for my last power sequence framework patch set [1].
> > >According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> > >power sequence library for parsing the power sequence elements on DT,
> > >and implement generic power sequence on library. The host driver
> > >can allocate power sequence instance, and calls pwrseq APIs accordingly.
> > >
> > >In future, if there are special power sequence requirements, the special
> > >power sequence library can be created.
> > >
> > >This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > >two hot-plug devices to simulate this use case, the related binding
> > >change is updated at patch [1/6], The udoo board changes were tested
> > >using my last power sequence patch set.[3]
> > >
> > >Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > >need to power on itself before it can be found by ULPI bus.
> > >
> > >[1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > >[2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > >[3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > (Please ignore my response on V2)
> > 
> > Sorry being so late in the discussion...
> > 
> > If I am not missing anything, then I am afraid to say that the
> > generic library
> > implementation in this patch series is not going to solve many of
> > the custom
> > requirement of power on, off, etc...
> > I know you mentioned about adding another library when we come
> > across such platforms, but should we not keep provision (or easy
> > hooks/path)
> > to enable that ?
> > 
> > Let me bring in the use case I am dealing with,
> > 
> > 
> >                               Host
> >                                |
> >                                V
> >                            USB port
> > ------------------------------------------------------------
> >                                |
> >                                V
> >                       USB HUB device (May need custom on/off seq)
> >                                |
> >                                V
> >               =============================
> >              |                             |
> >              V                             V
> >          Device-1                       Device-2
> > (Needs special power               (Needs special power
> >  on/off sequence.                   on/off sequence.
> >  Also may need custom               Also, may need custom
> >  sequence for                       sequence for
> >  suspend/resume)                    suspend/resume)
> > 
> > 
> > Note: Both Devices are connected to HUB via HSIC and may differ
> >           in terms of functionality, features they support.
> > 
> > In the above case, both Device-1 and Device-2, need separate
> > power on/off sequence. So generic library currently we have in this
> > patch series is not going to satisfy the need here.
> > 
> > I looked at all 6 revisions of this patch-series, went through the
> > review comments, and looked at MMC power sequence code;
> > what I can say here is, we need something similar to
> > MMC power sequence here, where every device can have its own
> > power sequence (if needed).
> > 
> > I know Rob is not in favor of creating platform device for
> > this, and I understand his comment.
> > If not platform device, but atleast we need mechanism to
> > connect each device back to its of_node and its respective
> > driver/library fns. For example, the Devices may support different
> > boot modes, and platform driver needs to make sure that
> > the right sequence is followed for booting.
> > 
> > Peter, My apologies for taking you back again on this series.
> > I am OK, if you wish to address this in incremental addition,
> > but my point is, we know that the current generic way is not
> > enough for us, so I think we should try to fix it in initial phase only.
> > 
> 
> Rob, it seems generic power sequence can't cover all cases.
> Without information from DT, we can't know which power sequence
> for which device.
> 

Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.

-- 

Best Regards,
Peter Chen

[PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> > 
> > 
> > On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> > >Hi all,
> > >
> > >This is a follow-up for my last power sequence framework patch set [1].
> > >According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> > >power sequence library for parsing the power sequence elements on DT,
> > >and implement generic power sequence on library. The host driver
> > >can allocate power sequence instance, and calls pwrseq APIs accordingly.
> > >
> > >In future, if there are special power sequence requirements, the special
> > >power sequence library can be created.
> > >
> > >This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > >two hot-plug devices to simulate this use case, the related binding
> > >change is updated at patch [1/6], The udoo board changes were tested
> > >using my last power sequence patch set.[3]
> > >
> > >Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > >need to power on itself before it can be found by ULPI bus.
> > >
> > >[1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > >[2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > >[3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > (Please ignore my response on V2)
> > 
> > Sorry being so late in the discussion...
> > 
> > If I am not missing anything, then I am afraid to say that the
> > generic library
> > implementation in this patch series is not going to solve many of
> > the custom
> > requirement of power on, off, etc...
> > I know you mentioned about adding another library when we come
> > across such platforms, but should we not keep provision (or easy
> > hooks/path)
> > to enable that ?
> > 
> > Let me bring in the use case I am dealing with,
> > 
> > 
> >                               Host
> >                                |
> >                                V
> >                            USB port
> > ------------------------------------------------------------
> >                                |
> >                                V
> >                       USB HUB device (May need custom on/off seq)
> >                                |
> >                                V
> >               =============================
> >              |                             |
> >              V                             V
> >          Device-1                       Device-2
> > (Needs special power               (Needs special power
> >  on/off sequence.                   on/off sequence.
> >  Also may need custom               Also, may need custom
> >  sequence for                       sequence for
> >  suspend/resume)                    suspend/resume)
> > 
> > 
> > Note: Both Devices are connected to HUB via HSIC and may differ
> >           in terms of functionality, features they support.
> > 
> > In the above case, both Device-1 and Device-2, need separate
> > power on/off sequence. So generic library currently we have in this
> > patch series is not going to satisfy the need here.
> > 
> > I looked at all 6 revisions of this patch-series, went through the
> > review comments, and looked at MMC power sequence code;
> > what I can say here is, we need something similar to
> > MMC power sequence here, where every device can have its own
> > power sequence (if needed).
> > 
> > I know Rob is not in favor of creating platform device for
> > this, and I understand his comment.
> > If not platform device, but atleast we need mechanism to
> > connect each device back to its of_node and its respective
> > driver/library fns. For example, the Devices may support different
> > boot modes, and platform driver needs to make sure that
> > the right sequence is followed for booting.
> > 
> > Peter, My apologies for taking you back again on this series.
> > I am OK, if you wish to address this in incremental addition,
> > but my point is, we know that the current generic way is not
> > enough for us, so I think we should try to fix it in initial phase only.
> > 
> 
> Rob, it seems generic power sequence can't cover all cases.
> Without information from DT, we can't know which power sequence
> for which device.
> 

Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>> Hi all,
>>>>
>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>> power sequence library for parsing the power sequence elements on DT,
>>>> and implement generic power sequence on library. The host driver
>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>
>>>> In future, if there are special power sequence requirements, the special
>>>> power sequence library can be created.
>>>>
>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>> two hot-plug devices to simulate this use case, the related binding
>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>> using my last power sequence patch set.[3]
>>>>
>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>> need to power on itself before it can be found by ULPI bus.
>>>>
>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>> (Please ignore my response on V2)
>>>
>>> Sorry being so late in the discussion...
>>>
>>> If I am not missing anything, then I am afraid to say that the
>>> generic library
>>> implementation in this patch series is not going to solve many of
>>> the custom
>>> requirement of power on, off, etc...
>>> I know you mentioned about adding another library when we come
>>> across such platforms, but should we not keep provision (or easy
>>> hooks/path)
>>> to enable that ?
>>>
>>> Let me bring in the use case I am dealing with,
>>>
>>>
>>>                                Host
>>>                                 |
>>>                                 V
>>>                             USB port
>>> ------------------------------------------------------------
>>>                                 |
>>>                                 V
>>>                        USB HUB device (May need custom on/off seq)
>>>                                 |
>>>                                 V
>>>                =============================
>>>               |                             |
>>>               V                             V
>>>           Device-1                       Device-2
>>> (Needs special power               (Needs special power
>>>   on/off sequence.                   on/off sequence.
>>>   Also may need custom               Also, may need custom
>>>   sequence for                       sequence for
>>>   suspend/resume)                    suspend/resume)
>>>
>>>
>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>            in terms of functionality, features they support.
>>>
>>> In the above case, both Device-1 and Device-2, need separate
>>> power on/off sequence. So generic library currently we have in this
>>> patch series is not going to satisfy the need here.
>>>
>>> I looked at all 6 revisions of this patch-series, went through the
>>> review comments, and looked at MMC power sequence code;
>>> what I can say here is, we need something similar to
>>> MMC power sequence here, where every device can have its own
>>> power sequence (if needed).
>>>
>>> I know Rob is not in favor of creating platform device for
>>> this, and I understand his comment.
>>> If not platform device, but atleast we need mechanism to
>>> connect each device back to its of_node and its respective
>>> driver/library fns. For example, the Devices may support different
>>> boot modes, and platform driver needs to make sure that
>>> the right sequence is followed for booting.
>>>
>>> Peter, My apologies for taking you back again on this series.
>>> I am OK, if you wish to address this in incremental addition,
>>> but my point is, we know that the current generic way is not
>>> enough for us, so I think we should try to fix it in initial phase only.
>>>
>> Rob, it seems generic power sequence can't cover all cases.
>> Without information from DT, we can't know which power sequence
>> for which device.
>>
> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> for each library, and choose pwrseq library according to compatible
> string first, if there is no compatible string for this library, just
> use generic pwrseq library.
>

Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

  - How DTS looks like now ?? Can you put example here ?
  - Should we merge MMC power sequence in next series ?
    We also can take this as an incremental change, to avoid further
    delay :)
  - Lets also add suspend/resume callback to struct pwrseq


There are some comments I have on the patches,
I will respond directly on respective patches, it would be useful
for next series.


And Sorry for delayed response.

-- 
Thanks,
Vaibhav

[PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>> Hi all,
>>>>
>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>> power sequence library for parsing the power sequence elements on DT,
>>>> and implement generic power sequence on library. The host driver
>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>
>>>> In future, if there are special power sequence requirements, the special
>>>> power sequence library can be created.
>>>>
>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>> two hot-plug devices to simulate this use case, the related binding
>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>> using my last power sequence patch set.[3]
>>>>
>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>> need to power on itself before it can be found by ULPI bus.
>>>>
>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>> (Please ignore my response on V2)
>>>
>>> Sorry being so late in the discussion...
>>>
>>> If I am not missing anything, then I am afraid to say that the
>>> generic library
>>> implementation in this patch series is not going to solve many of
>>> the custom
>>> requirement of power on, off, etc...
>>> I know you mentioned about adding another library when we come
>>> across such platforms, but should we not keep provision (or easy
>>> hooks/path)
>>> to enable that ?
>>>
>>> Let me bring in the use case I am dealing with,
>>>
>>>
>>>                                Host
>>>                                 |
>>>                                 V
>>>                             USB port
>>> ------------------------------------------------------------
>>>                                 |
>>>                                 V
>>>                        USB HUB device (May need custom on/off seq)
>>>                                 |
>>>                                 V
>>>                =============================
>>>               |                             |
>>>               V                             V
>>>           Device-1                       Device-2
>>> (Needs special power               (Needs special power
>>>   on/off sequence.                   on/off sequence.
>>>   Also may need custom               Also, may need custom
>>>   sequence for                       sequence for
>>>   suspend/resume)                    suspend/resume)
>>>
>>>
>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>            in terms of functionality, features they support.
>>>
>>> In the above case, both Device-1 and Device-2, need separate
>>> power on/off sequence. So generic library currently we have in this
>>> patch series is not going to satisfy the need here.
>>>
>>> I looked at all 6 revisions of this patch-series, went through the
>>> review comments, and looked at MMC power sequence code;
>>> what I can say here is, we need something similar to
>>> MMC power sequence here, where every device can have its own
>>> power sequence (if needed).
>>>
>>> I know Rob is not in favor of creating platform device for
>>> this, and I understand his comment.
>>> If not platform device, but atleast we need mechanism to
>>> connect each device back to its of_node and its respective
>>> driver/library fns. For example, the Devices may support different
>>> boot modes, and platform driver needs to make sure that
>>> the right sequence is followed for booting.
>>>
>>> Peter, My apologies for taking you back again on this series.
>>> I am OK, if you wish to address this in incremental addition,
>>> but my point is, we know that the current generic way is not
>>> enough for us, so I think we should try to fix it in initial phase only.
>>>
>> Rob, it seems generic power sequence can't cover all cases.
>> Without information from DT, we can't know which power sequence
>> for which device.
>>
> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> for each library, and choose pwrseq library according to compatible
> string first, if there is no compatible string for this library, just
> use generic pwrseq library.
>

Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

  - How DTS looks like now ?? Can you put example here ?
  - Should we merge MMC power sequence in next series ?
    We also can take this as an incremental change, to avoid further
    delay :)
  - Lets also add suspend/resume callback to struct pwrseq


There are some comments I have on the patches,
I will respond directly on respective patches, it would be useful
for next series.


And Sorry for delayed response.

-- 
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> >On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> >>On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> >>>On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >>>>Hi all,
> >>>>
> >>>>This is a follow-up for my last power sequence framework patch set [1].
> >>>>According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >>>>power sequence library for parsing the power sequence elements on DT,
> >>>>and implement generic power sequence on library. The host driver
> >>>>can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >>>>
> >>>>In future, if there are special power sequence requirements, the special
> >>>>power sequence library can be created.
> >>>>
> >>>>This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >>>>two hot-plug devices to simulate this use case, the related binding
> >>>>change is updated at patch [1/6], The udoo board changes were tested
> >>>>using my last power sequence patch set.[3]
> >>>>
> >>>>Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >>>>need to power on itself before it can be found by ULPI bus.
> >>>>
> >>>>[1]http://www.spinics.net/lists/linux-usb/msg142755.html
> >>>>[2]http://www.spinics.net/lists/linux-usb/msg143106.html
> >>>>[3]http://www.spinics.net/lists/linux-usb/msg142815.html
> >>>(Please ignore my response on V2)
> >>>
> >>>Sorry being so late in the discussion...
> >>>
> >>>If I am not missing anything, then I am afraid to say that the
> >>>generic library
> >>>implementation in this patch series is not going to solve many of
> >>>the custom
> >>>requirement of power on, off, etc...
> >>>I know you mentioned about adding another library when we come
> >>>across such platforms, but should we not keep provision (or easy
> >>>hooks/path)
> >>>to enable that ?
> >>>
> >>>Let me bring in the use case I am dealing with,
> >>>
> >>>
> >>>                               Host
> >>>                                |
> >>>                                V
> >>>                            USB port
> >>>------------------------------------------------------------
> >>>                                |
> >>>                                V
> >>>                       USB HUB device (May need custom on/off seq)
> >>>                                |
> >>>                                V
> >>>               =============================
> >>>              |                             |
> >>>              V                             V
> >>>          Device-1                       Device-2
> >>>(Needs special power               (Needs special power
> >>>  on/off sequence.                   on/off sequence.
> >>>  Also may need custom               Also, may need custom
> >>>  sequence for                       sequence for
> >>>  suspend/resume)                    suspend/resume)
> >>>
> >>>
> >>>Note: Both Devices are connected to HUB via HSIC and may differ
> >>>           in terms of functionality, features they support.
> >>>
> >>>In the above case, both Device-1 and Device-2, need separate
> >>>power on/off sequence. So generic library currently we have in this
> >>>patch series is not going to satisfy the need here.
> >>>
> >>>I looked at all 6 revisions of this patch-series, went through the
> >>>review comments, and looked at MMC power sequence code;
> >>>what I can say here is, we need something similar to
> >>>MMC power sequence here, where every device can have its own
> >>>power sequence (if needed).
> >>>
> >>>I know Rob is not in favor of creating platform device for
> >>>this, and I understand his comment.
> >>>If not platform device, but atleast we need mechanism to
> >>>connect each device back to its of_node and its respective
> >>>driver/library fns. For example, the Devices may support different
> >>>boot modes, and platform driver needs to make sure that
> >>>the right sequence is followed for booting.
> >>>
> >>>Peter, My apologies for taking you back again on this series.
> >>>I am OK, if you wish to address this in incremental addition,
> >>>but my point is, we know that the current generic way is not
> >>>enough for us, so I think we should try to fix it in initial phase only.
> >>>
> >>Rob, it seems generic power sequence can't cover all cases.
> >>Without information from DT, we can't know which power sequence
> >>for which device.
> >>
> >Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> >for each library, and choose pwrseq library according to compatible
> >string first, if there is no compatible string for this library, just
> >use generic pwrseq library.
> >
> 
> Lets hear from MMC folks. Ulf, do you agree on approach
> for pwr seq ??
> 
> 
> With above approach, I kind of agree on it, but I have couple
> of comments,
> 
>  - How DTS looks like now ?? Can you put example here ?

The dts is the same with current version.

>  - Should we merge MMC power sequence in next series ?
>    We also can take this as an incremental change, to avoid further
>    delay :)

We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

>  - Lets also add suspend/resume callback to struct pwrseq
> 

Why suspend/resume can't do at related driver's suspend/resume API? 

> 
> There are some comments I have on the patches,
> I will respond directly on respective patches, it would be useful
> for next series.
> 

Thanks.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> >On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> >>On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> >>>On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >>>>Hi all,
> >>>>
> >>>>This is a follow-up for my last power sequence framework patch set [1].
> >>>>According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >>>>power sequence library for parsing the power sequence elements on DT,
> >>>>and implement generic power sequence on library. The host driver
> >>>>can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >>>>
> >>>>In future, if there are special power sequence requirements, the special
> >>>>power sequence library can be created.
> >>>>
> >>>>This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >>>>two hot-plug devices to simulate this use case, the related binding
> >>>>change is updated at patch [1/6], The udoo board changes were tested
> >>>>using my last power sequence patch set.[3]
> >>>>
> >>>>Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >>>>need to power on itself before it can be found by ULPI bus.
> >>>>
> >>>>[1]http://www.spinics.net/lists/linux-usb/msg142755.html
> >>>>[2]http://www.spinics.net/lists/linux-usb/msg143106.html
> >>>>[3]http://www.spinics.net/lists/linux-usb/msg142815.html
> >>>(Please ignore my response on V2)
> >>>
> >>>Sorry being so late in the discussion...
> >>>
> >>>If I am not missing anything, then I am afraid to say that the
> >>>generic library
> >>>implementation in this patch series is not going to solve many of
> >>>the custom
> >>>requirement of power on, off, etc...
> >>>I know you mentioned about adding another library when we come
> >>>across such platforms, but should we not keep provision (or easy
> >>>hooks/path)
> >>>to enable that ?
> >>>
> >>>Let me bring in the use case I am dealing with,
> >>>
> >>>
> >>>                               Host
> >>>                                |
> >>>                                V
> >>>                            USB port
> >>>------------------------------------------------------------
> >>>                                |
> >>>                                V
> >>>                       USB HUB device (May need custom on/off seq)
> >>>                                |
> >>>                                V
> >>>               =============================
> >>>              |                             |
> >>>              V                             V
> >>>          Device-1                       Device-2
> >>>(Needs special power               (Needs special power
> >>>  on/off sequence.                   on/off sequence.
> >>>  Also may need custom               Also, may need custom
> >>>  sequence for                       sequence for
> >>>  suspend/resume)                    suspend/resume)
> >>>
> >>>
> >>>Note: Both Devices are connected to HUB via HSIC and may differ
> >>>           in terms of functionality, features they support.
> >>>
> >>>In the above case, both Device-1 and Device-2, need separate
> >>>power on/off sequence. So generic library currently we have in this
> >>>patch series is not going to satisfy the need here.
> >>>
> >>>I looked at all 6 revisions of this patch-series, went through the
> >>>review comments, and looked at MMC power sequence code;
> >>>what I can say here is, we need something similar to
> >>>MMC power sequence here, where every device can have its own
> >>>power sequence (if needed).
> >>>
> >>>I know Rob is not in favor of creating platform device for
> >>>this, and I understand his comment.
> >>>If not platform device, but atleast we need mechanism to
> >>>connect each device back to its of_node and its respective
> >>>driver/library fns. For example, the Devices may support different
> >>>boot modes, and platform driver needs to make sure that
> >>>the right sequence is followed for booting.
> >>>
> >>>Peter, My apologies for taking you back again on this series.
> >>>I am OK, if you wish to address this in incremental addition,
> >>>but my point is, we know that the current generic way is not
> >>>enough for us, so I think we should try to fix it in initial phase only.
> >>>
> >>Rob, it seems generic power sequence can't cover all cases.
> >>Without information from DT, we can't know which power sequence
> >>for which device.
> >>
> >Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> >for each library, and choose pwrseq library according to compatible
> >string first, if there is no compatible string for this library, just
> >use generic pwrseq library.
> >
> 
> Lets hear from MMC folks. Ulf, do you agree on approach
> for pwr seq ??
> 
> 
> With above approach, I kind of agree on it, but I have couple
> of comments,
> 
>  - How DTS looks like now ?? Can you put example here ?

The dts is the same with current version.

>  - Should we merge MMC power sequence in next series ?
>    We also can take this as an incremental change, to avoid further
>    delay :)

We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

>  - Lets also add suspend/resume callback to struct pwrseq
> 

Why suspend/resume can't do at related driver's suspend/resume API? 

> 
> There are some comments I have on the patches,
> I will respond directly on respective patches, it would be useful
> for next series.
> 

Thanks.

-- 

Best Regards,
Peter Chen
--
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 v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> >On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> >>On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> >>>On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >>>>Hi all,
> >>>>
> >>>>This is a follow-up for my last power sequence framework patch set [1].
> >>>>According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >>>>power sequence library for parsing the power sequence elements on DT,
> >>>>and implement generic power sequence on library. The host driver
> >>>>can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >>>>
> >>>>In future, if there are special power sequence requirements, the special
> >>>>power sequence library can be created.
> >>>>
> >>>>This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >>>>two hot-plug devices to simulate this use case, the related binding
> >>>>change is updated at patch [1/6], The udoo board changes were tested
> >>>>using my last power sequence patch set.[3]
> >>>>
> >>>>Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >>>>need to power on itself before it can be found by ULPI bus.
> >>>>
> >>>>[1]http://www.spinics.net/lists/linux-usb/msg142755.html
> >>>>[2]http://www.spinics.net/lists/linux-usb/msg143106.html
> >>>>[3]http://www.spinics.net/lists/linux-usb/msg142815.html
> >>>(Please ignore my response on V2)
> >>>
> >>>Sorry being so late in the discussion...
> >>>
> >>>If I am not missing anything, then I am afraid to say that the
> >>>generic library
> >>>implementation in this patch series is not going to solve many of
> >>>the custom
> >>>requirement of power on, off, etc...
> >>>I know you mentioned about adding another library when we come
> >>>across such platforms, but should we not keep provision (or easy
> >>>hooks/path)
> >>>to enable that ?
> >>>
> >>>Let me bring in the use case I am dealing with,
> >>>
> >>>
> >>>                               Host
> >>>                                |
> >>>                                V
> >>>                            USB port
> >>>------------------------------------------------------------
> >>>                                |
> >>>                                V
> >>>                       USB HUB device (May need custom on/off seq)
> >>>                                |
> >>>                                V
> >>>               =============================
> >>>              |                             |
> >>>              V                             V
> >>>          Device-1                       Device-2
> >>>(Needs special power               (Needs special power
> >>>  on/off sequence.                   on/off sequence.
> >>>  Also may need custom               Also, may need custom
> >>>  sequence for                       sequence for
> >>>  suspend/resume)                    suspend/resume)
> >>>
> >>>
> >>>Note: Both Devices are connected to HUB via HSIC and may differ
> >>>           in terms of functionality, features they support.
> >>>
> >>>In the above case, both Device-1 and Device-2, need separate
> >>>power on/off sequence. So generic library currently we have in this
> >>>patch series is not going to satisfy the need here.
> >>>
> >>>I looked at all 6 revisions of this patch-series, went through the
> >>>review comments, and looked at MMC power sequence code;
> >>>what I can say here is, we need something similar to
> >>>MMC power sequence here, where every device can have its own
> >>>power sequence (if needed).
> >>>
> >>>I know Rob is not in favor of creating platform device for
> >>>this, and I understand his comment.
> >>>If not platform device, but atleast we need mechanism to
> >>>connect each device back to its of_node and its respective
> >>>driver/library fns. For example, the Devices may support different
> >>>boot modes, and platform driver needs to make sure that
> >>>the right sequence is followed for booting.
> >>>
> >>>Peter, My apologies for taking you back again on this series.
> >>>I am OK, if you wish to address this in incremental addition,
> >>>but my point is, we know that the current generic way is not
> >>>enough for us, so I think we should try to fix it in initial phase only.
> >>>
> >>Rob, it seems generic power sequence can't cover all cases.
> >>Without information from DT, we can't know which power sequence
> >>for which device.
> >>
> >Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> >for each library, and choose pwrseq library according to compatible
> >string first, if there is no compatible string for this library, just
> >use generic pwrseq library.
> >
> 
> Lets hear from MMC folks. Ulf, do you agree on approach
> for pwr seq ??
> 
> 
> With above approach, I kind of agree on it, but I have couple
> of comments,
> 
>  - How DTS looks like now ?? Can you put example here ?

The dts is the same with current version.

>  - Should we merge MMC power sequence in next series ?
>    We also can take this as an incremental change, to avoid further
>    delay :)

We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

>  - Lets also add suspend/resume callback to struct pwrseq
> 

Why suspend/resume can't do at related driver's suspend/resume API? 

> 
> There are some comments I have on the patches,
> I will respond directly on respective patches, it would be useful
> for next series.
> 

Thanks.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
> On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
>>
>> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
>>> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>>>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>>>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>>>> power sequence library for parsing the power sequence elements on DT,
>>>>>> and implement generic power sequence on library. The host driver
>>>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>>>
>>>>>> In future, if there are special power sequence requirements, the special
>>>>>> power sequence library can be created.
>>>>>>
>>>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>>>> two hot-plug devices to simulate this use case, the related binding
>>>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>>>> using my last power sequence patch set.[3]
>>>>>>
>>>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>>>> need to power on itself before it can be found by ULPI bus.
>>>>>>
>>>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>>>> (Please ignore my response on V2)
>>>>>
>>>>> Sorry being so late in the discussion...
>>>>>
>>>>> If I am not missing anything, then I am afraid to say that the
>>>>> generic library
>>>>> implementation in this patch series is not going to solve many of
>>>>> the custom
>>>>> requirement of power on, off, etc...
>>>>> I know you mentioned about adding another library when we come
>>>>> across such platforms, but should we not keep provision (or easy
>>>>> hooks/path)
>>>>> to enable that ?
>>>>>
>>>>> Let me bring in the use case I am dealing with,
>>>>>
>>>>>
>>>>>                                Host
>>>>>                                 |
>>>>>                                 V
>>>>>                             USB port
>>>>> ------------------------------------------------------------
>>>>>                                 |
>>>>>                                 V
>>>>>                        USB HUB device (May need custom on/off seq)
>>>>>                                 |
>>>>>                                 V
>>>>>                =============================
>>>>>               |                             |
>>>>>               V                             V
>>>>>           Device-1                       Device-2
>>>>> (Needs special power               (Needs special power
>>>>>   on/off sequence.                   on/off sequence.
>>>>>   Also may need custom               Also, may need custom
>>>>>   sequence for                       sequence for
>>>>>   suspend/resume)                    suspend/resume)
>>>>>
>>>>>
>>>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>>>            in terms of functionality, features they support.
>>>>>
>>>>> In the above case, both Device-1 and Device-2, need separate
>>>>> power on/off sequence. So generic library currently we have in this
>>>>> patch series is not going to satisfy the need here.
>>>>>
>>>>> I looked at all 6 revisions of this patch-series, went through the
>>>>> review comments, and looked at MMC power sequence code;
>>>>> what I can say here is, we need something similar to
>>>>> MMC power sequence here, where every device can have its own
>>>>> power sequence (if needed).
>>>>>
>>>>> I know Rob is not in favor of creating platform device for
>>>>> this, and I understand his comment.
>>>>> If not platform device, but atleast we need mechanism to
>>>>> connect each device back to its of_node and its respective
>>>>> driver/library fns. For example, the Devices may support different
>>>>> boot modes, and platform driver needs to make sure that
>>>>> the right sequence is followed for booting.
>>>>>
>>>>> Peter, My apologies for taking you back again on this series.
>>>>> I am OK, if you wish to address this in incremental addition,
>>>>> but my point is, we know that the current generic way is not
>>>>> enough for us, so I think we should try to fix it in initial phase only.
>>>>>
>>>> Rob, it seems generic power sequence can't cover all cases.
>>>> Without information from DT, we can't know which power sequence
>>>> for which device.
>>>>
>>> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
>>> for each library, and choose pwrseq library according to compatible
>>> string first, if there is no compatible string for this library, just
>>> use generic pwrseq library.
>>>
>> Lets hear from MMC folks. Ulf, do you agree on approach
>> for pwr seq ??
>>
>>
>> With above approach, I kind of agree on it, but I have couple
>> of comments,
>>
>>   - How DTS looks like now ?? Can you put example here ?
> The dts is the same with current version.

How would consumer driver get the power sequence ?
You must point to right power sequence driver.
For example, in the above example, Device-1, should
get handle to pwrseq-1, and Device-2 to pwrseq-2.

>>   - Should we merge MMC power sequence in next series ?
>>     We also can take this as an incremental change, to avoid further
>>     delay :)
> We had an agreement that keep mmc's pwrseq framework unchanging.
> Unless Ulf and rob both agree to change.

Why 2 separate approach for same problem ?
And I see this as possible duplication of code/functionality :)

Rob ??? Ulf ???

>>   - Lets also add suspend/resume callback to struct pwrseq
>>
> Why suspend/resume can't do at related driver's suspend/resume API?

Nope...
The pwrseq library would have taken ownership of resources, so
related driver cannot suspend the device. Again it is architecture
specific, but we should have provision to handle this.

The system I am dealing with today, does need suspend/resume
callback. To be precise, suspend is close to off state for some devices or
they could enter standby or different low power state, but to do that,
we need same resource as used for ON/OFF functionality.


Thanks,
Vaibhav
>> There are some comments I have on the patches,
>> I will respond directly on respective patches, it would be useful
>> for next series.
>>
> Thanks.
>

-- 
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
> On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
>>
>> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
>>> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>>>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>>>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>>>> power sequence library for parsing the power sequence elements on DT,
>>>>>> and implement generic power sequence on library. The host driver
>>>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>>>
>>>>>> In future, if there are special power sequence requirements, the special
>>>>>> power sequence library can be created.
>>>>>>
>>>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>>>> two hot-plug devices to simulate this use case, the related binding
>>>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>>>> using my last power sequence patch set.[3]
>>>>>>
>>>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>>>> need to power on itself before it can be found by ULPI bus.
>>>>>>
>>>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>>>> (Please ignore my response on V2)
>>>>>
>>>>> Sorry being so late in the discussion...
>>>>>
>>>>> If I am not missing anything, then I am afraid to say that the
>>>>> generic library
>>>>> implementation in this patch series is not going to solve many of
>>>>> the custom
>>>>> requirement of power on, off, etc...
>>>>> I know you mentioned about adding another library when we come
>>>>> across such platforms, but should we not keep provision (or easy
>>>>> hooks/path)
>>>>> to enable that ?
>>>>>
>>>>> Let me bring in the use case I am dealing with,
>>>>>
>>>>>
>>>>>                                Host
>>>>>                                 |
>>>>>                                 V
>>>>>                             USB port
>>>>> ------------------------------------------------------------
>>>>>                                 |
>>>>>                                 V
>>>>>                        USB HUB device (May need custom on/off seq)
>>>>>                                 |
>>>>>                                 V
>>>>>                =============================
>>>>>               |                             |
>>>>>               V                             V
>>>>>           Device-1                       Device-2
>>>>> (Needs special power               (Needs special power
>>>>>   on/off sequence.                   on/off sequence.
>>>>>   Also may need custom               Also, may need custom
>>>>>   sequence for                       sequence for
>>>>>   suspend/resume)                    suspend/resume)
>>>>>
>>>>>
>>>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>>>            in terms of functionality, features they support.
>>>>>
>>>>> In the above case, both Device-1 and Device-2, need separate
>>>>> power on/off sequence. So generic library currently we have in this
>>>>> patch series is not going to satisfy the need here.
>>>>>
>>>>> I looked at all 6 revisions of this patch-series, went through the
>>>>> review comments, and looked at MMC power sequence code;
>>>>> what I can say here is, we need something similar to
>>>>> MMC power sequence here, where every device can have its own
>>>>> power sequence (if needed).
>>>>>
>>>>> I know Rob is not in favor of creating platform device for
>>>>> this, and I understand his comment.
>>>>> If not platform device, but atleast we need mechanism to
>>>>> connect each device back to its of_node and its respective
>>>>> driver/library fns. For example, the Devices may support different
>>>>> boot modes, and platform driver needs to make sure that
>>>>> the right sequence is followed for booting.
>>>>>
>>>>> Peter, My apologies for taking you back again on this series.
>>>>> I am OK, if you wish to address this in incremental addition,
>>>>> but my point is, we know that the current generic way is not
>>>>> enough for us, so I think we should try to fix it in initial phase only.
>>>>>
>>>> Rob, it seems generic power sequence can't cover all cases.
>>>> Without information from DT, we can't know which power sequence
>>>> for which device.
>>>>
>>> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
>>> for each library, and choose pwrseq library according to compatible
>>> string first, if there is no compatible string for this library, just
>>> use generic pwrseq library.
>>>
>> Lets hear from MMC folks. Ulf, do you agree on approach
>> for pwr seq ??
>>
>>
>> With above approach, I kind of agree on it, but I have couple
>> of comments,
>>
>>   - How DTS looks like now ?? Can you put example here ?
> The dts is the same with current version.

How would consumer driver get the power sequence ?
You must point to right power sequence driver.
For example, in the above example, Device-1, should
get handle to pwrseq-1, and Device-2 to pwrseq-2.

>>   - Should we merge MMC power sequence in next series ?
>>     We also can take this as an incremental change, to avoid further
>>     delay :)
> We had an agreement that keep mmc's pwrseq framework unchanging.
> Unless Ulf and rob both agree to change.

Why 2 separate approach for same problem ?
And I see this as possible duplication of code/functionality :)

Rob ??? Ulf ???

>>   - Lets also add suspend/resume callback to struct pwrseq
>>
> Why suspend/resume can't do at related driver's suspend/resume API?

Nope...
The pwrseq library would have taken ownership of resources, so
related driver cannot suspend the device. Again it is architecture
specific, but we should have provision to handle this.

The system I am dealing with today, does need suspend/resume
callback. To be precise, suspend is close to off state for some devices or
they could enter standby or different low power state, but to do that,
we need same resource as used for ON/OFF functionality.


Thanks,
Vaibhav
>> There are some comments I have on the patches,
>> I will respond directly on respective patches, it would be useful
>> for next series.
>>
> Thanks.
>

-- 
Thanks,
Vaibhav

--
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 v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
> On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
>>
>> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
>>> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>>>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>>>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>>>> power sequence library for parsing the power sequence elements on DT,
>>>>>> and implement generic power sequence on library. The host driver
>>>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>>>
>>>>>> In future, if there are special power sequence requirements, the special
>>>>>> power sequence library can be created.
>>>>>>
>>>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>>>> two hot-plug devices to simulate this use case, the related binding
>>>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>>>> using my last power sequence patch set.[3]
>>>>>>
>>>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>>>> need to power on itself before it can be found by ULPI bus.
>>>>>>
>>>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>>>> (Please ignore my response on V2)
>>>>>
>>>>> Sorry being so late in the discussion...
>>>>>
>>>>> If I am not missing anything, then I am afraid to say that the
>>>>> generic library
>>>>> implementation in this patch series is not going to solve many of
>>>>> the custom
>>>>> requirement of power on, off, etc...
>>>>> I know you mentioned about adding another library when we come
>>>>> across such platforms, but should we not keep provision (or easy
>>>>> hooks/path)
>>>>> to enable that ?
>>>>>
>>>>> Let me bring in the use case I am dealing with,
>>>>>
>>>>>
>>>>>                                Host
>>>>>                                 |
>>>>>                                 V
>>>>>                             USB port
>>>>> ------------------------------------------------------------
>>>>>                                 |
>>>>>                                 V
>>>>>                        USB HUB device (May need custom on/off seq)
>>>>>                                 |
>>>>>                                 V
>>>>>                =============================
>>>>>               |                             |
>>>>>               V                             V
>>>>>           Device-1                       Device-2
>>>>> (Needs special power               (Needs special power
>>>>>   on/off sequence.                   on/off sequence.
>>>>>   Also may need custom               Also, may need custom
>>>>>   sequence for                       sequence for
>>>>>   suspend/resume)                    suspend/resume)
>>>>>
>>>>>
>>>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>>>            in terms of functionality, features they support.
>>>>>
>>>>> In the above case, both Device-1 and Device-2, need separate
>>>>> power on/off sequence. So generic library currently we have in this
>>>>> patch series is not going to satisfy the need here.
>>>>>
>>>>> I looked at all 6 revisions of this patch-series, went through the
>>>>> review comments, and looked at MMC power sequence code;
>>>>> what I can say here is, we need something similar to
>>>>> MMC power sequence here, where every device can have its own
>>>>> power sequence (if needed).
>>>>>
>>>>> I know Rob is not in favor of creating platform device for
>>>>> this, and I understand his comment.
>>>>> If not platform device, but atleast we need mechanism to
>>>>> connect each device back to its of_node and its respective
>>>>> driver/library fns. For example, the Devices may support different
>>>>> boot modes, and platform driver needs to make sure that
>>>>> the right sequence is followed for booting.
>>>>>
>>>>> Peter, My apologies for taking you back again on this series.
>>>>> I am OK, if you wish to address this in incremental addition,
>>>>> but my point is, we know that the current generic way is not
>>>>> enough for us, so I think we should try to fix it in initial phase only.
>>>>>
>>>> Rob, it seems generic power sequence can't cover all cases.
>>>> Without information from DT, we can't know which power sequence
>>>> for which device.
>>>>
>>> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
>>> for each library, and choose pwrseq library according to compatible
>>> string first, if there is no compatible string for this library, just
>>> use generic pwrseq library.
>>>
>> Lets hear from MMC folks. Ulf, do you agree on approach
>> for pwr seq ??
>>
>>
>> With above approach, I kind of agree on it, but I have couple
>> of comments,
>>
>>   - How DTS looks like now ?? Can you put example here ?
> The dts is the same with current version.

How would consumer driver get the power sequence ?
You must point to right power sequence driver.
For example, in the above example, Device-1, should
get handle to pwrseq-1, and Device-2 to pwrseq-2.

>>   - Should we merge MMC power sequence in next series ?
>>     We also can take this as an incremental change, to avoid further
>>     delay :)
> We had an agreement that keep mmc's pwrseq framework unchanging.
> Unless Ulf and rob both agree to change.

Why 2 separate approach for same problem ?
And I see this as possible duplication of code/functionality :)

Rob ??? Ulf ???

>>   - Lets also add suspend/resume callback to struct pwrseq
>>
> Why suspend/resume can't do at related driver's suspend/resume API?

Nope...
The pwrseq library would have taken ownership of resources, so
related driver cannot suspend the device. Again it is architecture
specific, but we should have provision to handle this.

The system I am dealing with today, does need suspend/resume
callback. To be precise, suspend is close to off state for some devices or
they could enter standby or different low power state, but to do that,
we need same resource as used for ON/OFF functionality.


Thanks,
Vaibhav
>> There are some comments I have on the patches,
>> I will respond directly on respective patches, it would be useful
>> for next series.
>>
> Thanks.
>

-- 
Thanks,
Vaibhav

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
>
> In this patch, it calls power sequence library APIs to finish
> the power sequence events. At first, it calls pwrseq_alloc_generic
> to create a generic power sequence instance, then it will do power
> on sequence at hub's probe for all devices under this hub
> (includes root hub).
>
> At hub_disconnect, it will do power off sequence which is at powered
> on list.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> ---
>   drivers/usb/core/Makefile |   1 +
>   drivers/usb/core/hub.c    |  12 ++++--
>   drivers/usb/core/hub.h    |  12 ++++++
>   drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
>   4 files changed, 122 insertions(+), 3 deletions(-)
>   create mode 100644 drivers/usb/core/pwrseq.c
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 9780877..39f2149 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
>   
>   usbcore-$(CONFIG_PCI)		+= hcd-pci.o
>   usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
>   
>   obj-$(CONFIG_USB)		+= usbcore.o
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bee1351..a346a8b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
>   	hub->error = 0;
>   	hub_quiesce(hub, HUB_DISCONNECT);
>   
> +	hub_pwrseq_off(hub);
>   	mutex_lock(&usb_port_peer_mutex);
>   
>   	/* Avoid races with recursively_mark_NOTATTACHED() */
> @@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
>   	struct usb_endpoint_descriptor *endpoint;
>   	struct usb_device *hdev;
>   	struct usb_hub *hub;
> +	int ret = -ENODEV;
>   
>   	desc = intf->cur_altsetting;
>   	hdev = interface_to_usbdev(intf);
> @@ -1839,6 +1841,7 @@ descriptor_error:
>   	INIT_DELAYED_WORK(&hub->leds, led_work);
>   	INIT_DELAYED_WORK(&hub->init_work, NULL);
>   	INIT_WORK(&hub->events, hub_event);
> +	INIT_LIST_HEAD(&hub->pwrseq_on_list);
>   	usb_get_intf(intf);
>   	usb_get_dev(hdev);
>   
> @@ -1852,11 +1855,14 @@ descriptor_error:
>   	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
>   		hub->quirk_check_port_auto_suspend = 1;
>   
> -	if (hub_configure(hub, endpoint) >= 0)
> -		return 0;
> +	if (hub_configure(hub, endpoint) >= 0) {
> +		ret = hub_pwrseq_on(hub);
> +		if (!ret)
> +			return 0;
> +	}
>   
>   	hub_disconnect(intf);
> -	return -ENODEV;
> +	return ret;
>   }
>   
>   static int
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 34c1a7e..9473f6f 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -78,6 +78,7 @@ struct usb_hub {
>   	struct delayed_work	init_work;
>   	struct work_struct      events;
>   	struct usb_port		**ports;
> +	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
>   };
>   
>   /**
> @@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
>   {
>   	return hub_port_debounce(hub, port1, false);
>   }
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +int hub_pwrseq_on(struct usb_hub *hub);
> +void hub_pwrseq_off(struct usb_hub *hub);
> +#else
> +static inline int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	return 0;
> +}
> +static inline void hub_pwrseq_off(struct usb_hub *hub) {}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
> new file mode 100644
> index 0000000..837fe66
> --- /dev/null
> +++ b/drivers/usb/core/pwrseq.c
> @@ -0,0 +1,100 @@
> +/*
> + * pwrseq.c	USB device power sequence management
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/power/pwrseq.h>
> +#include <linux/slab.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#include "hub.h"
> +
> +struct usb_pwrseq_node {
> +	struct pwrseq *pwrseq;
> +	struct list_head list;
> +};
> +
> +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node;
> +	int ret;
> +
> +	pwrseq = pwrseq_alloc_generic();
> +	if (IS_ERR(pwrseq))
> +		return PTR_ERR(pwrseq);
> +
> +	ret = pwrseq_get(np, pwrseq);
> +	if (ret)
> +		goto pwr_free;
> +
> +	ret = pwrseq_on(np, pwrseq);
> +	if (ret)
> +		goto pwr_put;
> +
> +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);

You probably want to check the return value here.

I think someone already commented on this, but still for the record
providing it.

Thanks,
Vaibhav
> +	pwrseq_node->pwrseq = pwrseq;
> +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> +
> +	return 0;
> +
> +pwr_put:
> +	pwrseq_put(pwrseq);
> +pwr_free:
> +	pwrseq_free(pwrseq);
> +	return ret;
> +}
> +
> +int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	struct device *parent;
> +	struct usb_device *hdev = hub->hdev;
> +	struct device_node *np;
> +	int ret;
> +
> +	if (hdev->parent)
> +		parent = &hdev->dev;
> +	else
> +		parent = bus_to_hcd(hdev->bus)->self.controller;
> +
> +	for_each_child_of_node(parent->of_node, np) {
> +		ret = hub_of_pwrseq_on(np, hub);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +void hub_pwrseq_off(struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
> +
> +	list_for_each_entry_safe(pwrseq_node, tmp_node,
> +			&hub->pwrseq_on_list, list) {
> +		pwrseq = pwrseq_node->pwrseq;
> +		pwrseq_off(pwrseq);
> +		pwrseq_put(pwrseq);
> +		pwrseq_free(pwrseq);
> +		list_del(&pwrseq_node->list);
> +		kfree(pwrseq_node);
> +	}
> +}

-- 
Thanks,
Vaibhav

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
>
> In this patch, it calls power sequence library APIs to finish
> the power sequence events. At first, it calls pwrseq_alloc_generic
> to create a generic power sequence instance, then it will do power
> on sequence at hub's probe for all devices under this hub
> (includes root hub).
>
> At hub_disconnect, it will do power off sequence which is at powered
> on list.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> ---
>   drivers/usb/core/Makefile |   1 +
>   drivers/usb/core/hub.c    |  12 ++++--
>   drivers/usb/core/hub.h    |  12 ++++++
>   drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
>   4 files changed, 122 insertions(+), 3 deletions(-)
>   create mode 100644 drivers/usb/core/pwrseq.c
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 9780877..39f2149 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
>   
>   usbcore-$(CONFIG_PCI)		+= hcd-pci.o
>   usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
>   
>   obj-$(CONFIG_USB)		+= usbcore.o
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bee1351..a346a8b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
>   	hub->error = 0;
>   	hub_quiesce(hub, HUB_DISCONNECT);
>   
> +	hub_pwrseq_off(hub);
>   	mutex_lock(&usb_port_peer_mutex);
>   
>   	/* Avoid races with recursively_mark_NOTATTACHED() */
> @@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
>   	struct usb_endpoint_descriptor *endpoint;
>   	struct usb_device *hdev;
>   	struct usb_hub *hub;
> +	int ret = -ENODEV;
>   
>   	desc = intf->cur_altsetting;
>   	hdev = interface_to_usbdev(intf);
> @@ -1839,6 +1841,7 @@ descriptor_error:
>   	INIT_DELAYED_WORK(&hub->leds, led_work);
>   	INIT_DELAYED_WORK(&hub->init_work, NULL);
>   	INIT_WORK(&hub->events, hub_event);
> +	INIT_LIST_HEAD(&hub->pwrseq_on_list);
>   	usb_get_intf(intf);
>   	usb_get_dev(hdev);
>   
> @@ -1852,11 +1855,14 @@ descriptor_error:
>   	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
>   		hub->quirk_check_port_auto_suspend = 1;
>   
> -	if (hub_configure(hub, endpoint) >= 0)
> -		return 0;
> +	if (hub_configure(hub, endpoint) >= 0) {
> +		ret = hub_pwrseq_on(hub);
> +		if (!ret)
> +			return 0;
> +	}
>   
>   	hub_disconnect(intf);
> -	return -ENODEV;
> +	return ret;
>   }
>   
>   static int
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 34c1a7e..9473f6f 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -78,6 +78,7 @@ struct usb_hub {
>   	struct delayed_work	init_work;
>   	struct work_struct      events;
>   	struct usb_port		**ports;
> +	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
>   };
>   
>   /**
> @@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
>   {
>   	return hub_port_debounce(hub, port1, false);
>   }
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +int hub_pwrseq_on(struct usb_hub *hub);
> +void hub_pwrseq_off(struct usb_hub *hub);
> +#else
> +static inline int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	return 0;
> +}
> +static inline void hub_pwrseq_off(struct usb_hub *hub) {}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
> new file mode 100644
> index 0000000..837fe66
> --- /dev/null
> +++ b/drivers/usb/core/pwrseq.c
> @@ -0,0 +1,100 @@
> +/*
> + * pwrseq.c	USB device power sequence management
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/power/pwrseq.h>
> +#include <linux/slab.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#include "hub.h"
> +
> +struct usb_pwrseq_node {
> +	struct pwrseq *pwrseq;
> +	struct list_head list;
> +};
> +
> +static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node;
> +	int ret;
> +
> +	pwrseq = pwrseq_alloc_generic();
> +	if (IS_ERR(pwrseq))
> +		return PTR_ERR(pwrseq);
> +
> +	ret = pwrseq_get(np, pwrseq);
> +	if (ret)
> +		goto pwr_free;
> +
> +	ret = pwrseq_on(np, pwrseq);
> +	if (ret)
> +		goto pwr_put;
> +
> +	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);

You probably want to check the return value here.

I think someone already commented on this, but still for the record
providing it.

Thanks,
Vaibhav
> +	pwrseq_node->pwrseq = pwrseq;
> +	list_add(&pwrseq_node->list, &hub->pwrseq_on_list);
> +
> +	return 0;
> +
> +pwr_put:
> +	pwrseq_put(pwrseq);
> +pwr_free:
> +	pwrseq_free(pwrseq);
> +	return ret;
> +}
> +
> +int hub_pwrseq_on(struct usb_hub *hub)
> +{
> +	struct device *parent;
> +	struct usb_device *hdev = hub->hdev;
> +	struct device_node *np;
> +	int ret;
> +
> +	if (hdev->parent)
> +		parent = &hdev->dev;
> +	else
> +		parent = bus_to_hcd(hdev->bus)->self.controller;
> +
> +	for_each_child_of_node(parent->of_node, np) {
> +		ret = hub_of_pwrseq_on(np, hub);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +void hub_pwrseq_off(struct usb_hub *hub)
> +{
> +	struct pwrseq *pwrseq;
> +	struct usb_pwrseq_node *pwrseq_node, *tmp_node;
> +
> +	list_for_each_entry_safe(pwrseq_node, tmp_node,
> +			&hub->pwrseq_on_list, list) {
> +		pwrseq = pwrseq_node->pwrseq;
> +		pwrseq_off(pwrseq);
> +		pwrseq_put(pwrseq);
> +		pwrseq_free(pwrseq);
> +		list_del(&pwrseq_node->list);
> +		kfree(pwrseq_node);
> +	}
> +}

-- 
Thanks,
Vaibhav

Re: [PATCH v6 2/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver calls pwrseq_alloc_generic to create
> an generic pwrseq instance.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
> ---
>   MAINTAINERS                           |   9 ++
>   drivers/power/Kconfig                 |   1 +
>   drivers/power/Makefile                |   1 +
>   drivers/power/pwrseq/Kconfig          |  20 ++++
>   drivers/power/pwrseq/Makefile         |   2 +
>   drivers/power/pwrseq/core.c           |  62 +++++++++++++
>   drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
>   include/linux/power/pwrseq.h          |  47 ++++++++++
>   8 files changed, 310 insertions(+)
>   create mode 100644 drivers/power/pwrseq/Kconfig
>   create mode 100644 drivers/power/pwrseq/Makefile
>   create mode 100644 drivers/power/pwrseq/core.c
>   create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>   create mode 100644 include/linux/power/pwrseq.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ae6c84..407254b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
>   F:	include/linux/powercap.h
>   F:	drivers/powercap/
>   
> +POWER SEQUENCE LIBRARY
> +M:	Peter Chen <Peter.Chen@nxp.com>
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L:	linux-pm@vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/power/pwrseq/
> +F:	drivers/power/pwrseq/
> +F:	include/linux/power/pwrseq.h/
> +
>   POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
>   M:	Sebastian Reichel <sre@kernel.org>
>   M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index acd4a15..f6aa4fd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -515,3 +515,4 @@ endif # POWER_SUPPLY
>   
>   source "drivers/power/reset/Kconfig"
>   source "drivers/power/avs/Kconfig"
> +source "drivers/power/pwrseq/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..4ed2e12 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
>   obj-$(CONFIG_POWER_RESET)	+= reset/
>   obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>   obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
> +obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..188729e
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,20 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> +	bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> +	bool "Generic power sequence control"
> +	depends on OF
> +	select POWER_SEQUENCE
> +	help
> +	  It is used for drivers which needs to do power sequence
> +	  (eg, turn on clock, toggle reset gpio) before the related
> +	  devices can be found by hardware. This generic one can be
> +	  used for common power sequence control.
> +
> +endmenu
> diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
> new file mode 100644
> index 0000000..ad82389
> --- /dev/null
> +++ b/drivers/power/pwrseq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQUENCE) += core.o
> +obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
> diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
> new file mode 100644
> index 0000000..dcf96c4
> --- /dev/null
> +++ b/drivers/power/pwrseq/core.c
> @@ -0,0 +1,62 @@
> +/*
> + * core.c	power sequence core file
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/power/pwrseq.h>
> +
> +static DEFINE_MUTEX(pwrseq_list_mutex);
> +static LIST_HEAD(pwrseq_list);
> +
> +int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->get)
> +		return p->get(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_get);
> +
> +int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->on)
> +		return p->on(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_on);
> +
> +void pwrseq_off(struct pwrseq *p)
> +{
> +	if (p && p->off)
> +		p->off(p);
> +}
> +EXPORT_SYMBOL(pwrseq_off);
> +
> +void pwrseq_put(struct pwrseq *p)
> +{
> +	if (p && p->put)
> +		p->put(p);
> +}
> +EXPORT_SYMBOL(pwrseq_put);
> +
> +void pwrseq_free(struct pwrseq *p)
> +{
> +	if (p && p->free)
> +		p->free(p);
> +}
> +EXPORT_SYMBOL(pwrseq_free);
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
> new file mode 100644
> index 0000000..8af626f
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
> @@ -0,0 +1,168 @@
> +/*
> + * pwrseq_generic.c	Generic power sequence handling
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/slab.h>
> +
> +#include <linux/power/pwrseq.h>
> +
> +struct pwrseq_generic {
> +	struct pwrseq pwrseq;
> +	struct gpio_desc *gpiod_reset;
> +	struct clk *clks[PWRSEQ_MAX_CLKS];
> +};
> +
> +#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
> +
> +static void pwrseq_generic_free(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +
> +	kfree(pwrseq_gen);
> +}
> +
> +static void pwrseq_generic_put(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	if (pwrseq_gen->gpiod_reset)
> +		gpiod_put(pwrseq_gen->gpiod_reset);
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
> +		clk_put(pwrseq_gen->clks[clk]);
> +}
> +
> +static void pwrseq_generic_off(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +}
> +
> +static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
Ideally you shouldn't need device_node here at this stage.
I expect to extract all the resource information in _get() itself.

> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk, ret = 0;
> +	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
> +		if (ret) {
> +			pr_err("Can't enable clock on %s: %d\n",
> +				np->full_name, ret);
> +			goto err_disable_clks;
> +		}
> +	}
> +
> +	if (gpiod_reset) {
> +		u32 duration_us = 50;
Why initialize to 50 ??

> +
> +		of_property_read_u32(np, "reset-duration-us",
> +				&duration_us);
> +		if (duration_us <= 10)
> +			udelay(10);
> +		else
> +			usleep_range(duration_us, duration_us + 100);
> +		gpiod_set_value(gpiod_reset, 0);
> +	}
> +
> +	return ret;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +
> +	return ret;
> +}
> +
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	enum of_gpio_flags flags;
> +	int reset_gpio, clk, ret = 0;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> +		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> +		if (IS_ERR(pwrseq_gen->clks[clk])) {
> +			ret = PTR_ERR(pwrseq_gen->clks[clk]);
> +			if (ret == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			pwrseq_gen->clks[clk] = NULL;
> +			break;

Do we really want to continue here, even we failed to get the clock ?

> +		}
> +	}
> +
> +	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> +	if (gpio_is_valid(reset_gpio)) {
> +		unsigned long gpio_flags;
> +
> +		if (flags & OF_GPIO_ACTIVE_LOW)
> +			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> +		else
> +			gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> +		ret = gpio_request_one(reset_gpio, gpio_flags,
> +				"pwrseq-reset-gpios");
> +		if (ret)
> +			goto err_put_clks;
> +
> +		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> +	} else {
> +		if (reset_gpio == -ENOENT)
> +			return 0;

Why are we returning success here ?

> +
> +		ret = reset_gpio;
> +		pr_err("Failed to get reset gpio on %s, err = %d\n",
> +				np->full_name, reset_gpio);
> +		goto err_put_clks;
> +	}
> +
> +	return ret;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(pwrseq_gen->clks[clk]);
> +	return ret;
> +}
> +
> +struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	struct pwrseq_generic *pwrseq_gen;
> +
> +	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> +	if (!pwrseq_gen)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> +	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> +	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> +	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> +	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> +	return &pwrseq_gen->pwrseq;
> +}
> +EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);

With recent discussion on postcore_initcall, we probably can merge
_get() and _alloc() fns.

Thanks,
Vaibhav
> diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
> new file mode 100644
> index 0000000..ebb2280
> --- /dev/null
> +++ b/include/linux/power/pwrseq.h
> @@ -0,0 +1,47 @@
> +#ifndef __LINUX_PWRSEQ_H
> +#define __LINUX_PWRSEQ_H
> +
> +#include <linux/of.h>
> +
> +#define PWRSEQ_MAX_CLKS		3
> +
> +struct pwrseq {
> +	char *name;
> +	struct list_head node;
> +	int (*get)(struct device_node *np, struct pwrseq *p);
> +	int (*on)(struct device_node *np, struct pwrseq *p);
> +	void (*off)(struct pwrseq *p);
> +	void (*put)(struct pwrseq *p);
> +	void (*free)(struct pwrseq *p);
> +};
> +
> +#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
> +int pwrseq_get(struct device_node *np, struct pwrseq *p);
> +int pwrseq_on(struct device_node *np, struct pwrseq *p);
> +void pwrseq_off(struct pwrseq *p);
> +void pwrseq_put(struct pwrseq *p);
> +void pwrseq_free(struct pwrseq *p);
> +#else
> +static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline void pwrseq_off(struct pwrseq *p) {}
> +static inline void pwrseq_put(struct pwrseq *p) {}
> +static inline void pwrseq_free(struct pwrseq *p) {}
> +#endif /* CONFIG_POWER_SEQUENCE */
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +struct pwrseq *pwrseq_alloc_generic(void);
> +#else
> +static inline struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> +
> +#endif  /* __LINUX_PWRSEQ_H */

-- 
Thanks,
Vaibhav

[PATCH v6 2/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver calls pwrseq_alloc_generic to create
> an generic pwrseq instance.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
> ---
>   MAINTAINERS                           |   9 ++
>   drivers/power/Kconfig                 |   1 +
>   drivers/power/Makefile                |   1 +
>   drivers/power/pwrseq/Kconfig          |  20 ++++
>   drivers/power/pwrseq/Makefile         |   2 +
>   drivers/power/pwrseq/core.c           |  62 +++++++++++++
>   drivers/power/pwrseq/pwrseq_generic.c | 168 ++++++++++++++++++++++++++++++++++
>   include/linux/power/pwrseq.h          |  47 ++++++++++
>   8 files changed, 310 insertions(+)
>   create mode 100644 drivers/power/pwrseq/Kconfig
>   create mode 100644 drivers/power/pwrseq/Makefile
>   create mode 100644 drivers/power/pwrseq/core.c
>   create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>   create mode 100644 include/linux/power/pwrseq.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ae6c84..407254b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9283,6 +9283,15 @@ F:	include/linux/pm_*
>   F:	include/linux/powercap.h
>   F:	drivers/powercap/
>   
> +POWER SEQUENCE LIBRARY
> +M:	Peter Chen <Peter.Chen@nxp.com>
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L:	linux-pm at vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/power/pwrseq/
> +F:	drivers/power/pwrseq/
> +F:	include/linux/power/pwrseq.h/
> +
>   POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
>   M:	Sebastian Reichel <sre@kernel.org>
>   M:	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index acd4a15..f6aa4fd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -515,3 +515,4 @@ endif # POWER_SUPPLY
>   
>   source "drivers/power/reset/Kconfig"
>   source "drivers/power/avs/Kconfig"
> +source "drivers/power/pwrseq/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..4ed2e12 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)	+= tps65217_charger.o
>   obj-$(CONFIG_POWER_RESET)	+= reset/
>   obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>   obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
> +obj-$(CONFIG_POWER_SEQUENCE)	+= pwrseq/
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..188729e
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,20 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> +	bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> +	bool "Generic power sequence control"
> +	depends on OF
> +	select POWER_SEQUENCE
> +	help
> +	  It is used for drivers which needs to do power sequence
> +	  (eg, turn on clock, toggle reset gpio) before the related
> +	  devices can be found by hardware. This generic one can be
> +	  used for common power sequence control.
> +
> +endmenu
> diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
> new file mode 100644
> index 0000000..ad82389
> --- /dev/null
> +++ b/drivers/power/pwrseq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQUENCE) += core.o
> +obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
> diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
> new file mode 100644
> index 0000000..dcf96c4
> --- /dev/null
> +++ b/drivers/power/pwrseq/core.c
> @@ -0,0 +1,62 @@
> +/*
> + * core.c	power sequence core file
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/power/pwrseq.h>
> +
> +static DEFINE_MUTEX(pwrseq_list_mutex);
> +static LIST_HEAD(pwrseq_list);
> +
> +int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->get)
> +		return p->get(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_get);
> +
> +int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	if (p && p->on)
> +		return p->on(np, p);
> +
> +	return -ENOTSUPP;
> +}
> +EXPORT_SYMBOL(pwrseq_on);
> +
> +void pwrseq_off(struct pwrseq *p)
> +{
> +	if (p && p->off)
> +		p->off(p);
> +}
> +EXPORT_SYMBOL(pwrseq_off);
> +
> +void pwrseq_put(struct pwrseq *p)
> +{
> +	if (p && p->put)
> +		p->put(p);
> +}
> +EXPORT_SYMBOL(pwrseq_put);
> +
> +void pwrseq_free(struct pwrseq *p)
> +{
> +	if (p && p->free)
> +		p->free(p);
> +}
> +EXPORT_SYMBOL(pwrseq_free);
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c b/drivers/power/pwrseq/pwrseq_generic.c
> new file mode 100644
> index 0000000..8af626f
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
> @@ -0,0 +1,168 @@
> +/*
> + * pwrseq_generic.c	Generic power sequence handling
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen@nxp.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/slab.h>
> +
> +#include <linux/power/pwrseq.h>
> +
> +struct pwrseq_generic {
> +	struct pwrseq pwrseq;
> +	struct gpio_desc *gpiod_reset;
> +	struct clk *clks[PWRSEQ_MAX_CLKS];
> +};
> +
> +#define to_generic_pwrseq(p) container_of(p, struct pwrseq_generic, pwrseq)
> +
> +static void pwrseq_generic_free(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +
> +	kfree(pwrseq_gen);
> +}
> +
> +static void pwrseq_generic_put(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	if (pwrseq_gen->gpiod_reset)
> +		gpiod_put(pwrseq_gen->gpiod_reset);
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
> +		clk_put(pwrseq_gen->clks[clk]);
> +}
> +
> +static void pwrseq_generic_off(struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk;
> +
> +	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +}
> +
> +static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
Ideally you shouldn't need device_node here at this stage.
I expect to extract all the resource information in _get() itself.

> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	int clk, ret = 0;
> +	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
> +		if (ret) {
> +			pr_err("Can't enable clock on %s: %d\n",
> +				np->full_name, ret);
> +			goto err_disable_clks;
> +		}
> +	}
> +
> +	if (gpiod_reset) {
> +		u32 duration_us = 50;
Why initialize to 50 ??

> +
> +		of_property_read_u32(np, "reset-duration-us",
> +				&duration_us);
> +		if (duration_us <= 10)
> +			udelay(10);
> +		else
> +			usleep_range(duration_us, duration_us + 100);
> +		gpiod_set_value(gpiod_reset, 0);
> +	}
> +
> +	return ret;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> +
> +	return ret;
> +}
> +
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> +{
> +	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> +	enum of_gpio_flags flags;
> +	int reset_gpio, clk, ret = 0;
> +
> +	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> +		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> +		if (IS_ERR(pwrseq_gen->clks[clk])) {
> +			ret = PTR_ERR(pwrseq_gen->clks[clk]);
> +			if (ret == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			pwrseq_gen->clks[clk] = NULL;
> +			break;

Do we really want to continue here, even we failed to get the clock ?

> +		}
> +	}
> +
> +	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> +	if (gpio_is_valid(reset_gpio)) {
> +		unsigned long gpio_flags;
> +
> +		if (flags & OF_GPIO_ACTIVE_LOW)
> +			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> +		else
> +			gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> +		ret = gpio_request_one(reset_gpio, gpio_flags,
> +				"pwrseq-reset-gpios");
> +		if (ret)
> +			goto err_put_clks;
> +
> +		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> +	} else {
> +		if (reset_gpio == -ENOENT)
> +			return 0;

Why are we returning success here ?

> +
> +		ret = reset_gpio;
> +		pr_err("Failed to get reset gpio on %s, err = %d\n",
> +				np->full_name, reset_gpio);
> +		goto err_put_clks;
> +	}
> +
> +	return ret;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(pwrseq_gen->clks[clk]);
> +	return ret;
> +}
> +
> +struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	struct pwrseq_generic *pwrseq_gen;
> +
> +	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> +	if (!pwrseq_gen)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> +	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> +	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> +	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> +	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> +	return &pwrseq_gen->pwrseq;
> +}
> +EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);

With recent discussion on postcore_initcall, we probably can merge
_get() and _alloc() fns.

Thanks,
Vaibhav
> diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
> new file mode 100644
> index 0000000..ebb2280
> --- /dev/null
> +++ b/include/linux/power/pwrseq.h
> @@ -0,0 +1,47 @@
> +#ifndef __LINUX_PWRSEQ_H
> +#define __LINUX_PWRSEQ_H
> +
> +#include <linux/of.h>
> +
> +#define PWRSEQ_MAX_CLKS		3
> +
> +struct pwrseq {
> +	char *name;
> +	struct list_head node;
> +	int (*get)(struct device_node *np, struct pwrseq *p);
> +	int (*on)(struct device_node *np, struct pwrseq *p);
> +	void (*off)(struct pwrseq *p);
> +	void (*put)(struct pwrseq *p);
> +	void (*free)(struct pwrseq *p);
> +};
> +
> +#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
> +int pwrseq_get(struct device_node *np, struct pwrseq *p);
> +int pwrseq_on(struct device_node *np, struct pwrseq *p);
> +void pwrseq_off(struct pwrseq *p);
> +void pwrseq_put(struct pwrseq *p);
> +void pwrseq_free(struct pwrseq *p);
> +#else
> +static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
> +{
> +	return 0;
> +}
> +static inline void pwrseq_off(struct pwrseq *p) {}
> +static inline void pwrseq_put(struct pwrseq *p) {}
> +static inline void pwrseq_free(struct pwrseq *p) {}
> +#endif /* CONFIG_POWER_SEQUENCE */
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +struct pwrseq *pwrseq_alloc_generic(void);
> +#else
> +static inline struct pwrseq *pwrseq_alloc_generic(void)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> +
> +#endif  /* __LINUX_PWRSEQ_H */

-- 
Thanks,
Vaibhav

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Add binding doc for generic power sequence library.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>   .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
>   1 file changed, 48 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>
> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> new file mode 100644
> index 0000000..ebf0d47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> @@ -0,0 +1,48 @@
> +The generic power sequence library
> +
> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
> +the device can be enumerated on the bus, the typical power sequence
> +like: enable USB PHY clock, toggle reset pin, etc. But current
> +Linux device driver lacks of such code to do it, it may cause some
> +hard-wired devices works abnormal or can't be recognized by
> +controller at all. The power sequence will be done before this device
> +can be found at the bus.
> +
> +The power sequence properties is under the device node.
> +
> +Optional properties:
> +- clocks: the input clocks for device.
> +- reset-gpios: Should specify the GPIO for reset.
> +- reset-duration-us: the duration in microsecond for assert reset signal.
> +
> +Below is the example of USB power sequence properties on USB device
> +nodes which have two level USB hubs.
> +
> +&usbotg1 {
> +	vbus-supply = <&reg_usb_otg1_vbus>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usb_otg1_id>;
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	genesys: hub@1 {
> +		compatible = "usb5e3,608";
> +		reg = <1>;
> +
> +		clocks = <&clks IMX6SX_CLK_CKO>;
> +		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> +		reset-duration-us = <10>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		asix: ethernet@1 {
> +			compatible = "usbb95,1708";

So I assume, with our recent discussion and the change
we are proposing, the library would have some knowledge
about this compatible string, right?

what I was asking on other email was, how are you connecting
multiple power sequence libraries to their respective consumers ?

Thanks,
Vaibhav

> +			reg = <1>;
> +
> +			clocks = <&clks IMX6SX_CLK_IPG>;
> +			reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* ethernet_rst */
> +			reset-duration-us = <15>;
> +		};
> +	};
> +};

-- 
Thanks,
Vaibhav

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Add binding doc for generic power sequence library.
>
> Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
> Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>   .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
>   1 file changed, 48 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>
> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> new file mode 100644
> index 0000000..ebf0d47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> @@ -0,0 +1,48 @@
> +The generic power sequence library
> +
> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
> +the device can be enumerated on the bus, the typical power sequence
> +like: enable USB PHY clock, toggle reset pin, etc. But current
> +Linux device driver lacks of such code to do it, it may cause some
> +hard-wired devices works abnormal or can't be recognized by
> +controller at all. The power sequence will be done before this device
> +can be found at the bus.
> +
> +The power sequence properties is under the device node.
> +
> +Optional properties:
> +- clocks: the input clocks for device.
> +- reset-gpios: Should specify the GPIO for reset.
> +- reset-duration-us: the duration in microsecond for assert reset signal.
> +
> +Below is the example of USB power sequence properties on USB device
> +nodes which have two level USB hubs.
> +
> +&usbotg1 {
> +	vbus-supply = <&reg_usb_otg1_vbus>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usb_otg1_id>;
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	genesys: hub@1 {
> +		compatible = "usb5e3,608";
> +		reg = <1>;
> +
> +		clocks = <&clks IMX6SX_CLK_CKO>;
> +		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> +		reset-duration-us = <10>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		asix: ethernet@1 {
> +			compatible = "usbb95,1708";

So I assume, with our recent discussion and the change
we are proposing, the library would have some knowledge
about this compatible string, right?

what I was asking on other email was, how are you connecting
multiple power sequence libraries to their respective consumers ?

Thanks,
Vaibhav

> +			reg = <1>;
> +
> +			clocks = <&clks IMX6SX_CLK_IPG>;
> +			reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* ethernet_rst */
> +			reset-duration-us = <15>;
> +		};
> +	};
> +};

-- 
Thanks,
Vaibhav

--
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 v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> Add binding doc for generic power sequence library.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>   .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
>   1 file changed, 48 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>
> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> new file mode 100644
> index 0000000..ebf0d47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> @@ -0,0 +1,48 @@
> +The generic power sequence library
> +
> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
> +the device can be enumerated on the bus, the typical power sequence
> +like: enable USB PHY clock, toggle reset pin, etc. But current
> +Linux device driver lacks of such code to do it, it may cause some
> +hard-wired devices works abnormal or can't be recognized by
> +controller at all. The power sequence will be done before this device
> +can be found at the bus.
> +
> +The power sequence properties is under the device node.
> +
> +Optional properties:
> +- clocks: the input clocks for device.
> +- reset-gpios: Should specify the GPIO for reset.
> +- reset-duration-us: the duration in microsecond for assert reset signal.
> +
> +Below is the example of USB power sequence properties on USB device
> +nodes which have two level USB hubs.
> +
> +&usbotg1 {
> +	vbus-supply = <&reg_usb_otg1_vbus>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usb_otg1_id>;
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	genesys: hub at 1 {
> +		compatible = "usb5e3,608";
> +		reg = <1>;
> +
> +		clocks = <&clks IMX6SX_CLK_CKO>;
> +		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> +		reset-duration-us = <10>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		asix: ethernet at 1 {
> +			compatible = "usbb95,1708";

So I assume, with our recent discussion and the change
we are proposing, the library would have some knowledge
about this compatible string, right?

what I was asking on other email was, how are you connecting
multiple power sequence libraries to their respective consumers ?

Thanks,
Vaibhav

> +			reg = <1>;
> +
> +			clocks = <&clks IMX6SX_CLK_IPG>;
> +			reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* ethernet_rst */
> +			reset-duration-us = <15>;
> +		};
> +	};
> +};

-- 
Thanks,
Vaibhav

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Add binding doc for generic power sequence library.
> >
> >Signed-off-by: Peter Chen <peter.chen@nxp.com>
> >Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> >Acked-by: Rob Herring <robh@kernel.org>
> >---
> >  .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >
> >diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >new file mode 100644
> >index 0000000..ebf0d47
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >@@ -0,0 +1,48 @@
> >+The generic power sequence library
> >+
> >+Some hard-wired devices (eg USB/MMC) need to do power sequence before
> >+the device can be enumerated on the bus, the typical power sequence
> >+like: enable USB PHY clock, toggle reset pin, etc. But current
> >+Linux device driver lacks of such code to do it, it may cause some
> >+hard-wired devices works abnormal or can't be recognized by
> >+controller at all. The power sequence will be done before this device
> >+can be found at the bus.
> >+
> >+The power sequence properties is under the device node.
> >+
> >+Optional properties:
> >+- clocks: the input clocks for device.
> >+- reset-gpios: Should specify the GPIO for reset.
> >+- reset-duration-us: the duration in microsecond for assert reset signal.
> >+
> >+Below is the example of USB power sequence properties on USB device
> >+nodes which have two level USB hubs.
> >+
> >+&usbotg1 {
> >+	vbus-supply = <&reg_usb_otg1_vbus>;
> >+	pinctrl-names = "default";
> >+	pinctrl-0 = <&pinctrl_usb_otg1_id>;
> >+	status = "okay";
> >+
> >+	#address-cells = <1>;
> >+	#size-cells = <0>;
> >+	genesys: hub@1 {
> >+		compatible = "usb5e3,608";
> >+		reg = <1>;
> >+
> >+		clocks = <&clks IMX6SX_CLK_CKO>;
> >+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> >+		reset-duration-us = <10>;
> >+
> >+		#address-cells = <1>;
> >+		#size-cells = <0>;
> >+		asix: ethernet@1 {
> >+			compatible = "usbb95,1708";
> 
> So I assume, with our recent discussion and the change
> we are proposing, the library would have some knowledge
> about this compatible string, right?

Yes

> 
> what I was asking on other email was, how are you connecting
> multiple power sequence libraries to their respective consumers ?
> 

The consumers has its of_node, then it can find related power sequence
library according to compatible string.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Add binding doc for generic power sequence library.
> >
> >Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
> >Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >---
> >  .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >
> >diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >new file mode 100644
> >index 0000000..ebf0d47
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >@@ -0,0 +1,48 @@
> >+The generic power sequence library
> >+
> >+Some hard-wired devices (eg USB/MMC) need to do power sequence before
> >+the device can be enumerated on the bus, the typical power sequence
> >+like: enable USB PHY clock, toggle reset pin, etc. But current
> >+Linux device driver lacks of such code to do it, it may cause some
> >+hard-wired devices works abnormal or can't be recognized by
> >+controller at all. The power sequence will be done before this device
> >+can be found at the bus.
> >+
> >+The power sequence properties is under the device node.
> >+
> >+Optional properties:
> >+- clocks: the input clocks for device.
> >+- reset-gpios: Should specify the GPIO for reset.
> >+- reset-duration-us: the duration in microsecond for assert reset signal.
> >+
> >+Below is the example of USB power sequence properties on USB device
> >+nodes which have two level USB hubs.
> >+
> >+&usbotg1 {
> >+	vbus-supply = <&reg_usb_otg1_vbus>;
> >+	pinctrl-names = "default";
> >+	pinctrl-0 = <&pinctrl_usb_otg1_id>;
> >+	status = "okay";
> >+
> >+	#address-cells = <1>;
> >+	#size-cells = <0>;
> >+	genesys: hub@1 {
> >+		compatible = "usb5e3,608";
> >+		reg = <1>;
> >+
> >+		clocks = <&clks IMX6SX_CLK_CKO>;
> >+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> >+		reset-duration-us = <10>;
> >+
> >+		#address-cells = <1>;
> >+		#size-cells = <0>;
> >+		asix: ethernet@1 {
> >+			compatible = "usbb95,1708";
> 
> So I assume, with our recent discussion and the change
> we are proposing, the library would have some knowledge
> about this compatible string, right?

Yes

> 
> what I was asking on other email was, how are you connecting
> multiple power sequence libraries to their respective consumers ?
> 

The consumers has its of_node, then it can find related power sequence
library according to compatible string.

-- 

Best Regards,
Peter Chen
--
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 v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Add binding doc for generic power sequence library.
> >
> >Signed-off-by: Peter Chen <peter.chen@nxp.com>
> >Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> >Acked-by: Rob Herring <robh@kernel.org>
> >---
> >  .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >
> >diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >new file mode 100644
> >index 0000000..ebf0d47
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> >@@ -0,0 +1,48 @@
> >+The generic power sequence library
> >+
> >+Some hard-wired devices (eg USB/MMC) need to do power sequence before
> >+the device can be enumerated on the bus, the typical power sequence
> >+like: enable USB PHY clock, toggle reset pin, etc. But current
> >+Linux device driver lacks of such code to do it, it may cause some
> >+hard-wired devices works abnormal or can't be recognized by
> >+controller at all. The power sequence will be done before this device
> >+can be found at the bus.
> >+
> >+The power sequence properties is under the device node.
> >+
> >+Optional properties:
> >+- clocks: the input clocks for device.
> >+- reset-gpios: Should specify the GPIO for reset.
> >+- reset-duration-us: the duration in microsecond for assert reset signal.
> >+
> >+Below is the example of USB power sequence properties on USB device
> >+nodes which have two level USB hubs.
> >+
> >+&usbotg1 {
> >+	vbus-supply = <&reg_usb_otg1_vbus>;
> >+	pinctrl-names = "default";
> >+	pinctrl-0 = <&pinctrl_usb_otg1_id>;
> >+	status = "okay";
> >+
> >+	#address-cells = <1>;
> >+	#size-cells = <0>;
> >+	genesys: hub at 1 {
> >+		compatible = "usb5e3,608";
> >+		reg = <1>;
> >+
> >+		clocks = <&clks IMX6SX_CLK_CKO>;
> >+		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> >+		reset-duration-us = <10>;
> >+
> >+		#address-cells = <1>;
> >+		#size-cells = <0>;
> >+		asix: ethernet at 1 {
> >+			compatible = "usbb95,1708";
> 
> So I assume, with our recent discussion and the change
> we are proposing, the library would have some knowledge
> about this compatible string, right?

Yes

> 
> what I was asking on other email was, how are you connecting
> multiple power sequence libraries to their respective consumers ?
> 

The consumers has its of_node, then it can find related power sequence
library according to compatible string.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
> >On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
> >>
> >>On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> >>>On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> >>>>On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> >>>>>On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >>>>>>Hi all,
> >>>>>>
> >>>>>>This is a follow-up for my last power sequence framework patch set [1].
> >>>>>>According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >>>>>>power sequence library for parsing the power sequence elements on DT,
> >>>>>>and implement generic power sequence on library. The host driver
> >>>>>>can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >>>>>>
> >>>>>>In future, if there are special power sequence requirements, the special
> >>>>>>power sequence library can be created.
> >>>>>>
> >>>>>>This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >>>>>>two hot-plug devices to simulate this use case, the related binding
> >>>>>>change is updated at patch [1/6], The udoo board changes were tested
> >>>>>>using my last power sequence patch set.[3]
> >>>>>>
> >>>>>>Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >>>>>>need to power on itself before it can be found by ULPI bus.
> >>>>>>
> >>>>>>[1]http://www.spinics.net/lists/linux-usb/msg142755.html
> >>>>>>[2]http://www.spinics.net/lists/linux-usb/msg143106.html
> >>>>>>[3]http://www.spinics.net/lists/linux-usb/msg142815.html
> >>>>>(Please ignore my response on V2)
> >>>>>
> >>>>>Sorry being so late in the discussion...
> >>>>>
> >>>>>If I am not missing anything, then I am afraid to say that the
> >>>>>generic library
> >>>>>implementation in this patch series is not going to solve many of
> >>>>>the custom
> >>>>>requirement of power on, off, etc...
> >>>>>I know you mentioned about adding another library when we come
> >>>>>across such platforms, but should we not keep provision (or easy
> >>>>>hooks/path)
> >>>>>to enable that ?
> >>>>>
> >>>>>Let me bring in the use case I am dealing with,
> >>>>>
> >>>>>
> >>>>>                               Host
> >>>>>                                |
> >>>>>                                V
> >>>>>                            USB port
> >>>>>------------------------------------------------------------
> >>>>>                                |
> >>>>>                                V
> >>>>>                       USB HUB device (May need custom on/off seq)
> >>>>>                                |
> >>>>>                                V
> >>>>>               =============================
> >>>>>              |                             |
> >>>>>              V                             V
> >>>>>          Device-1                       Device-2
> >>>>>(Needs special power               (Needs special power
> >>>>>  on/off sequence.                   on/off sequence.
> >>>>>  Also may need custom               Also, may need custom
> >>>>>  sequence for                       sequence for
> >>>>>  suspend/resume)                    suspend/resume)
> >>>>>
> >>>>>
> >>>>>Note: Both Devices are connected to HUB via HSIC and may differ
> >>>>>           in terms of functionality, features they support.
> >>>>>
> >>>>>In the above case, both Device-1 and Device-2, need separate
> >>>>>power on/off sequence. So generic library currently we have in this
> >>>>>patch series is not going to satisfy the need here.
> >>>>>
> >>>>>I looked at all 6 revisions of this patch-series, went through the
> >>>>>review comments, and looked at MMC power sequence code;
> >>>>>what I can say here is, we need something similar to
> >>>>>MMC power sequence here, where every device can have its own
> >>>>>power sequence (if needed).
> >>>>>
> >>>>>I know Rob is not in favor of creating platform device for
> >>>>>this, and I understand his comment.
> >>>>>If not platform device, but atleast we need mechanism to
> >>>>>connect each device back to its of_node and its respective
> >>>>>driver/library fns. For example, the Devices may support different
> >>>>>boot modes, and platform driver needs to make sure that
> >>>>>the right sequence is followed for booting.
> >>>>>
> >>>>>Peter, My apologies for taking you back again on this series.
> >>>>>I am OK, if you wish to address this in incremental addition,
> >>>>>but my point is, we know that the current generic way is not
> >>>>>enough for us, so I think we should try to fix it in initial phase only.
> >>>>>
> >>>>Rob, it seems generic power sequence can't cover all cases.
> >>>>Without information from DT, we can't know which power sequence
> >>>>for which device.
> >>>>
> >>>Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> >>>for each library, and choose pwrseq library according to compatible
> >>>string first, if there is no compatible string for this library, just
> >>>use generic pwrseq library.
> >>>
> >>Lets hear from MMC folks. Ulf, do you agree on approach
> >>for pwr seq ??
> >>
> >>
> >>With above approach, I kind of agree on it, but I have couple
> >>of comments,
> >>
> >>  - How DTS looks like now ?? Can you put example here ?
> >The dts is the same with current version.
> 
> How would consumer driver get the power sequence ?
> You must point to right power sequence driver.
> For example, in the above example, Device-1, should
> get handle to pwrseq-1, and Device-2 to pwrseq-2.

According to compatible string at device's of_node, we will have a list
for power sequence libraries which has index (or name), and matches
compatible string.

> 
> >>  - Should we merge MMC power sequence in next series ?
> >>    We also can take this as an incremental change, to avoid further
> >>    delay :)
> >We had an agreement that keep mmc's pwrseq framework unchanging.
> >Unless Ulf and rob both agree to change.
> 
> Why 2 separate approach for same problem ?
> And I see this as possible duplication of code/functionality :)

How the new kernel compatibles old dts? If we do not need to
consider this problem, the mmc can try to use power sequence library
too in future.

> 
> >>  - Lets also add suspend/resume callback to struct pwrseq
> >>
> >Why suspend/resume can't do at related driver's suspend/resume API?
> 
> Nope...
> The pwrseq library would have taken ownership of resources, so
> related driver cannot suspend the device. Again it is architecture
> specific, but we should have provision to handle this.
> 
> The system I am dealing with today, does need suspend/resume
> callback. To be precise, suspend is close to off state for some devices or
> they could enter standby or different low power state, but to do that,
> we need same resource as used for ON/OFF functionality.
> 

Ok, I will have API for suspend/resume. You can implement it at your own
library or generic one.

-- 

Best Regards,
Peter Chen

[PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
> >On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
> >>
> >>On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> >>>On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> >>>>On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> >>>>>On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >>>>>>Hi all,
> >>>>>>
> >>>>>>This is a follow-up for my last power sequence framework patch set [1].
> >>>>>>According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >>>>>>power sequence library for parsing the power sequence elements on DT,
> >>>>>>and implement generic power sequence on library. The host driver
> >>>>>>can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >>>>>>
> >>>>>>In future, if there are special power sequence requirements, the special
> >>>>>>power sequence library can be created.
> >>>>>>
> >>>>>>This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >>>>>>two hot-plug devices to simulate this use case, the related binding
> >>>>>>change is updated at patch [1/6], The udoo board changes were tested
> >>>>>>using my last power sequence patch set.[3]
> >>>>>>
> >>>>>>Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >>>>>>need to power on itself before it can be found by ULPI bus.
> >>>>>>
> >>>>>>[1]http://www.spinics.net/lists/linux-usb/msg142755.html
> >>>>>>[2]http://www.spinics.net/lists/linux-usb/msg143106.html
> >>>>>>[3]http://www.spinics.net/lists/linux-usb/msg142815.html
> >>>>>(Please ignore my response on V2)
> >>>>>
> >>>>>Sorry being so late in the discussion...
> >>>>>
> >>>>>If I am not missing anything, then I am afraid to say that the
> >>>>>generic library
> >>>>>implementation in this patch series is not going to solve many of
> >>>>>the custom
> >>>>>requirement of power on, off, etc...
> >>>>>I know you mentioned about adding another library when we come
> >>>>>across such platforms, but should we not keep provision (or easy
> >>>>>hooks/path)
> >>>>>to enable that ?
> >>>>>
> >>>>>Let me bring in the use case I am dealing with,
> >>>>>
> >>>>>
> >>>>>                               Host
> >>>>>                                |
> >>>>>                                V
> >>>>>                            USB port
> >>>>>------------------------------------------------------------
> >>>>>                                |
> >>>>>                                V
> >>>>>                       USB HUB device (May need custom on/off seq)
> >>>>>                                |
> >>>>>                                V
> >>>>>               =============================
> >>>>>              |                             |
> >>>>>              V                             V
> >>>>>          Device-1                       Device-2
> >>>>>(Needs special power               (Needs special power
> >>>>>  on/off sequence.                   on/off sequence.
> >>>>>  Also may need custom               Also, may need custom
> >>>>>  sequence for                       sequence for
> >>>>>  suspend/resume)                    suspend/resume)
> >>>>>
> >>>>>
> >>>>>Note: Both Devices are connected to HUB via HSIC and may differ
> >>>>>           in terms of functionality, features they support.
> >>>>>
> >>>>>In the above case, both Device-1 and Device-2, need separate
> >>>>>power on/off sequence. So generic library currently we have in this
> >>>>>patch series is not going to satisfy the need here.
> >>>>>
> >>>>>I looked at all 6 revisions of this patch-series, went through the
> >>>>>review comments, and looked at MMC power sequence code;
> >>>>>what I can say here is, we need something similar to
> >>>>>MMC power sequence here, where every device can have its own
> >>>>>power sequence (if needed).
> >>>>>
> >>>>>I know Rob is not in favor of creating platform device for
> >>>>>this, and I understand his comment.
> >>>>>If not platform device, but atleast we need mechanism to
> >>>>>connect each device back to its of_node and its respective
> >>>>>driver/library fns. For example, the Devices may support different
> >>>>>boot modes, and platform driver needs to make sure that
> >>>>>the right sequence is followed for booting.
> >>>>>
> >>>>>Peter, My apologies for taking you back again on this series.
> >>>>>I am OK, if you wish to address this in incremental addition,
> >>>>>but my point is, we know that the current generic way is not
> >>>>>enough for us, so I think we should try to fix it in initial phase only.
> >>>>>
> >>>>Rob, it seems generic power sequence can't cover all cases.
> >>>>Without information from DT, we can't know which power sequence
> >>>>for which device.
> >>>>
> >>>Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> >>>for each library, and choose pwrseq library according to compatible
> >>>string first, if there is no compatible string for this library, just
> >>>use generic pwrseq library.
> >>>
> >>Lets hear from MMC folks. Ulf, do you agree on approach
> >>for pwr seq ??
> >>
> >>
> >>With above approach, I kind of agree on it, but I have couple
> >>of comments,
> >>
> >>  - How DTS looks like now ?? Can you put example here ?
> >The dts is the same with current version.
> 
> How would consumer driver get the power sequence ?
> You must point to right power sequence driver.
> For example, in the above example, Device-1, should
> get handle to pwrseq-1, and Device-2 to pwrseq-2.

According to compatible string at device's of_node, we will have a list
for power sequence libraries which has index (or name), and matches
compatible string.

> 
> >>  - Should we merge MMC power sequence in next series ?
> >>    We also can take this as an incremental change, to avoid further
> >>    delay :)
> >We had an agreement that keep mmc's pwrseq framework unchanging.
> >Unless Ulf and rob both agree to change.
> 
> Why 2 separate approach for same problem ?
> And I see this as possible duplication of code/functionality :)

How the new kernel compatibles old dts? If we do not need to
consider this problem, the mmc can try to use power sequence library
too in future.

> 
> >>  - Lets also add suspend/resume callback to struct pwrseq
> >>
> >Why suspend/resume can't do at related driver's suspend/resume API?
> 
> Nope...
> The pwrseq library would have taken ownership of resources, so
> related driver cannot suspend the device. Again it is architecture
> specific, but we should have provision to handle this.
> 
> The system I am dealing with today, does need suspend/resume
> callback. To be precise, suspend is close to off state for some devices or
> they could enter standby or different low power state, but to do that,
> we need same resource as used for ON/OFF functionality.
> 

Ok, I will have API for suspend/resume. You can implement it at your own
library or generic one.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 2/8] power: add power sequence library

[Peter Chen]

On Thu, Sep 01, 2016 at 01:32:56PM +0530, Vaibhav Hiremath wrote:
> >+static void pwrseq_generic_put(struct pwrseq *pwrseq)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	int clk;
> >+
> >+	if (pwrseq_gen->gpiod_reset)
> >+		gpiod_put(pwrseq_gen->gpiod_reset);
> >+
> >+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
> >+		clk_put(pwrseq_gen->clks[clk]);
> >+}
> >+
> >+static void pwrseq_generic_off(struct pwrseq *pwrseq)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	int clk;
> >+
> >+	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
> >+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> >+}
> >+
> >+static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
> Ideally you shouldn't need device_node here at this stage.
> I expect to extract all the resource information in _get() itself.
> 

Agree, I will move reset-duration-us property handling to pwrseq_get.

> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	int clk, ret = 0;
> >+	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
> >+
> >+	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
> >+		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
> >+		if (ret) {
> >+			pr_err("Can't enable clock on %s: %d\n",
> >+				np->full_name, ret);
> >+			goto err_disable_clks;
> >+		}
> >+	}
> >+
> >+	if (gpiod_reset) {
> >+		u32 duration_us = 50;
> Why initialize to 50 ??
> 

This active duration is default value, and should work for most of
devices. If your device needs longer, you can change it at dts.

> >+
> >+		of_property_read_u32(np, "reset-duration-us",
> >+				&duration_us);
> >+		if (duration_us <= 10)
> >+			udelay(10);
> >+		else
> >+			usleep_range(duration_us, duration_us + 100);
> >+		gpiod_set_value(gpiod_reset, 0);
> >+	}
> >+
> >+	return ret;
> >+
> >+err_disable_clks:
> >+	while (--clk >= 0)
> >+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> >+
> >+	return ret;
> >+}
> >+
> >+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	enum of_gpio_flags flags;
> >+	int reset_gpio, clk, ret = 0;
> >+
> >+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> >+		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> >+		if (IS_ERR(pwrseq_gen->clks[clk])) {
> >+			ret = PTR_ERR(pwrseq_gen->clks[clk]);
> >+			if (ret == -EPROBE_DEFER)
> >+				goto err_put_clks;
> >+			pwrseq_gen->clks[clk] = NULL;
> >+			break;
> 
> Do we really want to continue here, even we failed to get the clock ?

Ok, if it is -ENOENT, I set clk as NULL, for other error cases, I go to
error path.

> 
> >+		}
> >+	}
> >+
> >+	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> >+	if (gpio_is_valid(reset_gpio)) {
> >+		unsigned long gpio_flags;
> >+
> >+		if (flags & OF_GPIO_ACTIVE_LOW)
> >+			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> >+		else
> >+			gpio_flags = GPIOF_OUT_INIT_HIGH;
> >+
> >+		ret = gpio_request_one(reset_gpio, gpio_flags,
> >+				"pwrseq-reset-gpios");
> >+		if (ret)
> >+			goto err_put_clks;
> >+
> >+		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> >+	} else {
> >+		if (reset_gpio == -ENOENT)
> >+			return 0;
> 
> Why are we returning success here ?
> 

The property "reset-gpios" is optional, it can be nonexistent.

> >+
> >+		ret = reset_gpio;
> >+		pr_err("Failed to get reset gpio on %s, err = %d\n",
> >+				np->full_name, reset_gpio);
> >+		goto err_put_clks;
> >+	}
> >+
> >+	return ret;
> >+
> >+err_put_clks:
> >+	while (--clk >= 0)
> >+		clk_put(pwrseq_gen->clks[clk]);
> >+	return ret;
> >+}
> >+
> >+struct pwrseq *pwrseq_alloc_generic(void)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen;
> >+
> >+	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> >+	if (!pwrseq_gen)
> >+		return ERR_PTR(-ENOMEM);
> >+
> >+	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> >+	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> >+	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> >+	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> >+	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> >+
> >+	return &pwrseq_gen->pwrseq;
> >+}
> >+EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
> 
> With recent discussion on postcore_initcall, we probably can merge
> _get() and _alloc() fns.
> 

At postcore_initcall, I plan to allocate individual pwrseq library, and
add it to pwrseq list. The consumer tries to get the resources.

Peter

> Thanks,
> Vaibhav
> >diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
> >new file mode 100644
> >index 0000000..ebb2280
> >--- /dev/null
> >+++ b/include/linux/power/pwrseq.h
> >@@ -0,0 +1,47 @@
> >+#ifndef __LINUX_PWRSEQ_H
> >+#define __LINUX_PWRSEQ_H
> >+
> >+#include <linux/of.h>
> >+
> >+#define PWRSEQ_MAX_CLKS		3
> >+
> >+struct pwrseq {
> >+	char *name;
> >+	struct list_head node;
> >+	int (*get)(struct device_node *np, struct pwrseq *p);
> >+	int (*on)(struct device_node *np, struct pwrseq *p);
> >+	void (*off)(struct pwrseq *p);
> >+	void (*put)(struct pwrseq *p);
> >+	void (*free)(struct pwrseq *p);
> >+};
> >+
> >+#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
> >+int pwrseq_get(struct device_node *np, struct pwrseq *p);
> >+int pwrseq_on(struct device_node *np, struct pwrseq *p);
> >+void pwrseq_off(struct pwrseq *p);
> >+void pwrseq_put(struct pwrseq *p);
> >+void pwrseq_free(struct pwrseq *p);
> >+#else
> >+static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
> >+{
> >+	return 0;
> >+}
> >+static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
> >+{
> >+	return 0;
> >+}
> >+static inline void pwrseq_off(struct pwrseq *p) {}
> >+static inline void pwrseq_put(struct pwrseq *p) {}
> >+static inline void pwrseq_free(struct pwrseq *p) {}
> >+#endif /* CONFIG_POWER_SEQUENCE */
> >+
> >+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> >+struct pwrseq *pwrseq_alloc_generic(void);
> >+#else
> >+static inline struct pwrseq *pwrseq_alloc_generic(void)
> >+{
> >+	return NULL;
> >+}
> >+#endif /* CONFIG_PWRSEQ_GENERIC */
> >+
> >+#endif  /* __LINUX_PWRSEQ_H */
> 
> -- 
> Thanks,
> Vaibhav
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[PATCH v6 2/8] power: add power sequence library

[Peter Chen]

On Thu, Sep 01, 2016 at 01:32:56PM +0530, Vaibhav Hiremath wrote:
> >+static void pwrseq_generic_put(struct pwrseq *pwrseq)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	int clk;
> >+
> >+	if (pwrseq_gen->gpiod_reset)
> >+		gpiod_put(pwrseq_gen->gpiod_reset);
> >+
> >+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++)
> >+		clk_put(pwrseq_gen->clks[clk]);
> >+}
> >+
> >+static void pwrseq_generic_off(struct pwrseq *pwrseq)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	int clk;
> >+
> >+	for (clk = PWRSEQ_MAX_CLKS - 1; clk >= 0; clk--)
> >+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> >+}
> >+
> >+static int pwrseq_generic_on(struct device_node *np, struct pwrseq *pwrseq)
> Ideally you shouldn't need device_node here at this stage.
> I expect to extract all the resource information in _get() itself.
> 

Agree, I will move reset-duration-us property handling to pwrseq_get.

> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	int clk, ret = 0;
> >+	struct gpio_desc *gpiod_reset = pwrseq_gen->gpiod_reset;
> >+
> >+	for (clk = 0; clk < PWRSEQ_MAX_CLKS && pwrseq_gen->clks[clk]; clk++) {
> >+		ret = clk_prepare_enable(pwrseq_gen->clks[clk]);
> >+		if (ret) {
> >+			pr_err("Can't enable clock on %s: %d\n",
> >+				np->full_name, ret);
> >+			goto err_disable_clks;
> >+		}
> >+	}
> >+
> >+	if (gpiod_reset) {
> >+		u32 duration_us = 50;
> Why initialize to 50 ??
> 

This active duration is default value, and should work for most of
devices. If your device needs longer, you can change it at dts.

> >+
> >+		of_property_read_u32(np, "reset-duration-us",
> >+				&duration_us);
> >+		if (duration_us <= 10)
> >+			udelay(10);
> >+		else
> >+			usleep_range(duration_us, duration_us + 100);
> >+		gpiod_set_value(gpiod_reset, 0);
> >+	}
> >+
> >+	return ret;
> >+
> >+err_disable_clks:
> >+	while (--clk >= 0)
> >+		clk_disable_unprepare(pwrseq_gen->clks[clk]);
> >+
> >+	return ret;
> >+}
> >+
> >+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+	enum of_gpio_flags flags;
> >+	int reset_gpio, clk, ret = 0;
> >+
> >+	for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> >+		pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> >+		if (IS_ERR(pwrseq_gen->clks[clk])) {
> >+			ret = PTR_ERR(pwrseq_gen->clks[clk]);
> >+			if (ret == -EPROBE_DEFER)
> >+				goto err_put_clks;
> >+			pwrseq_gen->clks[clk] = NULL;
> >+			break;
> 
> Do we really want to continue here, even we failed to get the clock ?

Ok, if it is -ENOENT, I set clk as NULL, for other error cases, I go to
error path.

> 
> >+		}
> >+	}
> >+
> >+	reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> >+	if (gpio_is_valid(reset_gpio)) {
> >+		unsigned long gpio_flags;
> >+
> >+		if (flags & OF_GPIO_ACTIVE_LOW)
> >+			gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> >+		else
> >+			gpio_flags = GPIOF_OUT_INIT_HIGH;
> >+
> >+		ret = gpio_request_one(reset_gpio, gpio_flags,
> >+				"pwrseq-reset-gpios");
> >+		if (ret)
> >+			goto err_put_clks;
> >+
> >+		pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> >+	} else {
> >+		if (reset_gpio == -ENOENT)
> >+			return 0;
> 
> Why are we returning success here ?
> 

The property "reset-gpios" is optional, it can be nonexistent.

> >+
> >+		ret = reset_gpio;
> >+		pr_err("Failed to get reset gpio on %s, err = %d\n",
> >+				np->full_name, reset_gpio);
> >+		goto err_put_clks;
> >+	}
> >+
> >+	return ret;
> >+
> >+err_put_clks:
> >+	while (--clk >= 0)
> >+		clk_put(pwrseq_gen->clks[clk]);
> >+	return ret;
> >+}
> >+
> >+struct pwrseq *pwrseq_alloc_generic(void)
> >+{
> >+	struct pwrseq_generic *pwrseq_gen;
> >+
> >+	pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> >+	if (!pwrseq_gen)
> >+		return ERR_PTR(-ENOMEM);
> >+
> >+	pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> >+	pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> >+	pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> >+	pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> >+	pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> >+
> >+	return &pwrseq_gen->pwrseq;
> >+}
> >+EXPORT_SYMBOL_GPL(pwrseq_alloc_generic);
> 
> With recent discussion on postcore_initcall, we probably can merge
> _get() and _alloc() fns.
> 

At postcore_initcall, I plan to allocate individual pwrseq library, and
add it to pwrseq list. The consumer tries to get the resources.

Peter

> Thanks,
> Vaibhav
> >diff --git a/include/linux/power/pwrseq.h b/include/linux/power/pwrseq.h
> >new file mode 100644
> >index 0000000..ebb2280
> >--- /dev/null
> >+++ b/include/linux/power/pwrseq.h
> >@@ -0,0 +1,47 @@
> >+#ifndef __LINUX_PWRSEQ_H
> >+#define __LINUX_PWRSEQ_H
> >+
> >+#include <linux/of.h>
> >+
> >+#define PWRSEQ_MAX_CLKS		3
> >+
> >+struct pwrseq {
> >+	char *name;
> >+	struct list_head node;
> >+	int (*get)(struct device_node *np, struct pwrseq *p);
> >+	int (*on)(struct device_node *np, struct pwrseq *p);
> >+	void (*off)(struct pwrseq *p);
> >+	void (*put)(struct pwrseq *p);
> >+	void (*free)(struct pwrseq *p);
> >+};
> >+
> >+#if IS_ENABLED(CONFIG_POWER_SEQUENCE)
> >+int pwrseq_get(struct device_node *np, struct pwrseq *p);
> >+int pwrseq_on(struct device_node *np, struct pwrseq *p);
> >+void pwrseq_off(struct pwrseq *p);
> >+void pwrseq_put(struct pwrseq *p);
> >+void pwrseq_free(struct pwrseq *p);
> >+#else
> >+static inline int pwrseq_get(struct device_node *np, struct pwrseq *p)
> >+{
> >+	return 0;
> >+}
> >+static inline int pwrseq_on(struct device_node *np, struct pwrseq *p)
> >+{
> >+	return 0;
> >+}
> >+static inline void pwrseq_off(struct pwrseq *p) {}
> >+static inline void pwrseq_put(struct pwrseq *p) {}
> >+static inline void pwrseq_free(struct pwrseq *p) {}
> >+#endif /* CONFIG_POWER_SEQUENCE */
> >+
> >+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> >+struct pwrseq *pwrseq_alloc_generic(void);
> >+#else
> >+static inline struct pwrseq *pwrseq_alloc_generic(void)
> >+{
> >+	return NULL;
> >+}
> >+#endif /* CONFIG_PWRSEQ_GENERIC */
> >+
> >+#endif  /* __LINUX_PWRSEQ_H */
> 
> -- 
> Thanks,
> Vaibhav
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

On Thu, Sep 01, 2016 at 01:32:49PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Some hard-wired USB devices need to do power sequence to let the
> >device work normally, the typical power sequence like: enable USB
> >PHY clock, toggle reset pin, etc. But current Linux USB driver
> >lacks of such code to do it, it may cause some hard-wired USB devices
> >works abnormal or can't be recognized by controller at all.
> >
> >In this patch, it calls power sequence library APIs to finish
> >the power sequence events. At first, it calls pwrseq_alloc_generic
> >to create a generic power sequence instance, then it will do power
> >on sequence at hub's probe for all devices under this hub
> >(includes root hub).
> >
> >At hub_disconnect, it will do power off sequence which is at powered
> >on list.
> >
> >Signed-off-by: Peter Chen <peter.chen@nxp.com>
> >Tested-by Joshua Clayton <stillcompiling@gmail.com>
> >---
> >  drivers/usb/core/Makefile |   1 +
> >  drivers/usb/core/hub.c    |  12 ++++--
> >  drivers/usb/core/hub.h    |  12 ++++++
> >  drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 122 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/usb/core/pwrseq.c
> >
> >diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> >index 9780877..39f2149 100644
> >--- a/drivers/usb/core/Makefile
> >+++ b/drivers/usb/core/Makefile
> >@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
> >  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
> >  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> >+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
> >  obj-$(CONFIG_USB)		+= usbcore.o
> >diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> >index bee1351..a346a8b 100644
> >--- a/drivers/usb/core/hub.c
> >+++ b/drivers/usb/core/hub.c
> >@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
> >  	hub->error = 0;
> >  	hub_quiesce(hub, HUB_DISCONNECT);
> >+	hub_pwrseq_off(hub);
> >  	mutex_lock(&usb_port_peer_mutex);
> >  	/* Avoid races with recursively_mark_NOTATTACHED() */
> >@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
> >  	struct usb_endpoint_descriptor *endpoint;
> >  	struct usb_device *hdev;
> >  	struct usb_hub *hub;
> >+	int ret = -ENODEV;
> >  	desc = intf->cur_altsetting;
> >  	hdev = interface_to_usbdev(intf);
> >@@ -1839,6 +1841,7 @@ descriptor_error:
> >  	INIT_DELAYED_WORK(&hub->leds, led_work);
> >  	INIT_DELAYED_WORK(&hub->init_work, NULL);
> >  	INIT_WORK(&hub->events, hub_event);
> >+	INIT_LIST_HEAD(&hub->pwrseq_on_list);
> >  	usb_get_intf(intf);
> >  	usb_get_dev(hdev);
> >@@ -1852,11 +1855,14 @@ descriptor_error:
> >  	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
> >  		hub->quirk_check_port_auto_suspend = 1;
> >-	if (hub_configure(hub, endpoint) >= 0)
> >-		return 0;
> >+	if (hub_configure(hub, endpoint) >= 0) {
> >+		ret = hub_pwrseq_on(hub);
> >+		if (!ret)
> >+			return 0;
> >+	}
> >  	hub_disconnect(intf);
> >-	return -ENODEV;
> >+	return ret;
> >  }
> >  static int
> >diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> >index 34c1a7e..9473f6f 100644
> >--- a/drivers/usb/core/hub.h
> >+++ b/drivers/usb/core/hub.h
> >@@ -78,6 +78,7 @@ struct usb_hub {
> >  	struct delayed_work	init_work;
> >  	struct work_struct      events;
> >  	struct usb_port		**ports;
> >+	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
> >  };
> >  /**
> >@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
> >  {
> >  	return hub_port_debounce(hub, port1, false);
> >  }
> >+
> >+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> >+int hub_pwrseq_on(struct usb_hub *hub);
> >+void hub_pwrseq_off(struct usb_hub *hub);
> >+#else
> >+static inline int hub_pwrseq_on(struct usb_hub *hub)
> >+{
> >+	return 0;
> >+}
> >+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
> >+#endif /* CONFIG_PWRSEQ_GENERIC */
> >diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
> >new file mode 100644
> >index 0000000..837fe66
> >--- /dev/null
> >+++ b/drivers/usb/core/pwrseq.c
> >@@ -0,0 +1,100 @@
> >+/*
> >+ * pwrseq.c	USB device power sequence management
> >+ *
> >+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
> >+ * Author: Peter Chen <peter.chen@nxp.com>
> >+ *
> >+ * This program is free software: you can redistribute it and/or modify
> >+ * it under the terms of the GNU General Public License version 2  of
> >+ * the License as published by the Free Software Foundation.
> >+ *
> >+ * 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.
> >+ *
> >+ * You should have received a copy of the GNU General Public License
> >+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >+ */
> >+
> >+#include <linux/list.h>
> >+#include <linux/of.h>
> >+#include <linux/power/pwrseq.h>
> >+#include <linux/slab.h>
> >+#include <linux/usb.h>
> >+#include <linux/usb/hcd.h>
> >+
> >+#include "hub.h"
> >+
> >+struct usb_pwrseq_node {
> >+	struct pwrseq *pwrseq;
> >+	struct list_head list;
> >+};
> >+
> >+static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> >+{
> >+	struct pwrseq *pwrseq;
> >+	struct usb_pwrseq_node *pwrseq_node;
> >+	int ret;
> >+
> >+	pwrseq = pwrseq_alloc_generic();
> >+	if (IS_ERR(pwrseq))
> >+		return PTR_ERR(pwrseq);
> >+
> >+	ret = pwrseq_get(np, pwrseq);
> >+	if (ret)
> >+		goto pwr_free;
> >+
> >+	ret = pwrseq_on(np, pwrseq);
> >+	if (ret)
> >+		goto pwr_put;
> >+
> >+	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
> 
> You probably want to check the return value here.
> 
> I think someone already commented on this, but still for the record
> providing it.
> 

Thanks, I will.

-- 

Best Regards,
Peter Chen

[PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

On Thu, Sep 01, 2016 at 01:32:49PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Some hard-wired USB devices need to do power sequence to let the
> >device work normally, the typical power sequence like: enable USB
> >PHY clock, toggle reset pin, etc. But current Linux USB driver
> >lacks of such code to do it, it may cause some hard-wired USB devices
> >works abnormal or can't be recognized by controller at all.
> >
> >In this patch, it calls power sequence library APIs to finish
> >the power sequence events. At first, it calls pwrseq_alloc_generic
> >to create a generic power sequence instance, then it will do power
> >on sequence at hub's probe for all devices under this hub
> >(includes root hub).
> >
> >At hub_disconnect, it will do power off sequence which is at powered
> >on list.
> >
> >Signed-off-by: Peter Chen <peter.chen@nxp.com>
> >Tested-by Joshua Clayton <stillcompiling@gmail.com>
> >---
> >  drivers/usb/core/Makefile |   1 +
> >  drivers/usb/core/hub.c    |  12 ++++--
> >  drivers/usb/core/hub.h    |  12 ++++++
> >  drivers/usb/core/pwrseq.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 122 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/usb/core/pwrseq.c
> >
> >diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> >index 9780877..39f2149 100644
> >--- a/drivers/usb/core/Makefile
> >+++ b/drivers/usb/core/Makefile
> >@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
> >  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
> >  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> >+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
> >  obj-$(CONFIG_USB)		+= usbcore.o
> >diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> >index bee1351..a346a8b 100644
> >--- a/drivers/usb/core/hub.c
> >+++ b/drivers/usb/core/hub.c
> >@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
> >  	hub->error = 0;
> >  	hub_quiesce(hub, HUB_DISCONNECT);
> >+	hub_pwrseq_off(hub);
> >  	mutex_lock(&usb_port_peer_mutex);
> >  	/* Avoid races with recursively_mark_NOTATTACHED() */
> >@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
> >  	struct usb_endpoint_descriptor *endpoint;
> >  	struct usb_device *hdev;
> >  	struct usb_hub *hub;
> >+	int ret = -ENODEV;
> >  	desc = intf->cur_altsetting;
> >  	hdev = interface_to_usbdev(intf);
> >@@ -1839,6 +1841,7 @@ descriptor_error:
> >  	INIT_DELAYED_WORK(&hub->leds, led_work);
> >  	INIT_DELAYED_WORK(&hub->init_work, NULL);
> >  	INIT_WORK(&hub->events, hub_event);
> >+	INIT_LIST_HEAD(&hub->pwrseq_on_list);
> >  	usb_get_intf(intf);
> >  	usb_get_dev(hdev);
> >@@ -1852,11 +1855,14 @@ descriptor_error:
> >  	if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
> >  		hub->quirk_check_port_auto_suspend = 1;
> >-	if (hub_configure(hub, endpoint) >= 0)
> >-		return 0;
> >+	if (hub_configure(hub, endpoint) >= 0) {
> >+		ret = hub_pwrseq_on(hub);
> >+		if (!ret)
> >+			return 0;
> >+	}
> >  	hub_disconnect(intf);
> >-	return -ENODEV;
> >+	return ret;
> >  }
> >  static int
> >diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> >index 34c1a7e..9473f6f 100644
> >--- a/drivers/usb/core/hub.h
> >+++ b/drivers/usb/core/hub.h
> >@@ -78,6 +78,7 @@ struct usb_hub {
> >  	struct delayed_work	init_work;
> >  	struct work_struct      events;
> >  	struct usb_port		**ports;
> >+	struct list_head	pwrseq_on_list; /* powered pwrseq node list */
> >  };
> >  /**
> >@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct usb_hub *hub,
> >  {
> >  	return hub_port_debounce(hub, port1, false);
> >  }
> >+
> >+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> >+int hub_pwrseq_on(struct usb_hub *hub);
> >+void hub_pwrseq_off(struct usb_hub *hub);
> >+#else
> >+static inline int hub_pwrseq_on(struct usb_hub *hub)
> >+{
> >+	return 0;
> >+}
> >+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
> >+#endif /* CONFIG_PWRSEQ_GENERIC */
> >diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
> >new file mode 100644
> >index 0000000..837fe66
> >--- /dev/null
> >+++ b/drivers/usb/core/pwrseq.c
> >@@ -0,0 +1,100 @@
> >+/*
> >+ * pwrseq.c	USB device power sequence management
> >+ *
> >+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
> >+ * Author: Peter Chen <peter.chen@nxp.com>
> >+ *
> >+ * This program is free software: you can redistribute it and/or modify
> >+ * it under the terms of the GNU General Public License version 2  of
> >+ * the License as published by the Free Software Foundation.
> >+ *
> >+ * 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.
> >+ *
> >+ * You should have received a copy of the GNU General Public License
> >+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >+ */
> >+
> >+#include <linux/list.h>
> >+#include <linux/of.h>
> >+#include <linux/power/pwrseq.h>
> >+#include <linux/slab.h>
> >+#include <linux/usb.h>
> >+#include <linux/usb/hcd.h>
> >+
> >+#include "hub.h"
> >+
> >+struct usb_pwrseq_node {
> >+	struct pwrseq *pwrseq;
> >+	struct list_head list;
> >+};
> >+
> >+static int hub_of_pwrseq_on(struct device_node *np, struct usb_hub *hub)
> >+{
> >+	struct pwrseq *pwrseq;
> >+	struct usb_pwrseq_node *pwrseq_node;
> >+	int ret;
> >+
> >+	pwrseq = pwrseq_alloc_generic();
> >+	if (IS_ERR(pwrseq))
> >+		return PTR_ERR(pwrseq);
> >+
> >+	ret = pwrseq_get(np, pwrseq);
> >+	if (ret)
> >+		goto pwr_free;
> >+
> >+	ret = pwrseq_on(np, pwrseq);
> >+	if (ret)
> >+		goto pwr_put;
> >+
> >+	pwrseq_node = kzalloc(sizeof(*pwrseq_node), GFP_KERNEL);
> 
> You probably want to check the return value here.
> 
> I think someone already commented on this, but still for the record
> providing it.
> 

Thanks, I will.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Friday 02 September 2016 06:30 AM, Peter Chen wrote:
> On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:
>>
>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>> Add binding doc for generic power sequence library.
>>>
>>> Signed-off-by: Peter Chen <peter.chen@nxp.com>
>>> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>>   .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
>>>   1 file changed, 48 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> new file mode 100644
>>> index 0000000..ebf0d47
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> @@ -0,0 +1,48 @@
>>> +The generic power sequence library
>>> +
>>> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
>>> +the device can be enumerated on the bus, the typical power sequence
>>> +like: enable USB PHY clock, toggle reset pin, etc. But current
>>> +Linux device driver lacks of such code to do it, it may cause some
>>> +hard-wired devices works abnormal or can't be recognized by
>>> +controller at all. The power sequence will be done before this device
>>> +can be found at the bus.
>>> +
>>> +The power sequence properties is under the device node.
>>> +
>>> +Optional properties:
>>> +- clocks: the input clocks for device.
>>> +- reset-gpios: Should specify the GPIO for reset.
>>> +- reset-duration-us: the duration in microsecond for assert reset signal.
>>> +
>>> +Below is the example of USB power sequence properties on USB device
>>> +nodes which have two level USB hubs.
>>> +
>>> +&usbotg1 {
>>> +	vbus-supply = <&reg_usb_otg1_vbus>;
>>> +	pinctrl-names = "default";
>>> +	pinctrl-0 = <&pinctrl_usb_otg1_id>;
>>> +	status = "okay";
>>> +
>>> +	#address-cells = <1>;
>>> +	#size-cells = <0>;
>>> +	genesys: hub@1 {
>>> +		compatible = "usb5e3,608";
>>> +		reg = <1>;
>>> +
>>> +		clocks = <&clks IMX6SX_CLK_CKO>;
>>> +		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
>>> +		reset-duration-us = <10>;
>>> +
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +		asix: ethernet@1 {
>>> +			compatible = "usbb95,1708";
>> So I assume, with our recent discussion and the change
>> we are proposing, the library would have some knowledge
>> about this compatible string, right?
> Yes
>
>> what I was asking on other email was, how are you connecting
>> multiple power sequence libraries to their respective consumers ?
>>
> The consumers has its of_node, then it can find related power sequence
> library according to compatible string.
>

Exactly. Thats what I was referring and wanted to confirm.

Thanks,
Vaibhav


-- 
Thanks,
Vaibhav

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Friday 02 September 2016 06:30 AM, Peter Chen wrote:
> On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:
>>
>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>> Add binding doc for generic power sequence library.
>>>
>>> Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
>>> Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> ---
>>>   .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
>>>   1 file changed, 48 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> new file mode 100644
>>> index 0000000..ebf0d47
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> @@ -0,0 +1,48 @@
>>> +The generic power sequence library
>>> +
>>> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
>>> +the device can be enumerated on the bus, the typical power sequence
>>> +like: enable USB PHY clock, toggle reset pin, etc. But current
>>> +Linux device driver lacks of such code to do it, it may cause some
>>> +hard-wired devices works abnormal or can't be recognized by
>>> +controller at all. The power sequence will be done before this device
>>> +can be found at the bus.
>>> +
>>> +The power sequence properties is under the device node.
>>> +
>>> +Optional properties:
>>> +- clocks: the input clocks for device.
>>> +- reset-gpios: Should specify the GPIO for reset.
>>> +- reset-duration-us: the duration in microsecond for assert reset signal.
>>> +
>>> +Below is the example of USB power sequence properties on USB device
>>> +nodes which have two level USB hubs.
>>> +
>>> +&usbotg1 {
>>> +	vbus-supply = <&reg_usb_otg1_vbus>;
>>> +	pinctrl-names = "default";
>>> +	pinctrl-0 = <&pinctrl_usb_otg1_id>;
>>> +	status = "okay";
>>> +
>>> +	#address-cells = <1>;
>>> +	#size-cells = <0>;
>>> +	genesys: hub@1 {
>>> +		compatible = "usb5e3,608";
>>> +		reg = <1>;
>>> +
>>> +		clocks = <&clks IMX6SX_CLK_CKO>;
>>> +		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
>>> +		reset-duration-us = <10>;
>>> +
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +		asix: ethernet@1 {
>>> +			compatible = "usbb95,1708";
>> So I assume, with our recent discussion and the change
>> we are proposing, the library would have some knowledge
>> about this compatible string, right?
> Yes
>
>> what I was asking on other email was, how are you connecting
>> multiple power sequence libraries to their respective consumers ?
>>
> The consumers has its of_node, then it can find related power sequence
> library according to compatible string.
>

Exactly. Thats what I was referring and wanted to confirm.

Thanks,
Vaibhav


-- 
Thanks,
Vaibhav

--
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 v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Friday 02 September 2016 06:30 AM, Peter Chen wrote:
> On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:
>>
>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>> Add binding doc for generic power sequence library.
>>>
>>> Signed-off-by: Peter Chen <peter.chen@nxp.com>
>>> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>>   .../bindings/power/pwrseq/pwrseq-generic.txt       | 48 ++++++++++++++++++++++
>>>   1 file changed, 48 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> new file mode 100644
>>> index 0000000..ebf0d47
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> @@ -0,0 +1,48 @@
>>> +The generic power sequence library
>>> +
>>> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
>>> +the device can be enumerated on the bus, the typical power sequence
>>> +like: enable USB PHY clock, toggle reset pin, etc. But current
>>> +Linux device driver lacks of such code to do it, it may cause some
>>> +hard-wired devices works abnormal or can't be recognized by
>>> +controller at all. The power sequence will be done before this device
>>> +can be found at the bus.
>>> +
>>> +The power sequence properties is under the device node.
>>> +
>>> +Optional properties:
>>> +- clocks: the input clocks for device.
>>> +- reset-gpios: Should specify the GPIO for reset.
>>> +- reset-duration-us: the duration in microsecond for assert reset signal.
>>> +
>>> +Below is the example of USB power sequence properties on USB device
>>> +nodes which have two level USB hubs.
>>> +
>>> +&usbotg1 {
>>> +	vbus-supply = <&reg_usb_otg1_vbus>;
>>> +	pinctrl-names = "default";
>>> +	pinctrl-0 = <&pinctrl_usb_otg1_id>;
>>> +	status = "okay";
>>> +
>>> +	#address-cells = <1>;
>>> +	#size-cells = <0>;
>>> +	genesys: hub at 1 {
>>> +		compatible = "usb5e3,608";
>>> +		reg = <1>;
>>> +
>>> +		clocks = <&clks IMX6SX_CLK_CKO>;
>>> +		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
>>> +		reset-duration-us = <10>;
>>> +
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +		asix: ethernet at 1 {
>>> +			compatible = "usbb95,1708";
>> So I assume, with our recent discussion and the change
>> we are proposing, the library would have some knowledge
>> about this compatible string, right?
> Yes
>
>> what I was asking on other email was, how are you connecting
>> multiple power sequence libraries to their respective consumers ?
>>
> The consumers has its of_node, then it can find related power sequence
> library according to compatible string.
>

Exactly. Thats what I was referring and wanted to confirm.

Thanks,
Vaibhav


-- 
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

a

On Friday 02 September 2016 06:40 AM, Peter Chen wrote:
> On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:
>>
>> On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
>>> On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
>>>> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
>>>>> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>>>>>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>>>>>> veOn Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>>>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>>>>>> power sequence library for parsing the power sequence elements on DT,
>>>>>>>> and implement generic power sequence on library. The host driver
>>>>>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>>>>>
>>>>>>>> In future, if there are special power sequence requirements, the special
>>>>>>>> power sequence library can be created.
>>>>>>>>
>>>>>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>>>>>> two hot-plug devices to simulate this use case, the related binding
>>>>>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>>>>>> using my last power sequence patch set.[3]
>>>>>>>>
>>>>>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>>>>>> need to power on itself before it can be found by ULPI bus.
>>>>>>>>
>>>>>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>>>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>>>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>>>>>> (Please ignore my response on V2)
>>>>>>>
>>>>>>> Sorry being so late in the discussion...
>>>>>>>
>>>>>>> If I am not missing anything, then I am afraid to say that the
>>>>>>> generic library
>>>>>>> implementation in this patch series is not going to solve many of
>>>>>>> the custom
>>>>>>> requirement of power on, off, etc...
>>>>>>> I know you mentioned about adding another library when we come
>>>>>>> across such platforms, but should we not keep provision (or easy
>>>>>>> hooks/path)
>>>>>>> to enable that ?
>>>>>>>
>>>>>>> Let me bring in the use case I am dealing with,
>>>>>>>
>>>>>>>
>>>>>>>                                Host
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                             USB port
>>>>>>> ------------------------------------------------------------
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                        USB HUB device (May need custom on/off seq)
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                =============================
>>>>>>>               |                             |
>>>>>>>               V                             V
>>>>>>>           Device-1                       Device-2
>>>>>>> (Needs special power               (Needs special power
>>>>>>>   on/off sequence.                   on/off sequence.
>>>>>>>   Also may need custom               Also, may need custom
>>>>>>>   sequence for                       sequence for
>>>>>>>   suspend/resume)                    suspend/resume)
>>>>>>>
>>>>>>>
>>>>>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>>>>>            in terms of functionality, features they support.
>>>>>>>
>>>>>>> In the above case, both Device-1 and Device-2, need separate
>>>>>>> power on/off sequence. So generic library currently we have in this
>>>>>>> patch series is not going to satisfy the need here.
>>>>>>>
>>>>>>> I looked at all 6 revisions of this patch-series, went through the
>>>>>>> review comments, and looked at MMC power sequence code;
>>>>>>> what I can say here is, we need something similar to
>>>>>>> MMC power sequence here, where every device can have its own
>>>>>>> power sequence (if needed).
>>>>>>>
>>>>>>> I know Rob is not in favor of creating platform device for
>>>>>>> this, and I understand his comment.
>>>>>>> If not platform device, but atleast we need mechanism to
>>>>>>> connect each device back to its of_node and its respective
>>>>>>> driver/library fns. For example, the Devices may support different
>>>>>>> boot modes, and platform driver needs to make sure that
>>>>>>> the right sequence is followed for booting.
>>>>>>>
>>>>>>> Peter, My apologies for taking you back again on this series.
>>>>>>> I am OK, if you wish to address this in incremental addition,
>>>>>>> but my point is, we know that the current generic way is not
>>>>>>> enough for us, so I think we should try to fix it in initial phase only.
>>>>>>>
>>>>>> Rob, it seems generic power sequence can't cover all cases.
>>>>>> Without information from DT, we can't know which power sequence
>>>>>> for which device.
>>>>>>
>>>>> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
>>>>> for each library, and choose pwrseq library according to compatible
>>>>> string first, if there is no compatible string for this library, just
>>>>> use generic pwrseq library.
>>>>>
>>>> Lets hear from MMC folks. Ulf, do you agree on approach
>>>> for pwr seq ??
>>>>
>>>>
>>>> With above approach, I kind of agree on it, but I have couple
>>>> of comments,
>>>>
>>>>   - How DTS looks like now ?? Can you put example here ?
>>> The dts is the same with current version.
>> How would consumer driver get the power sequence ?
>> You must point to right power sequence driver.
>> For example, in the above example, Device-1, should
>> get handle to pwrseq-1, and Device-2 to pwrseq-2.
> According to compatible string at device's of_node, we will have a list
> for power sequence libraries which has index (or name), and matches
> compatible string.
>
>>>>   - Should we merge MMC power sequence in next series ?
>>>>     We also can take this as an incremental change, to avoid further
>>>>     delay :)
>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>> Unless Ulf and rob both agree to change.
>> Why 2 separate approach for same problem ?
>> And I see this as possible duplication of code/functionality :)
> How the new kernel compatibles old dts? If we do not need to
> consider this problem, the mmc can try to use power sequence library
> too in future.

I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.

MMC Power Seq :
  It is based on platform_device/platform_driver approach,

USB Power seq :
  We are trying to propose library approach, with compatible string match.

We should try to have one approach.
>
>>>>   - Lets also add suspend/resume callback to struct pwrseq
>>>>
>>> Why suspend/resume can't do at related driver's suspend/resume API?
>> Nope...
>> The pwrseq library would have taken ownership of resources, so
>> related driver cannot suspend the device. Again it is architecture
>> specific, but we should have provision to handle this.
>>
>> The system I am dealing with today, does need suspend/resume
>> callback. To be precise, suspend is close to off state for some devices or
>> they could enter standby or different low power state, but to do that,
>> we need same resource as used for ON/OFF functionality.
>>
> Ok, I will have API for suspend/resume. You can implement it at your own
> library or generic one.
>

Yeup. Sure.

-- 
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

a

On Friday 02 September 2016 06:40 AM, Peter Chen wrote:
> On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:
>>
>> On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
>>> On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
>>>> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
>>>>> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>>>>>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>>>>>> veOn Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>>>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>>>>>> power sequence library for parsing the power sequence elements on DT,
>>>>>>>> and implement generic power sequence on library. The host driver
>>>>>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>>>>>
>>>>>>>> In future, if there are special power sequence requirements, the special
>>>>>>>> power sequence library can be created.
>>>>>>>>
>>>>>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>>>>>> two hot-plug devices to simulate this use case, the related binding
>>>>>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>>>>>> using my last power sequence patch set.[3]
>>>>>>>>
>>>>>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>>>>>> need to power on itself before it can be found by ULPI bus.
>>>>>>>>
>>>>>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>>>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>>>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>>>>>> (Please ignore my response on V2)
>>>>>>>
>>>>>>> Sorry being so late in the discussion...
>>>>>>>
>>>>>>> If I am not missing anything, then I am afraid to say that the
>>>>>>> generic library
>>>>>>> implementation in this patch series is not going to solve many of
>>>>>>> the custom
>>>>>>> requirement of power on, off, etc...
>>>>>>> I know you mentioned about adding another library when we come
>>>>>>> across such platforms, but should we not keep provision (or easy
>>>>>>> hooks/path)
>>>>>>> to enable that ?
>>>>>>>
>>>>>>> Let me bring in the use case I am dealing with,
>>>>>>>
>>>>>>>
>>>>>>>                                Host
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                             USB port
>>>>>>> ------------------------------------------------------------
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                        USB HUB device (May need custom on/off seq)
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                =============================
>>>>>>>               |                             |
>>>>>>>               V                             V
>>>>>>>           Device-1                       Device-2
>>>>>>> (Needs special power               (Needs special power
>>>>>>>   on/off sequence.                   on/off sequence.
>>>>>>>   Also may need custom               Also, may need custom
>>>>>>>   sequence for                       sequence for
>>>>>>>   suspend/resume)                    suspend/resume)
>>>>>>>
>>>>>>>
>>>>>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>>>>>            in terms of functionality, features they support.
>>>>>>>
>>>>>>> In the above case, both Device-1 and Device-2, need separate
>>>>>>> power on/off sequence. So generic library currently we have in this
>>>>>>> patch series is not going to satisfy the need here.
>>>>>>>
>>>>>>> I looked at all 6 revisions of this patch-series, went through the
>>>>>>> review comments, and looked at MMC power sequence code;
>>>>>>> what I can say here is, we need something similar to
>>>>>>> MMC power sequence here, where every device can have its own
>>>>>>> power sequence (if needed).
>>>>>>>
>>>>>>> I know Rob is not in favor of creating platform device for
>>>>>>> this, and I understand his comment.
>>>>>>> If not platform device, but atleast we need mechanism to
>>>>>>> connect each device back to its of_node and its respective
>>>>>>> driver/library fns. For example, the Devices may support different
>>>>>>> boot modes, and platform driver needs to make sure that
>>>>>>> the right sequence is followed for booting.
>>>>>>>
>>>>>>> Peter, My apologies for taking you back again on this series.
>>>>>>> I am OK, if you wish to address this in incremental addition,
>>>>>>> but my point is, we know that the current generic way is not
>>>>>>> enough for us, so I think we should try to fix it in initial phase only.
>>>>>>>
>>>>>> Rob, it seems generic power sequence can't cover all cases.
>>>>>> Without information from DT, we can't know which power sequence
>>>>>> for which device.
>>>>>>
>>>>> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
>>>>> for each library, and choose pwrseq library according to compatible
>>>>> string first, if there is no compatible string for this library, just
>>>>> use generic pwrseq library.
>>>>>
>>>> Lets hear from MMC folks. Ulf, do you agree on approach
>>>> for pwr seq ??
>>>>
>>>>
>>>> With above approach, I kind of agree on it, but I have couple
>>>> of comments,
>>>>
>>>>   - How DTS looks like now ?? Can you put example here ?
>>> The dts is the same with current version.
>> How would consumer driver get the power sequence ?
>> You must point to right power sequence driver.
>> For example, in the above example, Device-1, should
>> get handle to pwrseq-1, and Device-2 to pwrseq-2.
> According to compatible string at device's of_node, we will have a list
> for power sequence libraries which has index (or name), and matches
> compatible string.
>
>>>>   - Should we merge MMC power sequence in next series ?
>>>>     We also can take this as an incremental change, to avoid further
>>>>     delay :)
>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>> Unless Ulf and rob both agree to change.
>> Why 2 separate approach for same problem ?
>> And I see this as possible duplication of code/functionality :)
> How the new kernel compatibles old dts? If we do not need to
> consider this problem, the mmc can try to use power sequence library
> too in future.

I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.

MMC Power Seq :
  It is based on platform_device/platform_driver approach,

USB Power seq :
  We are trying to propose library approach, with compatible string match.

We should try to have one approach.
>
>>>>   - Lets also add suspend/resume callback to struct pwrseq
>>>>
>>> Why suspend/resume can't do at related driver's suspend/resume API?
>> Nope...
>> The pwrseq library would have taken ownership of resources, so
>> related driver cannot suspend the device. Again it is architecture
>> specific, but we should have provision to handle this.
>>
>> The system I am dealing with today, does need suspend/resume
>> callback. To be precise, suspend is close to off state for some devices or
>> they could enter standby or different low power state, but to do that,
>> we need same resource as used for ON/OFF functionality.
>>
> Ok, I will have API for suspend/resume. You can implement it at your own
> library or generic one.
>

Yeup. Sure.

-- 
Thanks,
Vaibhav

--
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 v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

a

On Friday 02 September 2016 06:40 AM, Peter Chen wrote:
> On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:
>>
>> On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
>>> On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
>>>> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
>>>>> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>>>>>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>>>>>> veOn Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>>>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>>>>>> power sequence library for parsing the power sequence elements on DT,
>>>>>>>> and implement generic power sequence on library. The host driver
>>>>>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>>>>>
>>>>>>>> In future, if there are special power sequence requirements, the special
>>>>>>>> power sequence library can be created.
>>>>>>>>
>>>>>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>>>>>> two hot-plug devices to simulate this use case, the related binding
>>>>>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>>>>>> using my last power sequence patch set.[3]
>>>>>>>>
>>>>>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>>>>>> need to power on itself before it can be found by ULPI bus.
>>>>>>>>
>>>>>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>>>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>>>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>>>>>> (Please ignore my response on V2)
>>>>>>>
>>>>>>> Sorry being so late in the discussion...
>>>>>>>
>>>>>>> If I am not missing anything, then I am afraid to say that the
>>>>>>> generic library
>>>>>>> implementation in this patch series is not going to solve many of
>>>>>>> the custom
>>>>>>> requirement of power on, off, etc...
>>>>>>> I know you mentioned about adding another library when we come
>>>>>>> across such platforms, but should we not keep provision (or easy
>>>>>>> hooks/path)
>>>>>>> to enable that ?
>>>>>>>
>>>>>>> Let me bring in the use case I am dealing with,
>>>>>>>
>>>>>>>
>>>>>>>                                Host
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                             USB port
>>>>>>> ------------------------------------------------------------
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                        USB HUB device (May need custom on/off seq)
>>>>>>>                                 |
>>>>>>>                                 V
>>>>>>>                =============================
>>>>>>>               |                             |
>>>>>>>               V                             V
>>>>>>>           Device-1                       Device-2
>>>>>>> (Needs special power               (Needs special power
>>>>>>>   on/off sequence.                   on/off sequence.
>>>>>>>   Also may need custom               Also, may need custom
>>>>>>>   sequence for                       sequence for
>>>>>>>   suspend/resume)                    suspend/resume)
>>>>>>>
>>>>>>>
>>>>>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>>>>>>            in terms of functionality, features they support.
>>>>>>>
>>>>>>> In the above case, both Device-1 and Device-2, need separate
>>>>>>> power on/off sequence. So generic library currently we have in this
>>>>>>> patch series is not going to satisfy the need here.
>>>>>>>
>>>>>>> I looked at all 6 revisions of this patch-series, went through the
>>>>>>> review comments, and looked at MMC power sequence code;
>>>>>>> what I can say here is, we need something similar to
>>>>>>> MMC power sequence here, where every device can have its own
>>>>>>> power sequence (if needed).
>>>>>>>
>>>>>>> I know Rob is not in favor of creating platform device for
>>>>>>> this, and I understand his comment.
>>>>>>> If not platform device, but atleast we need mechanism to
>>>>>>> connect each device back to its of_node and its respective
>>>>>>> driver/library fns. For example, the Devices may support different
>>>>>>> boot modes, and platform driver needs to make sure that
>>>>>>> the right sequence is followed for booting.
>>>>>>>
>>>>>>> Peter, My apologies for taking you back again on this series.
>>>>>>> I am OK, if you wish to address this in incremental addition,
>>>>>>> but my point is, we know that the current generic way is not
>>>>>>> enough for us, so I think we should try to fix it in initial phase only.
>>>>>>>
>>>>>> Rob, it seems generic power sequence can't cover all cases.
>>>>>> Without information from DT, we can't know which power sequence
>>>>>> for which device.
>>>>>>
>>>>> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
>>>>> for each library, and choose pwrseq library according to compatible
>>>>> string first, if there is no compatible string for this library, just
>>>>> use generic pwrseq library.
>>>>>
>>>> Lets hear from MMC folks. Ulf, do you agree on approach
>>>> for pwr seq ??
>>>>
>>>>
>>>> With above approach, I kind of agree on it, but I have couple
>>>> of comments,
>>>>
>>>>   - How DTS looks like now ?? Can you put example here ?
>>> The dts is the same with current version.
>> How would consumer driver get the power sequence ?
>> You must point to right power sequence driver.
>> For example, in the above example, Device-1, should
>> get handle to pwrseq-1, and Device-2 to pwrseq-2.
> According to compatible string at device's of_node, we will have a list
> for power sequence libraries which has index (or name), and matches
> compatible string.
>
>>>>   - Should we merge MMC power sequence in next series ?
>>>>     We also can take this as an incremental change, to avoid further
>>>>     delay :)
>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>> Unless Ulf and rob both agree to change.
>> Why 2 separate approach for same problem ?
>> And I see this as possible duplication of code/functionality :)
> How the new kernel compatibles old dts? If we do not need to
> consider this problem, the mmc can try to use power sequence library
> too in future.

I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.

MMC Power Seq :
  It is based on platform_device/platform_driver approach,

USB Power seq :
  We are trying to propose library approach, with compatible string match.

We should try to have one approach.
>
>>>>   - Lets also add suspend/resume callback to struct pwrseq
>>>>
>>> Why suspend/resume can't do at related driver's suspend/resume API?
>> Nope...
>> The pwrseq library would have taken ownership of resources, so
>> related driver cannot suspend the device. Again it is architecture
>> specific, but we should have provision to handle this.
>>
>> The system I am dealing with today, does need suspend/resume
>> callback. To be precise, suspend is close to off state for some devices or
>> they could enter standby or different low power state, but to do that,
>> we need same resource as used for ON/OFF functionality.
>>
> Ok, I will have API for suspend/resume. You can implement it at your own
> library or generic one.
>

Yeup. Sure.

-- 
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Ulf Hansson]

[...]

>>>>
>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>> Unless Ulf and rob both agree to change.
>>>
>>> Why 2 separate approach for same problem ?
>>> And I see this as possible duplication of code/functionality :)
>>
>> How the new kernel compatibles old dts? If we do not need to
>> consider this problem, the mmc can try to use power sequence library
>> too in future.
>
>
> I think we should attempt to get both MMC and USB power seq
> come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?

>
> MMC Power Seq :
>  It is based on platform_device/platform_driver approach,

We recently converted MMC to this. It's has a clear benefit as you can
rely on the behaviour from the driver core and PM core. So, it simply
avoids duplication of code.

>
> USB Power seq :
>  We are trying to propose library approach, with compatible string match.
>
> We should try to have one approach.
>>
>>
>>>>>   - Lets also add suspend/resume callback to struct pwrseq
>>>>>
>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>
>>> Nope...
>>> The pwrseq library would have taken ownership of resources, so
>>> related driver cannot suspend the device. Again it is architecture
>>> specific, but we should have provision to handle this.
>>>
>>> The system I am dealing with today, does need suspend/resume
>>> callback. To be precise, suspend is close to off state for some devices
>>> or
>>> they could enter standby or different low power state, but to do that,
>>> we need same resource as used for ON/OFF functionality.
>>>
>> Ok, I will have API for suspend/resume. You can implement it at your own
>> library or generic one.

As stated, using a platform device + driver would simplify this, as
you wouldn't need an API but only a driver. I guess.

Kind regards
Uffe

Re: [PATCH v6 0/8] power: add power sequence library

[Ulf Hansson]

[...]

>>>>
>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>> Unless Ulf and rob both agree to change.
>>>
>>> Why 2 separate approach for same problem ?
>>> And I see this as possible duplication of code/functionality :)
>>
>> How the new kernel compatibles old dts? If we do not need to
>> consider this problem, the mmc can try to use power sequence library
>> too in future.
>
>
> I think we should attempt to get both MMC and USB power seq
> come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?

>
> MMC Power Seq :
>  It is based on platform_device/platform_driver approach,

We recently converted MMC to this. It's has a clear benefit as you can
rely on the behaviour from the driver core and PM core. So, it simply
avoids duplication of code.

>
> USB Power seq :
>  We are trying to propose library approach, with compatible string match.
>
> We should try to have one approach.
>>
>>
>>>>>   - Lets also add suspend/resume callback to struct pwrseq
>>>>>
>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>
>>> Nope...
>>> The pwrseq library would have taken ownership of resources, so
>>> related driver cannot suspend the device. Again it is architecture
>>> specific, but we should have provision to handle this.
>>>
>>> The system I am dealing with today, does need suspend/resume
>>> callback. To be precise, suspend is close to off state for some devices
>>> or
>>> they could enter standby or different low power state, but to do that,
>>> we need same resource as used for ON/OFF functionality.
>>>
>> Ok, I will have API for suspend/resume. You can implement it at your own
>> library or generic one.

As stated, using a platform device + driver would simplify this, as
you wouldn't need an API but only a driver. I guess.

Kind regards
Uffe

[PATCH v6 0/8] power: add power sequence library

[Ulf Hansson]

[...]

>>>>
>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>> Unless Ulf and rob both agree to change.
>>>
>>> Why 2 separate approach for same problem ?
>>> And I see this as possible duplication of code/functionality :)
>>
>> How the new kernel compatibles old dts? If we do not need to
>> consider this problem, the mmc can try to use power sequence library
>> too in future.
>
>
> I think we should attempt to get both MMC and USB power seq
> come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?

>
> MMC Power Seq :
>  It is based on platform_device/platform_driver approach,

We recently converted MMC to this. It's has a clear benefit as you can
rely on the behaviour from the driver core and PM core. So, it simply
avoids duplication of code.

>
> USB Power seq :
>  We are trying to propose library approach, with compatible string match.
>
> We should try to have one approach.
>>
>>
>>>>>   - Lets also add suspend/resume callback to struct pwrseq
>>>>>
>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>
>>> Nope...
>>> The pwrseq library would have taken ownership of resources, so
>>> related driver cannot suspend the device. Again it is architecture
>>> specific, but we should have provision to handle this.
>>>
>>> The system I am dealing with today, does need suspend/resume
>>> callback. To be precise, suspend is close to off state for some devices
>>> or
>>> they could enter standby or different low power state, but to do that,
>>> we need same resource as used for ON/OFF functionality.
>>>
>> Ok, I will have API for suspend/resume. You can implement it at your own
>> library or generic one.

As stated, using a platform device + driver would simplify this, as
you wouldn't need an API but only a driver. I guess.

Kind regards
Uffe

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> [...]
>
>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>> Unless Ulf and rob both agree to change.
>>>> Why 2 separate approach for same problem ?
>>>> And I see this as possible duplication of code/functionality :)
>>> How the new kernel compatibles old dts? If we do not need to
>>> consider this problem, the mmc can try to use power sequence library
>>> too in future.
>>
>> I think we should attempt to get both MMC and USB power seq
>> come on one agreement, so that it can be reused.
> That would be nice. Although, to do that you would have to allow some
> DT bindings to be deprecated in the new generic power seq bindings, as
> otherwise you would break existing DTBs.
>
> I guess that is what Rob was objecting to!?

yeah, thats right.

So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.

What I am trying to propose here is,

Lets have power-sequence framework (similar to V1 of this series),
with,

pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
                           here is, all future code should be using this new
                           binding, so that we can deprecate the 
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
                          complex in nature.

Then the respective drivers can add their drivers (if needed) based on
complexity.

comments ??

>> MMC Power Seq :
>>   It is based on platform_device/platform_driver approach,
> We recently converted MMC to this. It's has a clear benefit as you can
> rely on the behaviour from the driver core and PM core. So, it simply
> avoids duplication of code.

Agreed.

>> USB Power seq :
>>   We are trying to propose library approach, with compatible string match.
>>
>> We should try to have one approach.
>>>
>>>>>>    - Lets also add suspend/resume callback to struct pwrseq
>>>>>>
>>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>> Nope...
>>>> The pwrseq library would have taken ownership of resources, so
>>>> related driver cannot suspend the device. Again it is architecture
>>>> specific, but we should have provision to handle this.
>>>>
>>>> The system I am dealing with today, does need suspend/resume
>>>> callback. To be precise, suspend is close to off state for some devices
>>>> or
>>>> they could enter standby or different low power state, but to do that,
>>>> we need same resource as used for ON/OFF functionality.
>>>>
>>> Ok, I will have API for suspend/resume. You can implement it at your own
>>> library or generic one.
> As stated, using a platform device + driver would simplify this, as
> you wouldn't need an API but only a driver. I guess.

Exactly.

Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> [...]
>
>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>> Unless Ulf and rob both agree to change.
>>>> Why 2 separate approach for same problem ?
>>>> And I see this as possible duplication of code/functionality :)
>>> How the new kernel compatibles old dts? If we do not need to
>>> consider this problem, the mmc can try to use power sequence library
>>> too in future.
>>
>> I think we should attempt to get both MMC and USB power seq
>> come on one agreement, so that it can be reused.
> That would be nice. Although, to do that you would have to allow some
> DT bindings to be deprecated in the new generic power seq bindings, as
> otherwise you would break existing DTBs.
>
> I guess that is what Rob was objecting to!?

yeah, thats right.

So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.

What I am trying to propose here is,

Lets have power-sequence framework (similar to V1 of this series),
with,

pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
                           here is, all future code should be using this new
                           binding, so that we can deprecate the 
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
                          complex in nature.

Then the respective drivers can add their drivers (if needed) based on
complexity.

comments ??

>> MMC Power Seq :
>>   It is based on platform_device/platform_driver approach,
> We recently converted MMC to this. It's has a clear benefit as you can
> rely on the behaviour from the driver core and PM core. So, it simply
> avoids duplication of code.

Agreed.

>> USB Power seq :
>>   We are trying to propose library approach, with compatible string match.
>>
>> We should try to have one approach.
>>>
>>>>>>    - Lets also add suspend/resume callback to struct pwrseq
>>>>>>
>>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>> Nope...
>>>> The pwrseq library would have taken ownership of resources, so
>>>> related driver cannot suspend the device. Again it is architecture
>>>> specific, but we should have provision to handle this.
>>>>
>>>> The system I am dealing with today, does need suspend/resume
>>>> callback. To be precise, suspend is close to off state for some devices
>>>> or
>>>> they could enter standby or different low power state, but to do that,
>>>> we need same resource as used for ON/OFF functionality.
>>>>
>>> Ok, I will have API for suspend/resume. You can implement it at your own
>>> library or generic one.
> As stated, using a platform device + driver would simplify this, as
> you wouldn't need an API but only a driver. I guess.

Exactly.

Thanks,
Vaibhav

[PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> [...]
>
>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>> Unless Ulf and rob both agree to change.
>>>> Why 2 separate approach for same problem ?
>>>> And I see this as possible duplication of code/functionality :)
>>> How the new kernel compatibles old dts? If we do not need to
>>> consider this problem, the mmc can try to use power sequence library
>>> too in future.
>>
>> I think we should attempt to get both MMC and USB power seq
>> come on one agreement, so that it can be reused.
> That would be nice. Although, to do that you would have to allow some
> DT bindings to be deprecated in the new generic power seq bindings, as
> otherwise you would break existing DTBs.
>
> I guess that is what Rob was objecting to!?

yeah, thats right.

So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.

What I am trying to propose here is,

Lets have power-sequence framework (similar to V1 of this series),
with,

pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
                           here is, all future code should be using this new
                           binding, so that we can deprecate the 
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
                          complex in nature.

Then the respective drivers can add their drivers (if needed) based on
complexity.

comments ??

>> MMC Power Seq :
>>   It is based on platform_device/platform_driver approach,
> We recently converted MMC to this. It's has a clear benefit as you can
> rely on the behaviour from the driver core and PM core. So, it simply
> avoids duplication of code.

Agreed.

>> USB Power seq :
>>   We are trying to propose library approach, with compatible string match.
>>
>> We should try to have one approach.
>>>
>>>>>>    - Lets also add suspend/resume callback to struct pwrseq
>>>>>>
>>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>> Nope...
>>>> The pwrseq library would have taken ownership of resources, so
>>>> related driver cannot suspend the device. Again it is architecture
>>>> specific, but we should have provision to handle this.
>>>>
>>>> The system I am dealing with today, does need suspend/resume
>>>> callback. To be precise, suspend is close to off state for some devices
>>>> or
>>>> they could enter standby or different low power state, but to do that,
>>>> we need same resource as used for ON/OFF functionality.
>>>>
>>> Ok, I will have API for suspend/resume. You can implement it at your own
>>> library or generic one.
> As stated, using a platform device + driver would simplify this, as
> you wouldn't need an API but only a driver. I guess.

Exactly.

Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> >[...]
> >
> >>>>>We had an agreement that keep mmc's pwrseq framework unchanging.
> >>>>>Unless Ulf and rob both agree to change.
> >>>>Why 2 separate approach for same problem ?
> >>>>And I see this as possible duplication of code/functionality :)
> >>>How the new kernel compatibles old dts? If we do not need to
> >>>consider this problem, the mmc can try to use power sequence library
> >>>too in future.
> >>
> >>I think we should attempt to get both MMC and USB power seq
> >>come on one agreement, so that it can be reused.
> >That would be nice. Although, to do that you would have to allow some
> >DT bindings to be deprecated in the new generic power seq bindings, as
> >otherwise you would break existing DTBs.
> >
> >I guess that is what Rob was objecting to!?
> 
> yeah, thats right.
> 
> So lets adopt similar implementation for USB as well instead of
> library, but keeping MMC untouched as of now.
> 
> What I am trying to propose here is,
> 
> Lets have power-sequence framework (similar to V1 of this series),
> with,
> 
> pwrseq: Core framework for power sequence.
> pwrseq_generic/simple: for all generic control, like reset and clock
> pwrseq_emmc: probably duplication of existing code - the idea
>                           here is, all future code should be using this new
>                           binding, so that we can deprecate the
> drivers/mmc/core/pwrseq
> pwrseq_arche: The usecase which I am dealing with today, which is more
>                          complex in nature.
> 
> Then the respective drivers can add their drivers (if needed) based on
> complexity.
> 
> comments ??

The key point here is DT maintainer (Rob) doesn't agree with adding new node
for power sequence at dts.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> >[...]
> >
> >>>>>We had an agreement that keep mmc's pwrseq framework unchanging.
> >>>>>Unless Ulf and rob both agree to change.
> >>>>Why 2 separate approach for same problem ?
> >>>>And I see this as possible duplication of code/functionality :)
> >>>How the new kernel compatibles old dts? If we do not need to
> >>>consider this problem, the mmc can try to use power sequence library
> >>>too in future.
> >>
> >>I think we should attempt to get both MMC and USB power seq
> >>come on one agreement, so that it can be reused.
> >That would be nice. Although, to do that you would have to allow some
> >DT bindings to be deprecated in the new generic power seq bindings, as
> >otherwise you would break existing DTBs.
> >
> >I guess that is what Rob was objecting to!?
> 
> yeah, thats right.
> 
> So lets adopt similar implementation for USB as well instead of
> library, but keeping MMC untouched as of now.
> 
> What I am trying to propose here is,
> 
> Lets have power-sequence framework (similar to V1 of this series),
> with,
> 
> pwrseq: Core framework for power sequence.
> pwrseq_generic/simple: for all generic control, like reset and clock
> pwrseq_emmc: probably duplication of existing code - the idea
>                           here is, all future code should be using this new
>                           binding, so that we can deprecate the
> drivers/mmc/core/pwrseq
> pwrseq_arche: The usecase which I am dealing with today, which is more
>                          complex in nature.
> 
> Then the respective drivers can add their drivers (if needed) based on
> complexity.
> 
> comments ??

The key point here is DT maintainer (Rob) doesn't agree with adding new node
for power sequence at dts.

-- 

Best Regards,
Peter Chen
--
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 v6 0/8] power: add power sequence library

[Peter Chen]

On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> >[...]
> >
> >>>>>We had an agreement that keep mmc's pwrseq framework unchanging.
> >>>>>Unless Ulf and rob both agree to change.
> >>>>Why 2 separate approach for same problem ?
> >>>>And I see this as possible duplication of code/functionality :)
> >>>How the new kernel compatibles old dts? If we do not need to
> >>>consider this problem, the mmc can try to use power sequence library
> >>>too in future.
> >>
> >>I think we should attempt to get both MMC and USB power seq
> >>come on one agreement, so that it can be reused.
> >That would be nice. Although, to do that you would have to allow some
> >DT bindings to be deprecated in the new generic power seq bindings, as
> >otherwise you would break existing DTBs.
> >
> >I guess that is what Rob was objecting to!?
> 
> yeah, thats right.
> 
> So lets adopt similar implementation for USB as well instead of
> library, but keeping MMC untouched as of now.
> 
> What I am trying to propose here is,
> 
> Lets have power-sequence framework (similar to V1 of this series),
> with,
> 
> pwrseq: Core framework for power sequence.
> pwrseq_generic/simple: for all generic control, like reset and clock
> pwrseq_emmc: probably duplication of existing code - the idea
>                           here is, all future code should be using this new
>                           binding, so that we can deprecate the
> drivers/mmc/core/pwrseq
> pwrseq_arche: The usecase which I am dealing with today, which is more
>                          complex in nature.
> 
> Then the respective drivers can add their drivers (if needed) based on
> complexity.
> 
> comments ??

The key point here is DT maintainer (Rob) doesn't agree with adding new node
for power sequence at dts.

-- 

Best Regards,
Peter Chen

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 19 September 2016 01:16 PM, Peter Chen wrote:
> On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
>>
>> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
>>> [...]
>>>
>>>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>>>> Unless Ulf and rob both agree to change.
>>>>>> Why 2 separate approach for same problem ?
>>>>>> And I see this as possible duplication of code/functionality :)
>>>>> How the new kernel compatibles old dts? If we do not need to
>>>>> consider this problem, the mmc can try to use power sequence library
>>>>> too in future.
>>>> I think we should attempt to get both MMC and USB power seq
>>>> come on one agreement, so that it can be reused.
>>> That would be nice. Although, to do that you would have to allow some
>>> DT bindings to be deprecated in the new generic power seq bindings, as
>>> otherwise you would break existing DTBs.
>>>
>>> I guess that is what Rob was objecting to!?
>> yeah, thats right.
>>
>> So lets adopt similar implementation for USB as well instead of
>> library, but keeping MMC untouched as of now.
>>
>> What I am trying to propose here is,
>>
>> Lets have power-sequence framework (similar to V1 of this series),
>> with,
>>
>> pwrseq: Core framework for power sequence.
>> pwrseq_generic/simple: for all generic control, like reset and clock
>> pwrseq_emmc: probably duplication of existing code - the idea
>>                            here is, all future code should be using this new
>>                            binding, so that we can deprecate the
>> drivers/mmc/core/pwrseq
>> pwrseq_arche: The usecase which I am dealing with today, which is more
>>                           complex in nature.
>>
>> Then the respective drivers can add their drivers (if needed) based on
>> complexity.
>>
>> comments ??
> The key point here is DT maintainer (Rob) doesn't agree with adding new node
> for power sequence at dts.
>

Hmmm.
We haven't heard from Rob lately especially after introduction of complex
usecases. I hope he would revisit on above proposal.

Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 19 September 2016 01:16 PM, Peter Chen wrote:
> On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
>>
>> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
>>> [...]
>>>
>>>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>>>> Unless Ulf and rob both agree to change.
>>>>>> Why 2 separate approach for same problem ?
>>>>>> And I see this as possible duplication of code/functionality :)
>>>>> How the new kernel compatibles old dts? If we do not need to
>>>>> consider this problem, the mmc can try to use power sequence library
>>>>> too in future.
>>>> I think we should attempt to get both MMC and USB power seq
>>>> come on one agreement, so that it can be reused.
>>> That would be nice. Although, to do that you would have to allow some
>>> DT bindings to be deprecated in the new generic power seq bindings, as
>>> otherwise you would break existing DTBs.
>>>
>>> I guess that is what Rob was objecting to!?
>> yeah, thats right.
>>
>> So lets adopt similar implementation for USB as well instead of
>> library, but keeping MMC untouched as of now.
>>
>> What I am trying to propose here is,
>>
>> Lets have power-sequence framework (similar to V1 of this series),
>> with,
>>
>> pwrseq: Core framework for power sequence.
>> pwrseq_generic/simple: for all generic control, like reset and clock
>> pwrseq_emmc: probably duplication of existing code - the idea
>>                            here is, all future code should be using this new
>>                            binding, so that we can deprecate the
>> drivers/mmc/core/pwrseq
>> pwrseq_arche: The usecase which I am dealing with today, which is more
>>                           complex in nature.
>>
>> Then the respective drivers can add their drivers (if needed) based on
>> complexity.
>>
>> comments ??
> The key point here is DT maintainer (Rob) doesn't agree with adding new node
> for power sequence at dts.
>

Hmmm.
We haven't heard from Rob lately especially after introduction of complex
usecases. I hope he would revisit on above proposal.

Thanks,
Vaibhav
--
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 v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 19 September 2016 01:16 PM, Peter Chen wrote:
> On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
>>
>> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
>>> [...]
>>>
>>>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>>>> Unless Ulf and rob both agree to change.
>>>>>> Why 2 separate approach for same problem ?
>>>>>> And I see this as possible duplication of code/functionality :)
>>>>> How the new kernel compatibles old dts? If we do not need to
>>>>> consider this problem, the mmc can try to use power sequence library
>>>>> too in future.
>>>> I think we should attempt to get both MMC and USB power seq
>>>> come on one agreement, so that it can be reused.
>>> That would be nice. Although, to do that you would have to allow some
>>> DT bindings to be deprecated in the new generic power seq bindings, as
>>> otherwise you would break existing DTBs.
>>>
>>> I guess that is what Rob was objecting to!?
>> yeah, thats right.
>>
>> So lets adopt similar implementation for USB as well instead of
>> library, but keeping MMC untouched as of now.
>>
>> What I am trying to propose here is,
>>
>> Lets have power-sequence framework (similar to V1 of this series),
>> with,
>>
>> pwrseq: Core framework for power sequence.
>> pwrseq_generic/simple: for all generic control, like reset and clock
>> pwrseq_emmc: probably duplication of existing code - the idea
>>                            here is, all future code should be using this new
>>                            binding, so that we can deprecate the
>> drivers/mmc/core/pwrseq
>> pwrseq_arche: The usecase which I am dealing with today, which is more
>>                           complex in nature.
>>
>> Then the respective drivers can add their drivers (if needed) based on
>> complexity.
>>
>> comments ??
> The key point here is DT maintainer (Rob) doesn't agree with adding new node
> for power sequence at dts.
>

Hmmm.
We haven't heard from Rob lately especially after introduction of complex
usecases. I hope he would revisit on above proposal.

Thanks,
Vaibhav