Entering KSLEEP=0 after triggering OTG Host is broken

Ron · April 30, 2025, 2:08pm

Hello,
I am trying to make a WP7607 go into sleep mode with an OTG ethernet controller connected to it.
I have tried a whole bunch of things, and at last the sequence that I found that takes me ever so close to success is the following:
0. I have recompiled the kernel, enabling debug user control of the OTG mode (host and peripheral) by overriding the following in the WP7607 device tree.

&soc {
    usb_otg: usb@78d9000 {
        qcom,hsusb-otg-otg-control = <3>; /* User control */
        //qcom,hsusb-otg-delay-lpm;
    };
};

This lets me control via /sys/kernel/debug/msm_otg/mode the OTG configuration as follows.

I plug my OTG ethernet controller/flash drive/keyboard or nothing at all and turn on my device (This also works on the reference MangOH Red board)
I check via lsusb that no Bus 001 Device 001: ID 1d6b:0002 is shown.
I set it on peripheral mode, by cutting VBUS power and by sending echo -n peripheral > /sys/kernel/debug/msm_otg/mode; sleep 1; cat /sys/kernel/debug/msm_otg/mode, then I give VBUS power again.
The kernel prints me back this:

[   77.035243] msm_otg 78d9000.usb: Could not get usb power_supply
[   77.035284] msm_otg 78d9000.usb: Could not get usb power_supply
[   77.039999] msm_otg 78d9000.usb: Could not get usb power_supply
[   77.040010] msm_otg 78d9000.usb: Could not get usb power_supply

I send AT+KSLEEP=0, the device sleeps as expected.
I wake up the device. It does so as expected.
I put the device on host mode, by unpowering VBUS, then echo -n host > /sys/kernel/debug/msm_otg/mode; sleep 1; cat /sys/kernel/debug/msm_otg/mode and giving VBUS power again.
The kernel prints me this:

[  264.151050] usb usb1: runtime PM trying to activate child device usb1 but parent (msm_hsusb_host) is not active

I check via lsusb that both the ID 1d6b:0002 and the OTG device is present.
If I go to sleep at this stage, the OTG device prevents me from going, as expected.
I turn off the VBUS power again, get back into echo -n peripheral > /sys/kernel/debug/msm_otg/mode; sleep 1; cat /sys/kernel/debug/msm_otg/mode .
When the device goes to sleep now, it will enter a strange state, where the CPU is actually sleeping but I still get echo loop from the serial UART interface. If I then try to wake up with an interrupt, the device gets stuck until I unpower and power back the device.

To make it short, every time the device enters host mode and gets back into peripheral mode, no matter if an OTG device is plugged or not / the VBUS has the power cut or not / If I go to sleep during each stage or skip it. Nothing I do makes an obvious difference, it all leads to a total block of the CPU, unless I reboot the device, then the device is able to sleep. I suspect that something is not configured back correctly in kernel/drivers/usb/phy/phy-msm-usb.c when hopping between work modes.
Thank you for your help.

jyijyi · April 30, 2025, 2:23pm

Is problem happening in both r16.3 and r17？

Btw, for r17, you need to apply the patch for usb otg

Ron · April 30, 2025, 2:35pm

Thank you for your reply. I forgot to add that I was already using the patch that you linked.

diff --git a/arch/arm64/boot/dts/qcom/mdm9607-swi.dtsi b/arch/arm64/boot/dts/qcom/mdm9607-swi.dtsi
index 9a5644ec4dea..815b3305ffd9 100644
--- a/arch/arm64/boot/dts/qcom/mdm9607-swi.dtsi
+++ b/arch/arm64/boot/dts/qcom/mdm9607-swi.dtsi
@@ -162,9 +162,6 @@
 	qcom,hsusb-otg-phy-init-seq =
 		<0x44 0x80 0x30 0x81 0x24 0x82 0x13 0x83 0xffffffff>;
 	/delete-property/ vbus_otg-supply;
-	/delete-property/ qcom,usbid-gpio;
-	/delete-property/ pinctrl-names;
-	/delete-property/ pinctrl-0;
 };

 &hsic_host {
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 94a2e443ec47..55027522e561 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -4325,8 +4325,8 @@ static int msm_otg_probe(struct platform_device *pdev)
 	phy->set_power = msm_otg_set_power;
 	phy->set_suspend = msm_otg_set_suspend;
 	phy->dbg_event = msm_otg_dbg_log_event;
-	phy->vbus_nb.notifier_call = msm_otg_vbus_notifier;
-	phy->id_nb.notifier_call = msm_otg_id_notifier;
+	// phy->vbus_nb.notifier_call = msm_otg_vbus_notifier;
+	// phy->id_nb.notifier_call = msm_otg_id_notifier;

 	phy->io_ops = &msm_otg_io_ops;

Without applying this patch, even if I’m in peripheral mode, if I got an OTG device connected, the device will never enter sleep mode, but it doesn’t affect the issue that I’m encountering, switching from host mode to peripheral mode breaks sleep mode, and the CPU never wakes, unless I reboot via command or I unplug the device.
In regards of R16.3, I cannot use it, since I’m relying on the “newer” 4.14 kernel for some of my device functionalities.
Thank you for your time.

jyijyi · April 30, 2025, 2:37pm

I am thinking that if this is regression bug in r17 …

Ron · April 30, 2025, 2:45pm

If there are tests to do and patches you want me to apply, I will be more than happy to assist and help you. I’m not particularly skilled in C, but I suspect there’s something that gets configured by kernel/drivers/usb/phy/phy-msm-usb.c when hopping into host mode and that it doesn’t go back as it should when going back into peripheral mode, causing this mayhem.

jyijyi · April 30, 2025, 3:19pm

I mean if it works in r16.3, that means the bug is introduced when porting to kernel 4.14, probably that can give a clue

Btw, can you cut the vbus power by hardware instead of using the command?

Ron · April 30, 2025, 3:37pm

Thank you for your reply. I was already unpowering VBUS via hardware, I am not aware of a method to cut power to VBUS via a console command.
Regarding R16.3, I guess I can download it, apply the manual OTG control patch in the first post and try if it works there. I want to reiterate that, even if OTG sleep works there, downgrading to R16.3 is not a solution to my issue, since I need most of the changes that were made in the 4.14 Kernel.

jyijyi · May 1, 2025, 12:07am

What if not setting “peripheral” but just cut powerof vbus?
Will that be the same as as removing device from the uab otg directly?

I am thinking you can start with usb thumb drive
Once remove the drive physically, can the module go to sleep mode?
And then if you cc onbect the usb thumb drive after that, can it be working?

Btw, since your module now in r17, it cannot go back to r16.3.
You need to take another module to test

jyijyi · May 2, 2025, 7:41am

I found that I have similar test before in FW R16:

At that time, in order to go to sleep mode, I need to first connect to a PC host so that /sys/kernel/debug/msm_otg/otg_state from a_host to b_peripheral

(BTW, I saw you just echo host / peripheral, but not sure if it should be a_host / b_peripheral)

Lastly, have you tried to use the USB port in mangoh red board which is using HSIC instead of using the USB OTG cable like this in mangoh green board?

jyijyi · May 4, 2025, 4:35am

I have just tried to use the USB port in mangoh red board which is using HSIC like the picture above with FW R16.3, module can go to sleep mode when connected with USB thumb drive.
So you might double check whether you can use this HSIC USB port.

Ron · May 5, 2025, 9:34am

Hi, sorry for the late response, the company was on break.
I took a step back and reassessed if the bug was caused by the manual hsusb-otg-otg-control, so I asked my colleagues for a OTG cable with a switch on the ID pin, so that I could control the OTG status without unplugging cables. I’ve tested this both on R16.3 and R17, and as expected, nothing changes on R17, locking up on sleep after plugging ID to host mode and unplugging it back, while on R16.3 it works, after going to sleep mode the device is perfectly able to wake up again without a hitch. As for the modem datasheet specs, VBUS needs to be cut or applied every time the ID pin is acted upon. This happens by using a NOT gate on the USB_ID pin, as shown. So, if an OTG adapter is present, it will be detected and the VBUS voltage will be applied, otherwise, it will be removed.

To recap what the bug on R17 entails:

I plug my cable, with OTG ID on low state. The device is happy on sleep and resume.
I unpower VBUS and put ID on high, then I power VBUS back on. This makes the OTG device appear alongside the USB 2.0 root hub.
I unpower VBUS, switch ID back on low (and optionally put VBUS back on). When I tell the device to go in KSLEEP=0, the CPU will halt, the serial will still send local echo, and when I wake it up via GPIO the CPU won’t wake up anymore, needing a hard poweroff.
I have also tried plugging the WP7607 back to a PC before KSLEEPing, but nothing changes.
In regards to the HSIC port, I unfortunately can’t use without a whole board redesign, our device microUSB port is the same as the MangOH Red’s CF3 microUSB port.
I wish I could use R16.3, but I need to use the newer device drivers and kernel support that R17 comes with.

jyijyi · May 5, 2025, 9:59am

Is that you don’t need to change anything in R16.3?
Strange that i remember i cannot make it sleep unless after connecting to PC in R16.3…

Anyway, you need to contact Sierra FAE if you confirm this is regression bug in r17

Topic		Replies	Views
WP7607-1 KSLEEP doesnt work WP Series	0	456	May 24, 2019
Enable the hibernation mode in wp7608 WP Series	32	1597	July 1, 2019
Eth0 is not working after R17 upgrade - WP76xx IoT Modules	9	402	October 3, 2023
WP76 Sleep Mode WP Series	1	908	June 10, 2021
Octave WP7702 UART USP & ORP - how to disable "autosleep" on WP7702 UARTS Octave	5	922	June 18, 2020

Entering KSLEEP=0 after triggering OTG Host is broken

Related topics