fix HCD PHY suspend handling

PATCH Superseded Martin Blumenstingl 3 participants 7 messages Mar 27, 2018 – Apr 5, 2018

Subsystems (3)

USB Arm/Amlogic Meson SoC support Arm MediaTek

lore

Share & tools

lore

Martin Blumenstingl

author reviewer

2018-03-27 21:26 UTC #0 lore raw

v4 cover fix HCD PHY suspend handling

This is a follow-up to my previous series "initialize (multiple) PHYs for a HCD": [0].

Roger Quadros reported [1] that it "is breaking low power cases on TI SoCs when USB is in host mode". He further explains that "Not doing the phy_exit() here [when entering suspend] leaves the clocks enabled on our SoC and we're no longer able to reach low power states on system suspend."
Chunfeng Yun from Mediatek noted [2] that we cannot unconditionally call phy_exit while entering system suspend, because this would "disconnect plugged devices on MTK platforms, due to re-initialize u2 phys when resume"

In the discussion (which followed Roger's bug report: [1]) Roger, Chunfeng and me came to the conclusion that we can fix suspend on the TI SoCs without breaking it on the Mediatek SoCs by extending the suspend and resume code in usb/core/phy.c by checking whether the USB controller can wake up the system (which is the case for the Mediatek MTU3 controller, but now for the dwc3 controller used on the TI SoCs):
- if the controller can wake up the system (Mediatek MTU3 use-case) we only call usb_phy_roothub_power_off (which calls phy_power_off) when entering system suspend
- if the controller however cannot wake up the system (dwc3 on TI SoCs) we additionally call usb_phy_roothub_exit (which calls phy_exit) when entering system suspend
- (we undo the previous steps during system resume)

The goal of this series is to fix the issue reported by Roger without breaking suspend/resume on the Mediatek SoCs.
Since I neither have a TI nor a Mediatek device I am sending this as RFC. I have tested it on an Amlogic Meson GXM board (Khadas VIM2) which does NOT support suspend/resume yet.

this should be applied on top of [3] "usb: core: phy: fix return value of usb_phy_roothub_exit()" (even though there's no strict dependency, this is the order I wrote the patches in).

changes since RFC v3 at [6]:
- added Chunfeng Yun's Tested-by and Roger Quadros' Reviewed-by (thank you!)
- dropped RFC prefix

changes since RFC v2 at [5]:
- add missing INIT_LIST_HEAD call in usb_phy_roothub_add_phy (affects patch #1 - spotted by Roger Quadros, thank you!)
- fixed swapped conditions using device_may_wakeup() in usb_phy_roothub_resume because we need to call usb_phy_roothub_init if the controller cannot wake up the device (affects patch #2, spotted by Chunfeng Yun, thank you!)
- simplified the error condition to "undo" usb_phy_roothub_init if usb_phy_roothub_power_on failed in usb_phy_roothub_resume (suggested by Chunfeng Yun)
- updated the commit message (using Roger's wording) because (quote from Roger "it doesn't prevent the system from entering suspend but just prevents the system from reaching lowest power levels in the suspend state."

Changes since RFC v1 (blob attachments) at [4]:
- use device_may_wakeup instead of device_can_wakeup as suggested by Roger Quadros
- use the controller device from hcd->self.controller as suggested by Chunfeng Yun
- compile time fixes thanks to Roger Quadros
- if usb_phy_roothub_power_on in usb_phy_roothub_resume failes then we now call usb_phy_roothub_exit to keep the PHYs in the correct state if usb_phy_roothub_resume partially failed

[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006599.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006737.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006758.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006819.html
[4] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006794.html
[5] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006820.html
[6] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006847.html

Martin Blumenstingl (2):
usb: core: split usb_phy_roothub_{init,alloc}
usb: core: use phy_exit during suspend if wake up is not supported

 drivers/usb/core/hcd.c | 18 +++++++----
 drivers/usb/core/phy.c | 88 +++++++++++++++++++++++++++++++++++---------------
 drivers/usb/core/phy.h |  9 +++++-
 3 files changed, 82 insertions(+), 33 deletions(-)

Signature · 1 line

2.16.3

Martin Blumenstingl

author reviewer

2018-03-27 21:26 UTC #1 lore raw

PATCH v4 1/2 usb: core: split usb_phy_roothub_{init, alloc}

Before this patch usb_phy_roothub_init served two purposes (from a caller's point of view - like hcd.c):
- parsing the PHYs and allocating the list entries
- calling phy_init on each list entry

While this worked so far it has one disadvantage: if we need to call phy_init for each PHY instance then the existing code cannot be re-used. Solve this by splitting off usb_phy_roothub_alloc which only parses the PHYs and allocates the list entries.
usb_phy_roothub_init then gets a struct usb_phy_roothub and only calls phy_init on each PHY instance (along with the corresponding cleanup if that failed somewhere).

This is a preparation step for adding proper suspend support for some hardware that requires phy_exit to be called during suspend and phy_init to be called during resume.

Signed-off-by Martin Blumenstingl <[email protected]>

Tested-by Chunfeng Yun <[email protected]>

Reviewed-by Roger Quadros <[email protected]>

---
 drivers/usb/core/hcd.c | 10 +++++++---
 drivers/usb/core/phy.c | 53 +++++++++++++++++++++++++-------------------------
 drivers/usb/core/phy.h |  4 +++-
 3 files changed, 37 insertions(+), 30 deletions(-)

drivers/usb/core/hcd.c +7 -3

index 777036ae6367..15b0418e3b6a 100644
@@ -2758,12 +2758,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
 	}
 
 	if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
-		hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
+		hcd->phy_roothub = usb_phy_roothub_alloc(hcd->self.sysdev);
 		if (IS_ERR(hcd->phy_roothub)) {
 			retval = PTR_ERR(hcd->phy_roothub);
-			goto err_phy_roothub_init;
+			goto err_phy_roothub_alloc;
 		}
 
+		retval = usb_phy_roothub_init(hcd->phy_roothub);
+		if (retval)
+			goto err_phy_roothub_alloc;
+
 		retval = usb_phy_roothub_power_on(hcd->phy_roothub);
 		if (retval)
 			goto err_usb_phy_roothub_power_on;

@@ -2936,7 +2940,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
 	usb_phy_roothub_power_off(hcd->phy_roothub);
 err_usb_phy_roothub_power_on:
 	usb_phy_roothub_exit(hcd->phy_roothub);
-err_phy_roothub_init:
+err_phy_roothub_alloc:
 	if (hcd->remove_phy && hcd->usb_phy) {
 		usb_phy_shutdown(hcd->usb_phy);
 		usb_put_phy(hcd->usb_phy);

drivers/usb/core/phy.c +27 ~~-26~~

96 lines not on this page · raw message

drivers/usb/core/phy.h +3 -1

index 6fde59bfbff8..eb31253201ad 100644
@@ -1,6 +1,8 @@
 struct usb_phy_roothub;
 
-struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev);
+struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *dev);
+
+int usb_phy_roothub_init(struct usb_phy_roothub *phy_roothub);
 int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
 
 int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);

Signature · 1 line

2.16.3

Martin Blumenstingl

author reviewer

2018-03-27 21:26 UTC #2 lore raw

PATCH v4 2/2 usb: core: use phy_exit during suspend if wake up is not supported

In reply to Martin Blumenstingl

If the USB controller can wake up the system (which is the case for example with the Mediatek USB3 IP) then we must not call phy_exit during suspend to ensure that the USB controller doesn't have to re-enumerate the devices during resume.
However, if the USB controller cannot wake up the system (which is the case for example on various TI platforms using a dwc3 controller) then we must call phy_exit during suspend. Otherwise the PHY driver keeps the clocks enabled, which prevents the system from reaching the lowest power levels in the suspend state.

Solve this by introducing two new functions in the PHY wrapper which are dedicated to the suspend and resume handling.
If the controller can wake up the system the new usb_phy_roothub_suspend function will simply call usb_phy_roothub_power_off. However, if wake up is not supported by the controller it will also call usb_phy_roothub_exit.
The also new usb_phy_roothub_resume function takes care of calling usb_phy_roothub_init (if the controller can't wake up the system) in addition to usb_phy_roothub_power_on.

Fixes 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")

Fixes 178a0bce05cbc1 ("usb: core: hcd: integrate the PHY wrapper into the HCD core")

Reported-by Roger Quadros <[email protected]>

Signed-off-by Martin Blumenstingl <[email protected]>

Tested-by Chunfeng Yun <[email protected]>

Reviewed-by Roger Quadros <[email protected]>

---
 drivers/usb/core/hcd.c |  8 +++++---
 drivers/usb/core/phy.c | 35 +++++++++++++++++++++++++++++++++++
 drivers/usb/core/phy.h |  5 +++++
 3 files changed, 45 insertions(+), 3 deletions(-)

drivers/usb/core/hcd.c +5 -3

index 15b0418e3b6a..78bae4ecd68b 100644
@@ -2262,7 +2262,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
 		hcd->state = HC_STATE_SUSPENDED;
 
 		if (!PMSG_IS_AUTO(msg))
-			usb_phy_roothub_power_off(hcd->phy_roothub);
+			usb_phy_roothub_suspend(hcd->self.sysdev,
+						hcd->phy_roothub);
 
 		/* Did we race with a root-hub wakeup event? */
 		if (rhdev->do_remote_wakeup) {

@@ -2302,7 +2303,8 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
 	}
 
 	if (!PMSG_IS_AUTO(msg)) {
-		status = usb_phy_roothub_power_on(hcd->phy_roothub);
+		status = usb_phy_roothub_resume(hcd->self.sysdev,
+						hcd->phy_roothub);
 		if (status)
 			return status;
 	}

@@ -2344,7 +2346,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
 		}
 	} else {
 		hcd->state = old_state;
-		usb_phy_roothub_power_off(hcd->phy_roothub);
+		usb_phy_roothub_suspend(hcd->self.sysdev, hcd->phy_roothub);
 		dev_dbg(&rhdev->dev, "bus %s fail, err %d\n",
 				"resume", status);
 		if (status != -ESHUTDOWN)

drivers/usb/core/phy.c +35 -0

index 44f008cda7a8..a39d9bb26a4f 100644
@@ -157,3 +157,38 @@ void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub)
 		phy_power_off(roothub_entry->phy);
 }
 EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
+
+int usb_phy_roothub_suspend(struct device *controller_dev,
+			    struct usb_phy_roothub *phy_roothub)
+{
+	usb_phy_roothub_power_off(phy_roothub);
+
+	/* keep the PHYs initialized so the device can wake up the system */
+	if (device_may_wakeup(controller_dev))
+		return 0;
+
+	return usb_phy_roothub_exit(phy_roothub);
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_suspend);
+
+int usb_phy_roothub_resume(struct device *controller_dev,
+			   struct usb_phy_roothub *phy_roothub)
+{
+	int err;
+
+	/* if the device can't wake up the system _exit was called */
+	if (!device_may_wakeup(controller_dev)) {
+		err = usb_phy_roothub_init(phy_roothub);
+		if (err)
+			return err;
+	}
+
+	err = usb_phy_roothub_power_on(phy_roothub);
+
+	/* undo _init if _power_on failed */
+	if (err && !device_may_wakeup(controller_dev))
+		usb_phy_roothub_exit(phy_roothub);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_resume);

drivers/usb/core/phy.h +5 -0

index eb31253201ad..605555901d44 100644
@@ -7,3 +7,8 @@ int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
 
 int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
 void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);
+
+int usb_phy_roothub_suspend(struct device *controller_dev,
+			    struct usb_phy_roothub *phy_roothub);
+int usb_phy_roothub_resume(struct device *controller_dev,
+			   struct usb_phy_roothub *phy_roothub);

Signature · 1 line

2.16.3

Roger Quadros

2018-04-05 08:47 UTC #3 lore raw

v4 cover fix HCD PHY suspend handling

In reply to Martin Blumenstingl

Greg,

Quoted 76 lines · Martin Blumenstingl

This is a follow-up to my previous series "initialize (multiple) PHYs for a HCD": [0].
Roger Quadros reported [1] that it "is breaking low power cases on TI SoCs when USB is in host mode". He further explains that "Not doing the phy_exit() here [when entering suspend] leaves the clocks enabled on our SoC and we're no longer able to reach low power states on system suspend."
Chunfeng Yun from Mediatek noted [2] that we cannot unconditionally call phy_exit while entering system suspend, because this would "disconnect plugged devices on MTK platforms, due to re-initialize u2 phys when resume"
In the discussion (which followed Roger's bug report: [1]) Roger, Chunfeng and me came to the conclusion that we can fix suspend on the TI SoCs without breaking it on the Mediatek SoCs by extending the suspend and resume code in usb/core/phy.c by checking whether the USB controller can wake up the system (which is the case for the Mediatek MTU3 controller, but now for the dwc3 controller used on the TI SoCs):
- if the controller can wake up the system (Mediatek MTU3 use-case) we only call usb_phy_roothub_power_off (which calls phy_power_off) when entering system suspend
- if the controller however cannot wake up the system (dwc3 on TI SoCs) we additionally call usb_phy_roothub_exit (which calls phy_exit) when entering system suspend
- (we undo the previous steps during system resume)
The goal of this series is to fix the issue reported by Roger without breaking suspend/resume on the Mediatek SoCs.
Since I neither have a TI nor a Mediatek device I am sending this as RFC. I have tested it on an Amlogic Meson GXM board (Khadas VIM2) which does NOT support suspend/resume yet.
this should be applied on top of [3] "usb: core: phy: fix return value of usb_phy_roothub_exit()" (even though there's no strict dependency, this is the order I wrote the patches in).
changes since RFC v3 at [6]:
- added Chunfeng Yun's Tested-by and Roger Quadros' Reviewed-by (thank you!)
- dropped RFC prefix
changes since RFC v2 at [5]:
- add missing INIT_LIST_HEAD call in usb_phy_roothub_add_phy (affects patch #1 - spotted by Roger Quadros, thank you!)
- fixed swapped conditions using device_may_wakeup() in usb_phy_roothub_resume because we need to call usb_phy_roothub_init if the controller cannot wake up the device (affects patch #2, spotted by Chunfeng Yun, thank you!)
- simplified the error condition to "undo" usb_phy_roothub_init if usb_phy_roothub_power_on failed in usb_phy_roothub_resume (suggested by Chunfeng Yun)
- updated the commit message (using Roger's wording) because (quote from Roger "it doesn't prevent the system from entering suspend but just prevents the system from reaching lowest power levels in the suspend state."
Changes since RFC v1 (blob attachments) at [4]:
- use device_may_wakeup instead of device_can_wakeup as suggested by Roger Quadros
- use the controller device from hcd->self.controller as suggested by Chunfeng Yun
- compile time fixes thanks to Roger Quadros
- if usb_phy_roothub_power_on in usb_phy_roothub_resume failes then we now call usb_phy_roothub_exit to keep the PHYs in the correct state if usb_phy_roothub_resume partially failed
[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006599.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006737.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006758.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006819.html
[4] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006794.html
[5] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006820.html
[6] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006847.html

Quoted 3 lines

Martin Blumenstingl (2):
usb: core: split usb_phy_roothub_{init,alloc}
usb: core: use phy_exit during suspend if wake up is not supported

Gentle ping on this one. Without this system suspend/resume is broken on TI platforms.

Quoted 6 lines

 drivers/usb/core/hcd.c | 18 +++++++----
 drivers/usb/core/phy.c | 88 +++++++++++++++++++++++++++++++++++---------------
 drivers/usb/core/phy.h |  9 +++++-
 3 files changed, 82 insertions(+), 33 deletions(-)

Signature · 4 lines

cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Greg KH

maintainer

2018-04-05 13:38 UTC #4 lore raw

v4 cover fix HCD PHY suspend handling

Quoted 79 lines · Roger Quadros

Greg,
Quoted 76 lines · Martin Blumenstingl
This is a follow-up to my previous series "initialize (multiple) PHYs for a HCD": [0].
Roger Quadros reported [1] that it "is breaking low power cases on TI SoCs when USB is in host mode". He further explains that "Not doing the phy_exit() here [when entering suspend] leaves the clocks enabled on our SoC and we're no longer able to reach low power states on system suspend."
Chunfeng Yun from Mediatek noted [2] that we cannot unconditionally call phy_exit while entering system suspend, because this would "disconnect plugged devices on MTK platforms, due to re-initialize u2 phys when resume"
In the discussion (which followed Roger's bug report: [1]) Roger, Chunfeng and me came to the conclusion that we can fix suspend on the TI SoCs without breaking it on the Mediatek SoCs by extending the suspend and resume code in usb/core/phy.c by checking whether the USB controller can wake up the system (which is the case for the Mediatek MTU3 controller, but now for the dwc3 controller used on the TI SoCs):
- if the controller can wake up the system (Mediatek MTU3 use-case) we only call usb_phy_roothub_power_off (which calls phy_power_off) when entering system suspend
- if the controller however cannot wake up the system (dwc3 on TI SoCs) we additionally call usb_phy_roothub_exit (which calls phy_exit) when entering system suspend
- (we undo the previous steps during system resume)
The goal of this series is to fix the issue reported by Roger without breaking suspend/resume on the Mediatek SoCs.
Since I neither have a TI nor a Mediatek device I am sending this as RFC. I have tested it on an Amlogic Meson GXM board (Khadas VIM2) which does NOT support suspend/resume yet.
this should be applied on top of [3] "usb: core: phy: fix return value of usb_phy_roothub_exit()" (even though there's no strict dependency, this is the order I wrote the patches in).
changes since RFC v3 at [6]:
- added Chunfeng Yun's Tested-by and Roger Quadros' Reviewed-by (thank you!)
- dropped RFC prefix
changes since RFC v2 at [5]:
- add missing INIT_LIST_HEAD call in usb_phy_roothub_add_phy (affects patch #1 - spotted by Roger Quadros, thank you!)
- fixed swapped conditions using device_may_wakeup() in usb_phy_roothub_resume because we need to call usb_phy_roothub_init if the controller cannot wake up the device (affects patch #2, spotted by Chunfeng Yun, thank you!)
- simplified the error condition to "undo" usb_phy_roothub_init if usb_phy_roothub_power_on failed in usb_phy_roothub_resume (suggested by Chunfeng Yun)
- updated the commit message (using Roger's wording) because (quote from Roger "it doesn't prevent the system from entering suspend but just prevents the system from reaching lowest power levels in the suspend state."
Changes since RFC v1 (blob attachments) at [4]:
- use device_may_wakeup instead of device_can_wakeup as suggested by Roger Quadros
- use the controller device from hcd->self.controller as suggested by Chunfeng Yun
- compile time fixes thanks to Roger Quadros
- if usb_phy_roothub_power_on in usb_phy_roothub_resume failes then we now call usb_phy_roothub_exit to keep the PHYs in the correct state if usb_phy_roothub_resume partially failed
[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006599.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006737.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006758.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006819.html
[4] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006794.html
[5] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006820.html
[6] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006847.html

Quoted 5 lines

Quoted 3 lines
Martin Blumenstingl (2):
usb: core: split usb_phy_roothub_{init,alloc}
usb: core: use phy_exit during suspend if wake up is not supported
Gentle ping on this one. Without this system suspend/resume is broken on TI platforms.

Sorry, this missed my merge window, I can pick it up after 4.17-rc1 is out.

thanks,

greg k-h

Martin Blumenstingl

author reviewer

2018-04-05 20:08 UTC #5 lore raw

v4 cover fix HCD PHY suspend handling

Hi Greg,

Quoted 80 lines · Greg KH

Quoted 79 lines · Roger Quadros
Greg,
Quoted 76 lines · Martin Blumenstingl
This is a follow-up to my previous series "initialize (multiple) PHYs for a HCD": [0].
Roger Quadros reported [1] that it "is breaking low power cases on TI SoCs when USB is in host mode". He further explains that "Not doing the phy_exit() here [when entering suspend] leaves the clocks enabled on our SoC and we're no longer able to reach low power states on system suspend."
Chunfeng Yun from Mediatek noted [2] that we cannot unconditionally call phy_exit while entering system suspend, because this would "disconnect plugged devices on MTK platforms, due to re-initialize u2 phys when resume"
In the discussion (which followed Roger's bug report: [1]) Roger, Chunfeng and me came to the conclusion that we can fix suspend on the TI SoCs without breaking it on the Mediatek SoCs by extending the suspend and resume code in usb/core/phy.c by checking whether the USB controller can wake up the system (which is the case for the Mediatek MTU3 controller, but now for the dwc3 controller used on the TI SoCs):
- if the controller can wake up the system (Mediatek MTU3 use-case) we only call usb_phy_roothub_power_off (which calls phy_power_off) when entering system suspend
- if the controller however cannot wake up the system (dwc3 on TI SoCs) we additionally call usb_phy_roothub_exit (which calls phy_exit) when entering system suspend
- (we undo the previous steps during system resume)
The goal of this series is to fix the issue reported by Roger without breaking suspend/resume on the Mediatek SoCs.
Since I neither have a TI nor a Mediatek device I am sending this as RFC. I have tested it on an Amlogic Meson GXM board (Khadas VIM2) which does NOT support suspend/resume yet.
this should be applied on top of [3] "usb: core: phy: fix return value of usb_phy_roothub_exit()" (even though there's no strict dependency, this is the order I wrote the patches in).
changes since RFC v3 at [6]:
- added Chunfeng Yun's Tested-by and Roger Quadros' Reviewed-by (thank you!)
- dropped RFC prefix
changes since RFC v2 at [5]:
- add missing INIT_LIST_HEAD call in usb_phy_roothub_add_phy (affects patch #1 - spotted by Roger Quadros, thank you!)
- fixed swapped conditions using device_may_wakeup() in usb_phy_roothub_resume because we need to call usb_phy_roothub_init if the controller cannot wake up the device (affects patch #2, spotted by Chunfeng Yun, thank you!)
- simplified the error condition to "undo" usb_phy_roothub_init if usb_phy_roothub_power_on failed in usb_phy_roothub_resume (suggested by Chunfeng Yun)
- updated the commit message (using Roger's wording) because (quote from Roger "it doesn't prevent the system from entering suspend but just prevents the system from reaching lowest power levels in the suspend state."
Changes since RFC v1 (blob attachments) at [4]:
- use device_may_wakeup instead of device_can_wakeup as suggested by Roger Quadros
- use the controller device from hcd->self.controller as suggested by Chunfeng Yun
- compile time fixes thanks to Roger Quadros
- if usb_phy_roothub_power_on in usb_phy_roothub_resume failes then we now call usb_phy_roothub_exit to keep the PHYs in the correct state if usb_phy_roothub_resume partially failed
[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006599.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006737.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006758.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006819.html
[4] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006794.html
[5] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006820.html
[6] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006847.html

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
Martin Blumenstingl (2):
usb: core: split usb_phy_roothub_{init,alloc}
usb: core: use phy_exit during suspend if wake up is not supported
Gentle ping on this one. Without this system suspend/resume is broken on TI platforms.
Sorry, this missed my merge window, I can pick it up after 4.17-rc1 is out.

do you want me to re-send this based on v4.17-rc1 (once it's out)? I can re-spin this series so it includes:
a) "usb: core: phy: fix return value of usb_phy_roothub_exit()" [0]
b) the two patches from this series (they apply on top of [0])
c) a missing forward declaration as well as a missing include guard (and a SPDX-License-Identifier) as suggested by Masahiro Yamada in [1]

(patches for c) are neither written nor posted yet, but they're minor and I can prepare and test them during the weekend)

just let me know whether you would like to take these three series individually or whether you would like them all in one "usb: core:
phy: fixes for v4.17" series

Regards
Martin

[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006819.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2018-April/006975.html

Greg KH

maintainer

2018-04-05 20:13 UTC #6 lore raw

v4 cover fix HCD PHY suspend handling

Quoted 98 lines · Martin Blumenstingl

Hi Greg,
Quoted 80 lines · Greg KH
Quoted 79 lines · Roger Quadros
Greg,
Quoted 76 lines · Martin Blumenstingl
This is a follow-up to my previous series "initialize (multiple) PHYs for a HCD": [0].
Roger Quadros reported [1] that it "is breaking low power cases on TI SoCs when USB is in host mode". He further explains that "Not doing the phy_exit() here [when entering suspend] leaves the clocks enabled on our SoC and we're no longer able to reach low power states on system suspend."
Chunfeng Yun from Mediatek noted [2] that we cannot unconditionally call phy_exit while entering system suspend, because this would "disconnect plugged devices on MTK platforms, due to re-initialize u2 phys when resume"
In the discussion (which followed Roger's bug report: [1]) Roger, Chunfeng and me came to the conclusion that we can fix suspend on the TI SoCs without breaking it on the Mediatek SoCs by extending the suspend and resume code in usb/core/phy.c by checking whether the USB controller can wake up the system (which is the case for the Mediatek MTU3 controller, but now for the dwc3 controller used on the TI SoCs):
- if the controller can wake up the system (Mediatek MTU3 use-case) we only call usb_phy_roothub_power_off (which calls phy_power_off) when entering system suspend
- if the controller however cannot wake up the system (dwc3 on TI SoCs) we additionally call usb_phy_roothub_exit (which calls phy_exit) when entering system suspend
- (we undo the previous steps during system resume)
The goal of this series is to fix the issue reported by Roger without breaking suspend/resume on the Mediatek SoCs.
Since I neither have a TI nor a Mediatek device I am sending this as RFC. I have tested it on an Amlogic Meson GXM board (Khadas VIM2) which does NOT support suspend/resume yet.
this should be applied on top of [3] "usb: core: phy: fix return value of usb_phy_roothub_exit()" (even though there's no strict dependency, this is the order I wrote the patches in).
changes since RFC v3 at [6]:
- added Chunfeng Yun's Tested-by and Roger Quadros' Reviewed-by (thank you!)
- dropped RFC prefix
changes since RFC v2 at [5]:
- add missing INIT_LIST_HEAD call in usb_phy_roothub_add_phy (affects patch #1 - spotted by Roger Quadros, thank you!)
- fixed swapped conditions using device_may_wakeup() in usb_phy_roothub_resume because we need to call usb_phy_roothub_init if the controller cannot wake up the device (affects patch #2, spotted by Chunfeng Yun, thank you!)
- simplified the error condition to "undo" usb_phy_roothub_init if usb_phy_roothub_power_on failed in usb_phy_roothub_resume (suggested by Chunfeng Yun)
- updated the commit message (using Roger's wording) because (quote from Roger "it doesn't prevent the system from entering suspend but just prevents the system from reaching lowest power levels in the suspend state."
Changes since RFC v1 (blob attachments) at [4]:
- use device_may_wakeup instead of device_can_wakeup as suggested by Roger Quadros
- use the controller device from hcd->self.controller as suggested by Chunfeng Yun
- compile time fixes thanks to Roger Quadros
- if usb_phy_roothub_power_on in usb_phy_roothub_resume failes then we now call usb_phy_roothub_exit to keep the PHYs in the correct state if usb_phy_roothub_resume partially failed
[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006599.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006737.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006758.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006819.html
[4] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006794.html
[5] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006820.html
[6] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006847.html
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Martin Blumenstingl (2):
usb: core: split usb_phy_roothub_{init,alloc}
usb: core: use phy_exit during suspend if wake up is not supported
Gentle ping on this one. Without this system suspend/resume is broken on TI platforms.
Sorry, this missed my merge window, I can pick it up after 4.17-rc1 is out.
do you want me to re-send this based on v4.17-rc1 (once it's out)? I can re-spin this series so it includes:
a) "usb: core: phy: fix return value of usb_phy_roothub_exit()" [0]
b) the two patches from this series (they apply on top of [0])
c) a missing forward declaration as well as a missing include guard (and a SPDX-License-Identifier) as suggested by Masahiro Yamada in [1]

Quoted 6 lines

(patches for c) are neither written nor posted yet, but they're minor and I can prepare and test them during the weekend)
just let me know whether you would like to take these three series individually or whether you would like them all in one "usb: core:
phy: fixes for v4.17" series

Yes, please respin and resend.

thanks,

greg k-h