usb: ehci-exynos: Make provision for vdd regulators

Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos.

With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators.

Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working.

Signed-off-by Vivek Gautam <[email protected]>

Signed-off-by Anand Moon <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Alan Stern <[email protected]>

---
Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

---
 .../devicetree/bindings/usb/exynos-usb.txt         |  2 +
 drivers/usb/host/ehci-exynos.c                     | 55 +++++++++++++++++++++-
 2 files changed, 56 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/usb/exynos-usb.txt +2 -0

index 9b4dbe3..776fa03 100644
@@ -23,6 +23,8 @@ Required properties:
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
    needs to be pulled up for the bus to be powered.
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
 
 Example:
 

drivers/usb/host/ehci-exynos.c +24 -1

index df538fd..4f8f9d2 100644
@@ -21,6 +21,7 @@
 #include <linux/of_gpio.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 

@@ -45,6 +46,8 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 struct exynos_ehci_hcd {
 	struct clk *clk;
 	struct phy *phy[PHY_NUMBER];
+	struct regulator *vdd33;
+	struct regulator *vdd10;
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)

@@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device *pdev)
 
 	err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
 	if (err)
-		goto fail_clk;
+		goto fail_regulator1;
+
+	exynos_ehci->vdd33 = devm_regulator_get_optional(&pdev->dev, "vdd33");
+	if (!IS_ERR(exynos_ehci->vdd33)) {
+		err = regulator_enable(exynos_ehci->vdd33);
+		if (err) {
+			dev_err(&pdev->dev,
+				"Failed to enable 3.3V Vdd supply\n");
+			goto fail_regulator1;
+		}
+	}
+
+	exynos_ehci->vdd10 = devm_regulator_get_optional(&pdev->dev, "vdd10");
+	if (!IS_ERR(exynos_ehci->vdd10)) {
+		err = regulator_enable(exynos_ehci->vdd10);
+		if (err) {
+			dev_err(&pdev->dev,
+				"Failed to enable 1.0V Vdd supply\n");
+			goto fail_regulator2;
+		}
+	}
 
 skip_phy:
 

drivers/usb/host/ehci-exynos.c +6 -0

+fail_regulator1:
 	usb_put_hcd(hcd);
 	return err;
 }

@@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device *pdev)
 
 	clk_disable_unprepare(exynos_ehci->clk);
 
+	if (!IS_ERR(exynos_ehci->vdd33))
+		regulator_disable(exynos_ehci->vdd33);
+	if (!IS_ERR(exynos_ehci->vdd10))
+		regulator_disable(exynos_ehci->vdd10);
+
 	usb_put_hcd(hcd);
 
 	return 0;

Quoted 25 lines · Anand Moon

Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos.

With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators.

Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working.

Signed-off-by Vivek Gautam <[email protected]>

Signed-off-by Anand Moon <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Alan Stern <[email protected]>

---
Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing.

Quoted 1 line

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

So you just took Vivek's patch along with all the credits... That is not how we usually do this.

I would expect that rebasing a patch won't change the author unless this is fine with Vivek.

Quoted 69 lines

---
 .../devicetree/bindings/usb/exynos-usb.txt         |  2 +
 drivers/usb/host/ehci-exynos.c                     | 55 +++++++++++++++++++++-
 2 files changed, 56 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/usb/exynos-usb.txt +2 -0

index 9b4dbe3..776fa03 100644
@@ -23,6 +23,8 @@ Required properties:
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
    needs to be pulled up for the bus to be powered.
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
 
 Example:
 

drivers/usb/host/ehci-exynos.c +24 -1

index df538fd..4f8f9d2 100644
@@ -21,6 +21,7 @@
 #include <linux/of_gpio.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 

@@ -45,6 +46,8 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 struct exynos_ehci_hcd {
      struct clk *clk;
      struct phy *phy[PHY_NUMBER];
+     struct regulator *vdd33;
+     struct regulator *vdd10;
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)

@@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device *pdev)
 
      err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
      if (err)
-             goto fail_clk;
+             goto fail_regulator1;
+
+     exynos_ehci->vdd33 = devm_regulator_get_optional(&pdev->dev, "vdd33");
+     if (!IS_ERR(exynos_ehci->vdd33)) {
+             err = regulator_enable(exynos_ehci->vdd33);
+             if (err) {
+                     dev_err(&pdev->dev,
+                             "Failed to enable 3.3V Vdd supply\n");
+                     goto fail_regulator1;
+             }
+     }
+
+     exynos_ehci->vdd10 = devm_regulator_get_optional(&pdev->dev, "vdd10");
+     if (!IS_ERR(exynos_ehci->vdd10)) {
+             err = regulator_enable(exynos_ehci->vdd10);
+             if (err) {
+                     dev_err(&pdev->dev,
+                             "Failed to enable 1.0V Vdd supply\n");
+                     goto fail_regulator2;
+             }
+     }
 
 skip_phy:
 

drivers/usb/host/ehci-exynos.c fail_add_hcd: · line 259

Quoted 6 lines

drivers/usb/host/ehci-exynos.c +3 -0

@@ -231,6 +254,10 @@ fail_add_hcd:
 fail_io:
      clk_disable_unprepare(exynos_ehci->clk);
 fail_clk:
+     regulator_disable(exynos_ehci->vdd10);
+fail_regulator2:
+     regulator_disable(exynos_ehci->vdd33);

if (!IS_ERR()).

Quoted 17 lines

drivers/usb/host/ehci-exynos.c +6 -0

+fail_regulator1:
      usb_put_hcd(hcd);
      return err;
 }

@@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device *pdev)
 
      clk_disable_unprepare(exynos_ehci->clk);
 
+     if (!IS_ERR(exynos_ehci->vdd33))
+             regulator_disable(exynos_ehci->vdd33);
+     if (!IS_ERR(exynos_ehci->vdd10))
+             regulator_disable(exynos_ehci->vdd10);
+
      usb_put_hcd(hcd);
 
      return 0;

drivers/usb/host/ehci-exynos.c static int exynos_ehci_suspend(struct device *dev) · line 307

Quoted 8 lines

drivers/usb/host/ehci-exynos.c +5 -0

@@ -268,6 +300,11 @@ static int exynos_ehci_suspend(struct device *dev)
 
      clk_disable_unprepare(exynos_ehci->clk);
 
+     if (!IS_ERR(exynos_ehci->vdd33))
+             regulator_disable(exynos_ehci->vdd33);
+     if (!IS_ERR(exynos_ehci->vdd10))
+             regulator_disable(exynos_ehci->vdd10);
+

Is EHCI a wakeup source? If yes then how disabling regulators during suspend affects waking up process?

Best regards,
Krzysztof

Hi Krzysztof ,

Quoted 31 lines · Krzysztof Kozlowski

Quoted 21 lines · Anand Moon

Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos.

With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators.

Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working.

Signed-off-by Vivek Gautam <[email protected]>

Signed-off-by Anand Moon <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Alan Stern <[email protected]>

Quoted 5 lines

---
Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

So you just took Vivek's patch along with all the credits... That is not how we usually do this.

Quoted 3 lines

I would expect that rebasing a patch won't change the author unless this is fine with Vivek.

Sorry If I have done some mistake on my part. I just looked at below mail chain. Before I send it.

http://www.spinics.net/lists/linux-samsung-soc/msg44136.html

I don't want to take any credit out of it. I just re-base on the new kernel. I could not test this patch as it meant for exynos5440 boards.

2015-06-08 13:21 GMT+09:00 Anand Moon <[email protected]>:

Quoted 39 lines

Hi Krzysztof ,

Quoted 34 lines · Krzysztof Kozlowski

Quoted 21 lines · Anand Moon

Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos.

With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators.

Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working.

Signed-off-by Vivek Gautam <[email protected]>

Signed-off-by Anand Moon <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Alan Stern <[email protected]>

Quoted 5 lines

---
Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

So you just took Vivek's patch along with all the credits... That is not how we usually do this.

I would expect that rebasing a patch won't change the author unless this is fine with Vivek.

Quoted 4 lines

Sorry If I have done some mistake on my part. I just looked at below mail chain. Before I send it.

http://www.spinics.net/lists/linux-samsung-soc/msg44136.html

I don't get it. The patch you are referring to has a proper "From" field. So please use it as an example.

Quoted 3 lines

I don't want to take any credit out of it. I just re-base on the new kernel.

Quoted 1 line

I could not test this patch as it meant for exynos5440 boards.

Are you sure? I think the driver is used on almost all of Exynos SoCs (Exynos4, Exynos5250, Exynos542x).

Untested code should not go to the kernel. Additionally you should mark it as not-tested. Marking such patch as non-tested could help you finding some independent tests (tests performed by someone else).

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up).
3. The patchset must be tested, even after rebasing.

Best regards,
Krzysztof

Hi,

On Monday, June 08, 2015 10:44 AM, "Krzysztof Kozlowski" <[email protected]> wrote:

my apologies for being late in replying to this thread.

Quoted 45 lines

2015-06-08 13:21 GMT+09:00 Anand Moon <[email protected]>:

Quoted 44 lines

Hi Krzysztof ,

Quoted 38 lines · Krzysztof Kozlowski

Quoted 22 lines · Anand Moon

Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos.

With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators.

Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working.

Signed-off-by Vivek Gautam <[email protected]>

Signed-off-by Anand Moon <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Alan Stern <[email protected]>

Quoted 6 lines

---
Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

So you just took Vivek's patch along with all the credits... That is not how we usually do this.

I would expect that rebasing a patch won't change the author unless this is fine with Vivek.

Quoted 12 lines

Quoted 4 lines

Sorry If I have done some mistake on my part. I just looked at below mail chain. Before I send it.

http://www.spinics.net/lists/linux-samsung-soc/msg44136.html

I don't get it. The patch you are referring to has a proper "From" field. So please use it as an example.

Quoted 3 lines

I don't want to take any credit out of it. I just re-base on the new kernel.

Perhaps, you would have maintained the authorship !

Quoted 5 lines

Quoted 1 line

I could not test this patch as it meant for exynos5440 boards.

Are you sure? I think the driver is used on almost all of Exynos SoCs (Exynos4, Exynos5250, Exynos542x).

That's correct, as pointed by Krzysztof Kozlowski, the driver is same for Exynos4 and Exynos5 series
of SoCs.

Quoted 11 lines

Untested code should not go to the kernel. Additionally you should mark it as not-tested. Marking such patch as non-tested could help you finding some independent tests (tests performed by someone else).

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up).
3. The patchset must be tested, even after rebasing.

Unfortunately, I got busy with a different project and lost track of the patches posted upstream.
If it's not too late I can post a rebased version of the patch with previous review comments addressed.

Quoted 3 lines

Best regards,
Krzysztof

Quoted 93 lines

Hi,

On Monday, June 08, 2015 10:44 AM, "Krzysztof Kozlowski" <[email protected]> wrote:

my apologies for being late in replying to this thread.

Quoted 45 lines

2015-06-08 13:21 GMT+09:00 Anand Moon <[email protected]>:

Quoted 44 lines

Hi Krzysztof ,

Quoted 38 lines · Krzysztof Kozlowski

Quoted 22 lines · Anand Moon

Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos.

With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators.

Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working.

Signed-off-by Vivek Gautam <[email protected]>

Signed-off-by Anand Moon <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Alan Stern <[email protected]>

Quoted 6 lines

---
Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

So you just took Vivek's patch along with all the credits... That is not how we usually do this.

I would expect that rebasing a patch won't change the author unless this is fine with Vivek.

Quoted 12 lines

Quoted 4 lines

Sorry If I have done some mistake on my part. I just looked at below mail chain. Before I send it.

http://www.spinics.net/lists/linux-samsung-soc/msg44136.html

I don't get it. The patch you are referring to has a proper "From" field. So please use it as an example.

Quoted 3 lines

I don't want to take any credit out of it. I just re-base on the new kernel.

Perhaps, you would have maintained the authorship !

Quoted 5 lines

Quoted 1 line

I could not test this patch as it meant for exynos5440 boards.

Are you sure? I think the driver is used on almost all of Exynos SoCs (Exynos4, Exynos5250, Exynos542x).

That's correct, as pointed by Krzysztof Kozlowski, the driver is same for Exynos4 and Exynos5 series
of SoCs.

Quoted 11 lines

Untested code should not go to the kernel. Additionally you should mark it as not-tested. Marking such patch as non-tested could help you finding some independent tests (tests performed by someone else).

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up).
3. The patchset must be tested, even after rebasing.

Quoted 10 lines

Unfortunately, I got busy with a different project and lost track of the patches posted upstream.
If it's not too late I can post a rebased version of the patch with previous review comments addressed.

Quoted 3 lines

Best regards,
Krzysztof

Hi All,

I have learned my lesson not to interfere in others work. It will never happen from my side again.

Please accept my apology.

Quoted 2 lines

Hi,

Quoted 17 lines

Quoted 11 lines · Krzysztof Kozlowski

Untested code should not go to the kernel. Additionally you should mark it as not-tested. Marking such patch as non-tested could help you finding some independent tests (tests performed by someone else).

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up).
3. The patchset must be tested, even after rebasing.

Quoted 10 lines

Unfortunately, I got busy with a different project and lost track of the patches posted upstream.
If it's not too late I can post a rebased version of the patch with previous review comments addressed.

Quoted 3 lines

Best regards,
Krzysztof

Hi All,

I have learned my lesson not to interfere in others work. It will never happen from my side again.

Please accept my apology.

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up).
3. The patchset must be tested, even after rebasing.

Best regards,
Krzysztof

Hello,

On Mon, Jun 8, 2015 at 7:14 AM, Krzysztof Kozlowski <[email protected]> wrote:

[...]

Quoted 9 lines

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up).
3. The patchset must be tested, even after rebasing.

Agreed with all the points.

Anand,

An easy way to preserve authorship when rebasing patches is to use the git command author option. As an example you can execute the following command:

$ git commit -a -s --author='Vivek Gautam <[email protected]>'

2015-06-08 15:42 GMT+09:00 Javier Martinez Canillas <[email protected]>:

Quoted 25 lines

Hello,

On Mon, Jun 8, 2015 at 7:14 AM, Krzysztof Kozlowski <[email protected]> wrote:

[...]

Quoted 9 lines

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up).
3. The patchset must be tested, even after rebasing.

Agreed with all the points.

Anand,

An easy way to preserve authorship when rebasing patches is to use the git command author option. As an example you can execute the following command:

Quoted 1 line

$ git commit -a -s --author='Vivek Gautam <[email protected]>'

By default "git am" and "git format-patch" preserve the author of a patch so usually this step is not necessary. Unless the patch is applied in a different way... :)

Best regards,
Krzysztof

Quoted 21 lines

Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos.

With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators.

Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working.

Signed-off-by Vivek Gautam <[email protected]>

Signed-off-by Anand Moon <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Alan Stern <[email protected]>

Quoted 5 lines

---
Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

So you just took Vivek's patch along with all the credits... That is not how we usually do this.

I would expect that rebasing a patch won't change the author unless this is fine with Vivek.

Quoted 75 lines

---
 .../devicetree/bindings/usb/exynos-usb.txt         |  2 +
 drivers/usb/host/ehci-exynos.c                     | 55 
+++++++++++++++++++++-
 2 files changed, 56 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/usb/exynos-usb.txt +2 -0

index 9b4dbe3..776fa03 100644
@@ -23,6 +23,8 @@ Required properties:
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
    needs to be pulled up for the bus to be powered.
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
 
 Example:
 

drivers/usb/host/ehci-exynos.c +3 -0

index df538fd..4f8f9d2 100644
@@ -21,6 +21,7 @@
 #include <linux/of_gpio.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 

@@ -45,6 +46,8 @@ static struct hc_driver __read_mostly 
 exynos_ehci_hc_driver;
 struct exynos_ehci_hcd {
 struct clk *clk;
 struct phy *phy[PHY_NUMBER];
+ struct regulator *vdd33;
+ struct regulator *vdd10;
 };
 

#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
*)(hcd_to_ehci(hcd)->priv)

drivers/usb/host/ehci-exynos.c +21 -1

@@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device 
 *pdev)
 
 err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
 if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ehci->vdd33 = devm_regulator_get_optional(&pdev->dev, "vdd33");
+ if (!IS_ERR(exynos_ehci->vdd33)) {
+ err = regulator_enable(exynos_ehci->vdd33);
+ if (err) {
+ dev_err(&pdev->dev,
+ "Failed to enable 3.3V Vdd supply\n");
+ goto fail_regulator1;
+ }
+ }
+
+ exynos_ehci->vdd10 = devm_regulator_get_optional(&pdev->dev, "vdd10");
+ if (!IS_ERR(exynos_ehci->vdd10)) {
+ err = regulator_enable(exynos_ehci->vdd10);
+ if (err) {
+ dev_err(&pdev->dev,
+ "Failed to enable 1.0V Vdd supply\n");
+ goto fail_regulator2;
+ }
+ }
 
 skip_phy:

drivers/usb/host/ehci-exynos.c fail_add_hcd: · line 259

Quoted 6 lines

drivers/usb/host/ehci-exynos.c +3 -0

@@ -231,6 +254,10 @@ fail_add_hcd:
 fail_io:
 clk_disable_unprepare(exynos_ehci->clk);
 fail_clk:
+ regulator_disable(exynos_ehci->vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ehci->vdd33);

if (!IS_ERR()).

Quoted 18 lines

drivers/usb/host/ehci-exynos.c +6 -0

+fail_regulator1:
 usb_put_hcd(hcd);
 return err;
 }

@@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device 
 *pdev)
 
 clk_disable_unprepare(exynos_ehci->clk);
 
+ if (!IS_ERR(exynos_ehci->vdd33))
+ regulator_disable(exynos_ehci->vdd33);
+ if (!IS_ERR(exynos_ehci->vdd10))
+ regulator_disable(exynos_ehci->vdd10);
+
 usb_put_hcd(hcd);
 

return 0;

drivers/usb/host/ehci-exynos.c static int exynos_ehci_suspend(struct device *dev) · line 307

Quoted 8 lines

drivers/usb/host/ehci-exynos.c +5 -0

@@ -268,6 +300,11 @@ static int exynos_ehci_suspend(struct device *dev)
 
 clk_disable_unprepare(exynos_ehci->clk);
 
+ if (!IS_ERR(exynos_ehci->vdd33))
+ regulator_disable(exynos_ehci->vdd33);
+ if (!IS_ERR(exynos_ehci->vdd10))
+ regulator_disable(exynos_ehci->vdd10);
+

Is EHCI a wakeup source? If yes then how disabling regulators during suspend affects waking up process?

From my knowledge of Exynos5 USB controller, EHCI could not be used as the

Best regards,
Krzysztof