| Message ID | 20250131100630.342995-1-chenhuacai@loongson.cn |
|---|---|
| State | New |
| Headers | show |
| Series | USB: core: Enable root_hub's remote wakeup for wakeup sources | expand |
Hi, Greg, On Fri, Jan 31, 2025 at 6:49 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote: > > Now we only enable the remote wakeup function for the USB wakeup source > > itself at usb_port_suspend(). But on pre-XHCI controllers this is not > > enough to enable the S3 wakeup function for USB keyboards, so we also > > enable the root_hub's remote wakeup (and disable it on error). Frankly > > this is unnecessary for XHCI, but enable it unconditionally make code > > simple and seems harmless. > > > > Cc: stable@vger.kernel.org > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> > > What commit id does this fix? It seems this problem exist from the first place (at least >=4.19). > > > --- > > drivers/usb/core/hub.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index c3f839637cb5..efd6374ccd1d 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -3480,6 +3480,7 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) > > if (PMSG_IS_AUTO(msg)) > > goto err_wakeup; > > } > > + usb_enable_remote_wakeup(udev->bus->root_hub); > > } > > > > /* disable USB2 hardware LPM */ > > @@ -3543,8 +3544,10 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) > > /* Try to enable USB2 hardware LPM again */ > > usb_enable_usb2_hardware_lpm(udev); > > > > - if (udev->do_remote_wakeup) > > + if (udev->do_remote_wakeup) { > > (void) usb_disable_remote_wakeup(udev); > > + (void) usb_disable_remote_wakeup(udev->bus->root_hub); > > This feels wrong, what about all of the devices inbetween this device > and the root hub? Yes, if there are other hubs between the root hub and keyboard, this patch still cannot fix the wakeup problem. I have tried to enable every hub in the link, but failed. Because I found many hubs lost power during suspend. So this patch can only fixes the most usual cases. Huacai > > thanks, > > greg k-h
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote: > Now we only enable the remote wakeup function for the USB wakeup source > itself at usb_port_suspend(). But on pre-XHCI controllers this is not > enough to enable the S3 wakeup function for USB keyboards, Why do you say this? It was enough on my system with an EHCI/UHCI controller when I wrote that code. What hardware do you have that isn't working? > so we also > enable the root_hub's remote wakeup (and disable it on error). Frankly > this is unnecessary for XHCI, but enable it unconditionally make code > simple and seems harmless. This does not make sense. For hubs (including root hubs), enabling remote wakeup means that the hub will generate a wakeup request when there is a connect, disconnect, or over-current change. That's not what you want to do, is it? And it has nothing to do with how the hub handles wakeup requests received from downstream devices. You need to explain what's going on here in much more detail. What exactly is going wrong, and why? What is the hardware actually doing, as compared to what we expect it to do? Alan Stern
Hi, Alan, On Fri, Jan 31, 2025 at 11:17 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote: > > Now we only enable the remote wakeup function for the USB wakeup source > > itself at usb_port_suspend(). But on pre-XHCI controllers this is not > > enough to enable the S3 wakeup function for USB keyboards, > > Why do you say this? It was enough on my system with an EHCI/UHCI > controller when I wrote that code. What hardware do you have that isn't > working? > > > so we also > > enable the root_hub's remote wakeup (and disable it on error). Frankly > > this is unnecessary for XHCI, but enable it unconditionally make code > > simple and seems harmless. > > This does not make sense. For hubs (including root hubs), enabling > remote wakeup means that the hub will generate a wakeup request when > there is a connect, disconnect, or over-current change. That's not what > you want to do, is it? And it has nothing to do with how the hub > handles wakeup requests received from downstream devices. > > You need to explain what's going on here in much more detail. What > exactly is going wrong, and why? What is the hardware actually doing, > as compared to what we expect it to do? OK, let me tell a long story: At first, someone reported that on Loongson platform we cannot wake up S3 with a USB keyboard, but no problem on x86. At that time we thought this was a platform-specific problem. After that we have done many experiments, then we found that if the keyboard is connected to a XHCI controller, it can wake up, but cannot wake up if it is connected to a non-XHCI controller, no matter on x86 or on Loongson. We are not familiar with USB protocol, this is just observed from experiments. You are probably right that enabling remote wakeup on a hub means it can generate wakeup requests rather than forward downstream devices' requests. But from experiments we found that if we enable the "wakeup" knob of the root_hub via sysfs, then a keyboard becomes able to wake up S3 (for non-XHCI controllers). So we guess that the enablement also enables forwarding. So maybe this is an implementation-specific problem (but most implementations have problems)? This patch itself just emulates the enablement of root_hub's remote wakeup automatically (then we needn't operate on sysfs). Huacai > > Alan Stern
On Sat, Feb 01, 2025 at 02:42:43PM +0800, Huacai Chen wrote: > Hi, Alan, > > On Fri, Jan 31, 2025 at 11:17 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > > > On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote: > > > Now we only enable the remote wakeup function for the USB wakeup source > > > itself at usb_port_suspend(). But on pre-XHCI controllers this is not > > > enough to enable the S3 wakeup function for USB keyboards, > > > > Why do you say this? It was enough on my system with an EHCI/UHCI > > controller when I wrote that code. What hardware do you have that isn't > > working? > > > > > so we also > > > enable the root_hub's remote wakeup (and disable it on error). Frankly > > > this is unnecessary for XHCI, but enable it unconditionally make code > > > simple and seems harmless. > > > > This does not make sense. For hubs (including root hubs), enabling > > remote wakeup means that the hub will generate a wakeup request when > > there is a connect, disconnect, or over-current change. That's not what > > you want to do, is it? And it has nothing to do with how the hub > > handles wakeup requests received from downstream devices. > > > > You need to explain what's going on here in much more detail. What > > exactly is going wrong, and why? What is the hardware actually doing, > > as compared to what we expect it to do? > OK, let me tell a long story: > > At first, someone reported that on Loongson platform we cannot wake up > S3 with a USB keyboard, but no problem on x86. At that time we thought > this was a platform-specific problem. > > After that we have done many experiments, then we found that if the > keyboard is connected to a XHCI controller, it can wake up, but cannot > wake up if it is connected to a non-XHCI controller, no matter on x86 > or on Loongson. We are not familiar with USB protocol, this is just > observed from experiments. > > You are probably right that enabling remote wakeup on a hub means it > can generate wakeup requests rather than forward downstream devices' > requests. But from experiments we found that if we enable the "wakeup" > knob of the root_hub via sysfs, then a keyboard becomes able to wake > up S3 (for non-XHCI controllers). So we guess that the enablement also > enables forwarding. So maybe this is an implementation-specific > problem (but most implementations have problems)? > > This patch itself just emulates the enablement of root_hub's remote > wakeup automatically (then we needn't operate on sysfs). I'll run some experiments on my system. Maybe you're right about the problem, but your proposed solution looks wrong. Alan Stern
On Sun, Feb 2, 2025 at 12:55 AM Alan Stern <stern@rowland.harvard.edu> wrote: > > On Sat, Feb 01, 2025 at 02:42:43PM +0800, Huacai Chen wrote: > > Hi, Alan, > > > > On Fri, Jan 31, 2025 at 11:17 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > > On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote: > > > > Now we only enable the remote wakeup function for the USB wakeup source > > > > itself at usb_port_suspend(). But on pre-XHCI controllers this is not > > > > enough to enable the S3 wakeup function for USB keyboards, > > > > > > Why do you say this? It was enough on my system with an EHCI/UHCI > > > controller when I wrote that code. What hardware do you have that isn't > > > working? > > > > > > > so we also > > > > enable the root_hub's remote wakeup (and disable it on error). Frankly > > > > this is unnecessary for XHCI, but enable it unconditionally make code > > > > simple and seems harmless. > > > > > > This does not make sense. For hubs (including root hubs), enabling > > > remote wakeup means that the hub will generate a wakeup request when > > > there is a connect, disconnect, or over-current change. That's not what > > > you want to do, is it? And it has nothing to do with how the hub > > > handles wakeup requests received from downstream devices. > > > > > > You need to explain what's going on here in much more detail. What > > > exactly is going wrong, and why? What is the hardware actually doing, > > > as compared to what we expect it to do? > > OK, let me tell a long story: > > > > At first, someone reported that on Loongson platform we cannot wake up > > S3 with a USB keyboard, but no problem on x86. At that time we thought > > this was a platform-specific problem. > > > > After that we have done many experiments, then we found that if the > > keyboard is connected to a XHCI controller, it can wake up, but cannot > > wake up if it is connected to a non-XHCI controller, no matter on x86 > > or on Loongson. We are not familiar with USB protocol, this is just > > observed from experiments. > > > > You are probably right that enabling remote wakeup on a hub means it > > can generate wakeup requests rather than forward downstream devices' > > requests. But from experiments we found that if we enable the "wakeup" > > knob of the root_hub via sysfs, then a keyboard becomes able to wake > > up S3 (for non-XHCI controllers). So we guess that the enablement also > > enables forwarding. So maybe this is an implementation-specific > > problem (but most implementations have problems)? > > > > This patch itself just emulates the enablement of root_hub's remote > > wakeup automatically (then we needn't operate on sysfs). > > I'll run some experiments on my system. Maybe you're right about the > problem, but your proposed solution looks wrong. OK, I'm glad to see a better solution. :) Huacai > > Alan Stern
On Sat, Feb 01, 2025 at 11:55:03AM -0500, Alan Stern wrote: > On Sat, Feb 01, 2025 at 02:42:43PM +0800, Huacai Chen wrote: > > Hi, Alan, > > > > On Fri, Jan 31, 2025 at 11:17 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > > On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote: > > > > Now we only enable the remote wakeup function for the USB wakeup source > > > > itself at usb_port_suspend(). But on pre-XHCI controllers this is not > > > > enough to enable the S3 wakeup function for USB keyboards, > > > > > > Why do you say this? It was enough on my system with an EHCI/UHCI > > > controller when I wrote that code. What hardware do you have that isn't > > > working? > > > > > > > so we also > > > > enable the root_hub's remote wakeup (and disable it on error). Frankly > > > > this is unnecessary for XHCI, but enable it unconditionally make code > > > > simple and seems harmless. > > > > > > This does not make sense. For hubs (including root hubs), enabling > > > remote wakeup means that the hub will generate a wakeup request when > > > there is a connect, disconnect, or over-current change. That's not what > > > you want to do, is it? And it has nothing to do with how the hub > > > handles wakeup requests received from downstream devices. > > > > > > You need to explain what's going on here in much more detail. What > > > exactly is going wrong, and why? What is the hardware actually doing, > > > as compared to what we expect it to do? > > OK, let me tell a long story: > > > > At first, someone reported that on Loongson platform we cannot wake up > > S3 with a USB keyboard, but no problem on x86. At that time we thought > > this was a platform-specific problem. > > > > After that we have done many experiments, then we found that if the > > keyboard is connected to a XHCI controller, it can wake up, but cannot > > wake up if it is connected to a non-XHCI controller, no matter on x86 > > or on Loongson. We are not familiar with USB protocol, this is just > > observed from experiments. > > > > You are probably right that enabling remote wakeup on a hub means it > > can generate wakeup requests rather than forward downstream devices' > > requests. But from experiments we found that if we enable the "wakeup" > > knob of the root_hub via sysfs, then a keyboard becomes able to wake > > up S3 (for non-XHCI controllers). So we guess that the enablement also > > enables forwarding. So maybe this is an implementation-specific > > problem (but most implementations have problems)? > > > > This patch itself just emulates the enablement of root_hub's remote > > wakeup automatically (then we needn't operate on sysfs). > > I'll run some experiments on my system. Maybe you're right about the > problem, but your proposed solution looks wrong. I just tried running the experiment on my system. I enabled wakeup for the mouse device, made sure it was disabled for the intermediate hub and the root hub, and made sure it was enabled for the host controller. (Those last three are the default settings.) Then I put the system in S3 suspend by writing "mem" to /sys/power/state, and when the system was asleep I pressed one of the mouse buttons -- and the system woke up. This was done under a 6.12.10 kernel, with an EHCI host controller, not xHCI. So it seems like something is wrong with your system in particular, not the core USB code in general. What type of host controller is your mouse attached to? Have you tested whether the mouse is able to wake up from runtime suspend, as opposed to S3 suspend? Alan Stern
Hi Alan, Huacai, <snip> > I just tried running the experiment on my system. I enabled wakeup for > the mouse device, made sure it was disabled for the intermediate hub and > the root hub, and made sure it was enabled for the host controller. > (Those last three are the default settings.) Then I put the system in > S3 suspend by writing "mem" to /sys/power/state, and when the system was > asleep I pressed one of the mouse buttons -- and the system woke up. > This was done under a 6.12.10 kernel, with an EHCI host controller, not > xHCI. > > So it seems like something is wrong with your system in particular, not > the core USB code in general. What type of host controller is your > mouse attached to? Have you tested whether the mouse is able to wake up > from runtime suspend, as opposed to S3 suspend? > Just to chime in with my own test results. I was looking at this with Huacai a few days back and we suspected that this had something to do with particular systems, as you have found; we also suspected that if a keyboard was connected to a non-xHCI controller, it would fail to wake up the system. I conducted a simple experiment on my Lenovo ThinkPad X200s, which does not come with any USB 3.0 port. Here are my findings: 1. With upstream code, the system would not wake up with neither the internal nor the external keyboards. One exception being the Fn key on the internal keyboard, which would wake up the system (but I suspect that this is EC behaviour). This behaviour is consistent across any USB port on the laptop and, regardless if the external keyboard was connected to the laptop itself or via a hub. 2. With Huacai's code, I was able to wake up the laptop with an external keyboard in all the scenarios listed in (1). The internal keyboard still failed to wake up the system unless I strike the Fn key. I should note, however, that the internal keyboard is not connected via USB so it's probably irrelevant information anyway. As for mice, it seems that the kernel disables wake-up via USB mice and enables wake-up via USB keyboards. This is also consistent with your findings. Best Regards, Mingcong Bai > Alan Stern >
Hi Alan, 在 2025/2/4 00:15, Alan Stern 写道: > On Tue, Feb 04, 2025 at 12:01:37AM +0800, Mingcong Bai wrote: >> Hi Alan, Huacai, >> >> <snip> >> >>> I just tried running the experiment on my system. I enabled wakeup for >>> the mouse device, made sure it was disabled for the intermediate hub and >>> the root hub, and made sure it was enabled for the host controller. >>> (Those last three are the default settings.) Then I put the system in >>> S3 suspend by writing "mem" to /sys/power/state, and when the system was >>> asleep I pressed one of the mouse buttons -- and the system woke up. >>> This was done under a 6.12.10 kernel, with an EHCI host controller, not >>> xHCI. >>> >>> So it seems like something is wrong with your system in particular, not >>> the core USB code in general. What type of host controller is your >>> mouse attached to? Have you tested whether the mouse is able to wake up >>> from runtime suspend, as opposed to S3 suspend? >>> >> >> Just to chime in with my own test results. I was looking at this with Huacai >> a few days back and we suspected that this had something to do with >> particular systems, as you have found; we also suspected that if a keyboard >> was connected to a non-xHCI controller, it would fail to wake up the system. >> >> I conducted a simple experiment on my Lenovo ThinkPad X200s, which does not >> come with any USB 3.0 port. Here are my findings: > > What sort of USB controller does the X200s have? Is the controller > enabled for wakeup? > > What happens with runtime suspend rather than S3 suspend? It has the Intel Corporation 82801I (ICH9 Family) USB UCHI/USB2 EHCI controller with PCI IDs 17aa:20f0/17aa:20f1. The hub is a Genesys Logic, Inc. Hub with an ID of 05e3:0610 - this is an xHCI hub. Sorry but the record here is going to get a bit messy... But let's start with a kernel with Huacai's patch. === Kernel + Huacai's Patch === 1. If I plug in the external keyboard via the hub, /sys/bus/usb/devices/usb1, power/state is set to enabled. For the hub, corresponding to usb1/1-1, power/wakeup is set to disabled. 2. If I plug the keyboard directly into the chassis, usb1/power/wakeup is set to disabled, but usb1/1-1/power/wakeup is set to enabled. The system wakes up via external keyboard plugged directly into the chassis **or** the hub either way, regardless if I used S3 or runtime suspend (which I assume to be echo freeze > /sys/power/state). === Kernel w/o Huacai's Patch === The controller where I plugged in the USB hub, /sys/bus/usb/devices/usb1 and the hub, corresponding to usb1/1-1, their power/wakeup entries are both set to disabled. Same for when I have the patch applied. However, if I plug the external keyboard into the chassis, it would fail to wakeup regardless of S3/runtime suspend (freeze). If I plug the external keyboard via that USB Hub though, it would wake up the machine. The findings are consistent between S3/freeze. > >> 1. With upstream code, the system would not wake up with neither the >> internal nor the external keyboards. One exception being the Fn key on the >> internal keyboard, which would wake up the system (but I suspect that this >> is EC behaviour). This behaviour is consistent across any USB port on the >> laptop and, regardless if the external keyboard was connected to the laptop >> itself or via a hub. >> >> 2. With Huacai's code, I was able to wake up the laptop with an external >> keyboard in all the scenarios listed in (1). The internal keyboard still >> failed to wake up the system unless I strike the Fn key. >> >> I should note, however, that the internal keyboard is not connected via USB >> so it's probably irrelevant information anyway. >> >> As for mice, it seems that the kernel disables wake-up via USB mice and >> enables wake-up via USB keyboards. This is also consistent with your >> findings. > > Yes, and of course you can manually change the default wakeup settings > whenever you want. > > Alan Stern Best Regards, Mingcong Bai
Hi Alan, 在 2025/2/6 02:25, Alan Stern 写道: > On Wed, Feb 05, 2025 at 01:59:24PM +0800, Mingcong Bai wrote: >> 在 2025/2/4 00:15, Alan Stern 写道: >>> What sort of USB controller does the X200s have? Is the controller >>> enabled for wakeup? >>> >>> What happens with runtime suspend rather than S3 suspend? >> >> It has the Intel Corporation 82801I (ICH9 Family) USB UCHI/USB2 EHCI > > UHCI, not UCHI. > >> controller with PCI IDs 17aa:20f0/17aa:20f1. The hub is a Genesys Logic, >> Inc. Hub with an ID of 05e3:0610 - this is an xHCI hub. > > There is no such thing as an xHCI hub -- xHCI is a host controller > technology, not a hub technology. Perhaps you mean that it is a USB-3 > hub. > >> Sorry but the record here is going to get a bit messy... But let's start >> with a kernel with Huacai's patch. >> >> === Kernel + Huacai's Patch === >> >> 1. If I plug in the external keyboard via the hub, >> /sys/bus/usb/devices/usb1, > > /sys/bus/usb/devices/usb1 is the root hub, which is an emulated device > that is closely tied to the host controller. The external Genesys Logic > hub is /sys/bus/usb/devices/1-1. > >> power/state is set to enabled. For the hub, > > You mean power/wakeup, not power/state. In fact, there is no > power/state file for USB devices in sysfs. Sorry for the typos and terminology issues above. You are correct on all counts. Yes, I meant to say a USB 3.0 hub. > >> corresponding to usb1/1-1, power/wakeup is set to disabled. >> >> 2. If I plug the keyboard directly into the chassis, usb1/power/wakeup is >> set to disabled, but usb1/1-1/power/wakeup is set to enabled. > > Why is usb1/power/wakeup set to disabled? Doesn't Huacai's patch set it > to enabled? No idea on my end either, I have double checked and that is indeed how it is (and wakeup does work). > > Is 1-1 the keyboard device? That is, did you plug the keyboard into the > port that the Genesys Logic hub was using previously? > >> The system wakes up via external keyboard plugged directly into the chassis >> **or** the hub either way, regardless if I used S3 or runtime suspend (which >> I assume to be echo freeze > /sys/power/state). > > No. Runtime suspend has no relation to /sys/power. It is controlled by > /sys/bus/usb/devices/.../power/control. If you write "auto" to this > file for the device and for all the hubs above it (including the root > hub) then they will be put into runtime suspend a few seconds after you > stop using them, assuming no other USB devices are plugged into the same > hubs. Got it. On both unpatched and patched kernels, I have set power/control to "auto" for both the root hub and the external hub and left the keyboard for 60 seconds. Regardless if I plug the keyboard into the chassis or the external hub, the keyboard continues to work from the first key strike (no delay or lost input). > >> === Kernel w/o Huacai's Patch === >> >> The controller where I plugged in the USB hub, /sys/bus/usb/devices/usb1 and > > /sys/bus/usb/devices/usb1 is the root hub, not the controller. The two > are related but they are not the same thing. The controller is the > parent device of the root hub; it lies under /sys/bus/pci/devices/. > >> the hub, corresponding to usb1/1-1, their power/wakeup entries are both set >> to disabled. Same for when I have the patch applied. >> >> However, if I plug the external keyboard into the chassis, it would fail to >> wakeup regardless of S3/runtime suspend (freeze). If I plug the external >> keyboard via that USB Hub though, it would wake up the machine. The findings >> are consistent between S3/freeze. > > This means there's something different between the way the keyboard > sends its wakeup signal and the way the Genesys Logic hub sends its > wakeup signal. > > Can you post the output from "lsusb -t" for this system? Keyboard plugged into the chassis: /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M Keyboard plugged into the hub: /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 001: Dev 004, If 0, Class=Vendor Specific Class, Driver=r8152, 480M |__ Port 004: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M > > Also, can you enable dynamic debugging for usbcore by doing: > > echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control > > and then post the dmesg log for a suspend/resume cycle? Keyboard plugged into the chassis (does not wake up via the external keyboard, needed to strike Fn on the internal keyboard): [ 362.886330] PM: suspend entry (deep) [ 363.286839] Filesystems sync: 0.400 seconds [ 363.323106] Freezing user space processes [ 363.324899] Freezing user space processes completed (elapsed 0.001 seconds) [ 363.324909] OOM killer disabled. [ 363.324912] Freezing remaining freezable tasks [ 363.326107] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 363.326479] printk: Suspending console(s) (use no_console_suspend to debug) [ 363.331241] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 363.333294] usb 1-1: usb suspend, wakeup 1 [ 363.344205] usb usb8: usb auto-resume [ 363.344302] usb usb7: usb auto-resume [ 363.344380] usb usb6: usb auto-resume [ 363.344460] usb usb5: usb auto-resume [ 363.345267] usb usb3: usb auto-resume [ 363.345305] hub 3-0:1.0: hub_resume [ 363.345370] usb usb2: usb auto-resume [ 363.345426] hub 1-0:1.0: hub_suspend [ 363.345447] usb usb4: usb auto-resume [ 363.345562] usb usb1: bus suspend, wakeup 0 [ 363.345744] hub 3-0:1.0: hub_suspend [ 363.345763] usb usb3: bus suspend, wakeup 0 [ 363.345927] ata1.00: Entering standby power mode [ 363.353452] e1000e: EEE TX LPI TIMER: 00000000 [ 363.365259] hub 5-0:1.0: hub_resume [ 363.365294] hub 6-0:1.0: hub_resume [ 363.365320] hub 8-0:1.0: hub_resume [ 363.365401] hub 6-0:1.0: hub_suspend [ 363.365419] hub 5-0:1.0: hub_suspend [ 363.365435] hub 8-0:1.0: hub_suspend [ 363.365456] usb usb6: bus suspend, wakeup 0 [ 363.365487] usb usb5: bus suspend, wakeup 0 [ 363.365513] usb usb8: bus suspend, wakeup 0 [ 363.365626] hub 7-0:1.0: hub_resume [ 363.365675] hub 7-0:1.0: hub_suspend [ 363.365693] usb usb7: bus suspend, wakeup 0 [ 363.366246] hub 2-0:1.0: hub_resume [ 363.366348] hub 2-0:1.0: hub_suspend [ 363.366366] usb usb2: bus suspend, wakeup 0 [ 363.366428] hub 4-0:1.0: hub_resume [ 363.366470] hub 4-0:1.0: hub_suspend [ 363.366485] usb usb4: bus suspend, wakeup 0 [ 363.682065] ACPI: EC: interrupt blocked [ 363.682633] ehci-pci 0000:00:1d.7: wakeup: 1 [ 363.682714] uhci_hcd 0000:00:1d.2: wakeup: 1 [ 363.682719] uhci_hcd 0000:00:1d.2: --> PCI D0 [ 363.682757] uhci_hcd 0000:00:1d.1: wakeup: 1 [ 363.682760] uhci_hcd 0000:00:1d.1: --> PCI D0 [ 363.682796] uhci_hcd 0000:00:1d.0: wakeup: 1 [ 363.682849] uhci_hcd 0000:00:1d.0: --> PCI D2 [ 363.683087] ehci-pci 0000:00:1a.7: wakeup: 1 [ 363.683153] uhci_hcd 0000:00:1a.2: wakeup: 1 [ 363.683215] uhci_hcd 0000:00:1a.2: --> PCI D2 [ 363.683254] uhci_hcd 0000:00:1a.1: wakeup: 1 [ 363.683257] uhci_hcd 0000:00:1a.1: --> PCI D0 [ 363.683293] uhci_hcd 0000:00:1a.0: wakeup: 1 [ 363.683338] uhci_hcd 0000:00:1a.0: --> PCI D2 [ 363.694561] ehci-pci 0000:00:1a.7: --> PCI D3hot [ 363.694597] ehci-pci 0000:00:1d.7: --> PCI D3hot [ 363.694767] ACPI: PM: Preparing to enter system sleep state S3 [ 363.707378] ACPI: EC: event blocked [ 363.707382] ACPI: EC: EC stopped [ 363.707383] ACPI: PM: Saving platform NVS memory [ 363.709032] Disabling non-boot CPUs ... [ 363.709032] ACPI: PM: Low-level resume complete [ 363.709032] ACPI: EC: EC started [ 363.709032] ACPI: PM: Restoring platform NVS memory [ 363.709558] ACPI: PM: Waking up from system sleep state S3 [ 363.735865] ACPI: EC: interrupt unblocked [ 363.744280] usb usb1: root hub lost power or was reset [ 363.744731] ACPI: EC: event unblocked [ 363.745248] usb usb4: root hub lost power or was reset [ 363.745456] usb usb5: root hub lost power or was reset [ 363.745679] usb usb6: root hub lost power or was reset [ 363.745740] usb usb7: root hub lost power or was reset [ 363.745797] usb usb8: root hub lost power or was reset [ 363.745872] usb usb3: usb resume [ 363.745906] hub 3-0:1.0: hub_resume [ 363.745973] usb usb4: usb resume [ 363.745982] hub 4-0:1.0: hub_reset_resume [ 363.745985] hub 4-0:1.0: trying to enable port power on non-switchable hub [ 363.746459] usb usb5: usb resume [ 363.746469] hub 5-0:1.0: hub_reset_resume [ 363.746473] hub 5-0:1.0: trying to enable port power on non-switchable hub [ 363.747116] usb usb6: usb resume [ 363.747126] hub 6-0:1.0: hub_reset_resume [ 363.747130] hub 6-0:1.0: trying to enable port power on non-switchable hub [ 363.748764] usb usb7: usb resume [ 363.748775] hub 7-0:1.0: hub_reset_resume [ 363.748779] hub 7-0:1.0: trying to enable port power on non-switchable hub [ 363.748952] usb usb1: usb resume [ 363.748961] hub 1-0:1.0: hub_reset_resume [ 363.748965] hub 1-0:1.0: trying to enable port power on non-switchable hub [ 363.749036] usb usb8: usb resume [ 363.749045] hub 8-0:1.0: hub_reset_resume [ 363.749048] hub 8-0:1.0: trying to enable port power on non-switchable hub [ 363.750378] usb usb2: usb resume [ 363.751222] usb usb1-port1: status 0301 change 0003 [ 363.771214] hub 2-0:1.0: hub_resume [ 363.870210] usb 1-1: Waited 0ms for CONNECT [ 363.870217] usb 1-1: finish reset-resume [ 364.067770] ata2: SATA link down (SStatus 0 SControl 300) [ 364.126263] usb 1-1: reset low-speed USB device number 3 using uhci_hcd [ 364.859239] pcieport 0000:00:1c.0: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 364.859262] pcieport 0000:00:1c.1: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 364.859343] pcieport 0000:00:1c.3: pciehp: Timeout on hotplug command 0x0018 (issued 1122 msec ago) [ 364.868343] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 364.983337] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 365.212241] tpm tpm0: TPM is disabled/deactivated (0x6) [ 365.220350] ACPI: \_SB_.PCI0.SATA.SCND.MSTR: docking [ 365.220462] ACPI: \_SB_.PCI0.SATA.SCND.MSTR: Unable to dock! [ 365.220694] OOM killer enabled. [ 365.220702] Restarting tasks ... [ 365.222080] hub 3-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 365.222105] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222120] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222134] hub 8-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222148] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222205] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 365.222220] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222233] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002 [ 365.222266] hub 3-0:1.0: hub_suspend [ 365.222412] usb usb3: bus auto-suspend, wakeup 1 [ 365.222459] hub 6-0:1.0: hub_suspend [ 365.222511] hub 5-0:1.0: hub_suspend [ 365.222533] usb usb6: bus auto-suspend, wakeup 1 [ 365.222567] hub 8-0:1.0: hub_suspend [ 365.222580] usb usb5: bus auto-suspend, wakeup 1 [ 365.222612] hub 7-0:1.0: hub_suspend [ 365.222630] usb usb8: bus auto-suspend, wakeup 1 [ 365.222664] hub 2-0:1.0: hub_suspend [ 365.222677] usb usb7: bus auto-suspend, wakeup 1 [ 365.222708] hub 4-0:1.0: hub_suspend [ 365.222726] usb usb2: bus auto-suspend, wakeup 1 [ 365.222767] usb usb4: bus auto-suspend, wakeup 1 [ 365.237576] done. [ 365.273727] video LNXVIDEO:00: Restoring backlight state [ 365.281300] PM: suspend exit Keyboard plugged into the hub: [ 300.631522] PM: suspend entry (deep) [ 300.918836] Filesystems sync: 0.287 seconds [ 300.958743] Freezing user space processes [ 300.960270] Freezing user space processes completed (elapsed 0.001 seconds) [ 300.960279] OOM killer disabled. [ 300.960282] Freezing remaining freezable tasks [ 300.961290] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 300.961619] printk: Suspending console(s) (use no_console_suspend to debug) [ 300.965734] usb 2-1.4: usb suspend, wakeup 1 [ 300.966220] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 300.975608] r8152-cfgselector 2-1.1: usb suspend, wakeup 1 [ 300.983969] usb usb8: usb auto-resume [ 300.984000] usb usb7: usb auto-resume [ 300.984027] usb usb6: usb auto-resume [ 300.984056] usb usb5: usb auto-resume [ 300.984189] usb usb4: usb auto-resume [ 300.984281] usb usb3: usb auto-resume [ 300.984317] hub 3-0:1.0: hub_resume [ 300.984469] hub 3-0:1.0: hub_suspend [ 300.984485] usb usb3: bus suspend, wakeup 0 [ 300.984598] usb usb1: usb auto-resume [ 300.986240] hub 2-1:1.0: hub_suspend [ 300.988228] usb 2-1: usb suspend, wakeup 0 [ 300.991730] e1000e: EEE TX LPI TIMER: 00000000 [ 300.999224] hub 2-0:1.0: hub_suspend [ 300.999246] usb usb2: bus suspend, wakeup 0 [ 301.002231] ata1.00: Entering standby power mode [ 301.004222] hub 8-0:1.0: hub_resume [ 301.004275] hub 8-0:1.0: hub_suspend [ 301.004293] usb usb8: bus suspend, wakeup 0 [ 301.004371] hub 6-0:1.0: hub_resume [ 301.004410] hub 6-0:1.0: hub_suspend [ 301.004424] usb usb6: bus suspend, wakeup 0 [ 301.004495] hub 7-0:1.0: hub_resume [ 301.004534] hub 7-0:1.0: hub_suspend [ 301.004548] usb usb7: bus suspend, wakeup 0 [ 301.004620] hub 5-0:1.0: hub_resume [ 301.004658] hub 5-0:1.0: hub_suspend [ 301.004672] usb usb5: bus suspend, wakeup 0 [ 301.005220] hub 4-0:1.0: hub_resume [ 301.005260] hub 4-0:1.0: hub_suspend [ 301.005275] usb usb4: bus suspend, wakeup 0 [ 301.005351] hub 1-0:1.0: hub_resume [ 301.005389] hub 1-0:1.0: hub_suspend [ 301.005403] usb usb1: bus suspend, wakeup 0 [ 301.320060] ACPI: EC: interrupt blocked [ 301.320521] ehci-pci 0000:00:1d.7: wakeup: 1 [ 301.320603] uhci_hcd 0000:00:1d.2: wakeup: 1 [ 301.320608] uhci_hcd 0000:00:1d.2: --> PCI D0 [ 301.320644] uhci_hcd 0000:00:1d.1: wakeup: 1 [ 301.320648] uhci_hcd 0000:00:1d.1: --> PCI D0 [ 301.320683] uhci_hcd 0000:00:1d.0: wakeup: 1 [ 301.320738] uhci_hcd 0000:00:1d.0: --> PCI D2 [ 301.320967] ehci-pci 0000:00:1a.7: wakeup: 1 [ 301.321032] uhci_hcd 0000:00:1a.2: wakeup: 1 [ 301.321081] uhci_hcd 0000:00:1a.2: --> PCI D2 [ 301.321119] uhci_hcd 0000:00:1a.1: wakeup: 1 [ 301.321122] uhci_hcd 0000:00:1a.1: --> PCI D0 [ 301.321157] uhci_hcd 0000:00:1a.0: wakeup: 1 [ 301.321211] uhci_hcd 0000:00:1a.0: --> PCI D2 [ 301.332213] ehci-pci 0000:00:1a.7: --> PCI D3hot [ 301.332287] ehci-pci 0000:00:1d.7: --> PCI D3hot [ 301.333259] ACPI: PM: Preparing to enter system sleep state S3 [ 301.345826] ACPI: EC: event blocked [ 301.345829] ACPI: EC: EC stopped [ 301.345831] ACPI: PM: Saving platform NVS memory [ 301.347482] Disabling non-boot CPUs ... [ 301.358452] ACPI: PM: Low-level resume complete [ 301.358492] ACPI: EC: EC started [ 301.358494] ACPI: PM: Restoring platform NVS memory [ 301.360029] ACPI: PM: Waking up from system sleep state S3 [ 301.384290] ACPI: EC: interrupt unblocked [ 301.386938] usb usb7: root hub lost power or was reset [ 301.386996] usb usb8: root hub lost power or was reset [ 301.387109] usb usb1: root hub lost power or was reset [ 301.387451] usb usb1: usb resume [ 301.387810] hub 1-0:1.0: hub_reset_resume [ 301.388174] hub 1-0:1.0: trying to enable port power on non-switchable hub [ 301.388828] usb usb6: root hub lost power or was reset [ 301.389860] usb usb4: root hub lost power or was reset [ 301.390026] usb usb5: root hub lost power or was reset [ 301.391115] usb usb3: usb resume [ 301.391150] hub 3-0:1.0: hub_resume [ 301.391312] usb usb2: usb resume [ 301.391371] hub 2-0:1.0: hub_resume [ 301.393298] usb usb2-port1: status 0507 change 0000 [ 301.393517] usb usb4: usb resume [ 301.393526] hub 4-0:1.0: hub_reset_resume [ 301.393529] hub 4-0:1.0: trying to enable port power on non-switchable hub [ 301.393572] usb usb5: usb resume [ 301.393580] hub 5-0:1.0: hub_reset_resume [ 301.393583] hub 5-0:1.0: trying to enable port power on non-switchable hub [ 301.393651] usb usb6: usb resume [ 301.393659] hub 6-0:1.0: hub_reset_resume [ 301.393661] hub 6-0:1.0: trying to enable port power on non-switchable hub [ 301.394042] ACPI: EC: event unblocked [ 301.394380] usb usb7: usb resume [ 301.394390] hub 7-0:1.0: hub_reset_resume [ 301.394393] hub 7-0:1.0: trying to enable port power on non-switchable hub [ 301.394846] usb usb8: usb resume [ 301.394856] hub 8-0:1.0: hub_reset_resume [ 301.394859] hub 8-0:1.0: trying to enable port power on non-switchable hub [ 301.395151] usb 2-1: usb resume [ 301.407569] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 301.446267] usb 2-1: Waited 0ms for CONNECT [ 301.446274] usb 2-1: finish resume [ 301.446496] hub 2-1:1.0: hub_resume [ 301.446738] usb 2-1-port1: status 0507 change 0000 [ 301.447487] usb 2-1-port4: status 0303 change 0004 [ 301.448488] r8152-cfgselector 2-1.1: usb resume [ 301.459266] usb 2-1.4: Waited 0ms for CONNECT [ 301.459272] usb 2-1.4: finish resume [ 301.500260] r8152-cfgselector 2-1.1: Waited 0ms for CONNECT [ 301.500267] r8152-cfgselector 2-1.1: finish resume [ 301.703719] ata2: SATA link down (SStatus 0 SControl 300) [ 302.231255] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 302.231260] clocksource: 'hpet' wd_nsec: 686990643 wd_now: e82aa5 wd_last: 5212fe mask: ffffffff [ 302.231265] clocksource: 'tsc' cs_nsec: 495997904 cs_now: 5f58466b cs_last: 360f1164 mask: ffffffffffffffff [ 302.231269] clocksource: Clocksource 'tsc' skewed -190992739 ns (-190 ms) over watchdog 'hpet' interval of 686990643 ns (686 ms) [ 302.231274] clocksource: 'tsc' is current clocksource. [ 302.231279] tsc: Marking TSC unstable due to clocksource watchdog [ 302.231309] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. [ 302.231312] sched_clock: Marking unstable (302218066766, 1180678)<-(302494932176, -263623254) [ 302.219394] clocksource: Not enough CPUs to check clocksource 'tsc'. [ 302.219425] clocksource: Switched to clocksource hpet [ 302.494221] pcieport 0000:00:1c.1: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 302.494250] pcieport 0000:00:1c.0: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 302.494327] pcieport 0000:00:1c.3: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 302.503313] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 302.618321] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 302.660241] tpm tpm0: TPM is disabled/deactivated (0x6) [ 302.670557] OOM killer enabled. [ 302.670566] Restarting tasks ... [ 302.670842] hub 3-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 302.670880] hub 3-0:1.0: hub_suspend [ 302.670924] hub 8-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671024] hub 8-0:1.0: hub_suspend [ 302.671052] usb usb8: bus auto-suspend, wakeup 1 [ 302.671088] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671106] hub 6-0:1.0: hub_suspend [ 302.671128] usb usb6: bus auto-suspend, wakeup 1 [ 302.671161] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671179] hub 7-0:1.0: hub_suspend [ 302.671216] usb usb7: bus auto-suspend, wakeup 1 [ 302.671248] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671266] hub 5-0:1.0: hub_suspend [ 302.671287] usb usb5: bus auto-suspend, wakeup 1 [ 302.671317] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671334] hub 4-0:1.0: hub_suspend [ 302.671356] usb usb4: bus auto-suspend, wakeup 1 [ 302.671386] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671403] hub 1-0:1.0: hub_suspend [ 302.671424] usb usb1: bus auto-suspend, wakeup 1 [ 302.671455] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 302.671469] hub 2-1:1.0: state 7 ports 4 chg 0000 evt 0010 [ 302.671493] usb usb3: bus auto-suspend, wakeup 1 [ 302.679716] done. [ 302.715864] video LNXVIDEO:00: Restoring backlight state [ 302.723732] PM: suspend exit > > Alan Stern Best Regards, Mingcong Bai
Hi again, Oops. I missed the dmesg. 在 2025/2/9 18:19, Mingcong Bai 写道: > Hi Alan, > > <snip> > >> This all makes sense. Since Huacai's patch was originally intended to >> fix Loongson's OHCI implementation, I was beginning to suspect if it >> exists for OHCI implementations found on older x86 platforms, say, >> AMD's SB600/700 series south bridges. Also to see if this issue is >> shared between OHCI and UHCI. >> >> I have purchased a motherboard to test this and will report back as >> soon as I get my hands on it. >> > > I have since purchased a Gigabyte GA-78LMT-S2 motherboard with an SB710 > south bridge, the USB OHCI controllers and USB device tree are as follows: > > 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] > SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] > 00:12.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] > SB7x0 USB OHCI1 Controller [1002:4398] > 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] > SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] > 00:13.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] > SB7x0 USB OHCI1 Controller [1002:4398] > 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] > SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399] > > /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M > ID 1d6b:0001 Linux Foundation 1.1 root hub > /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M > ID 1d6b:0002 Linux Foundation 2.0 root hub > /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M > ID 1d6b:0002 Linux Foundation 2.0 root hub > /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M > ID 1d6b:0001 Linux Foundation 1.1 root hub > /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M > ID 1d6b:0001 Linux Foundation 1.1 root hub > /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M > ID 1d6b:0001 Linux Foundation 1.1 root hub > |__ Port 002: Dev 004, If 0, Class=Human Interface Device, > Driver=usbhid, 1.5M > ID 17ef:6099 Lenovo > |__ Port 003: Dev 003, If 0, Class=Human Interface Device, > Driver=usbhid, 1.5M > ID 046d:c077 Logitech, Inc. Mouse > /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/2p, 12M > ID 1d6b:0001 Linux Foundation 1.1 root hub > > Long story short - wake from keyboard via OHCI works (as opposed to what > we have found with the Loongson XA61200 motherboard, which also has an > OHCI controller, but in its 7A2000 bridge chip). > > Huacai, I suspect that we are looking at a Loongson-specific issue. > > For your reference, here are the equivalent logs which I have supplied > for the ThinkPad X200s (which, according to my previous testing, failed > to wake up from an external keyboard plugged into its UHCI interface). > The OHCI to which the keyboard is connected to on this motherboard > corresponds to PCI device 0000:00:13.1: > > `grep . /sys/bus/usb/devices/*/serial`: > > /sys/bus/usb/devices/usb1/serial:0000:00:12.0 > /sys/bus/usb/devices/usb2/serial:0000:00:12.2 > /sys/bus/usb/devices/usb3/serial:0000:00:13.2 > /sys/bus/usb/devices/usb4/serial:0000:00:12.1 > /sys/bus/usb/devices/usb5/serial:0000:00:13.0 > /sys/bus/usb/devices/usb6/serial:0000:00:13.1 > /sys/bus/usb/devices/usb7/serial:0000:00:14.5 > > `cat /sys/kernel/debug/usb/ohci/0000:00:13.1/*`: > > size = 32 > 0 [117]: ed8/00000000dd878181 (ls dev4 ep1in-int qlen 1 max 8 00083084) > 1 [ 92]: ed8/000000001f1ee77f (ls dev3 ep1in-int qlen 1 max 4 00043083) > 8 [117]: ed8/00000000dd878181 > 9 [ 92]: ed8/000000001f1ee77f > 16 [117]: ed8/00000000dd878181 > 17 [ 92]: ed8/000000001f1ee77f > 24 [117]: ed8/00000000dd878181 > 25 [ 92]: ed8/000000001f1ee77f > bus pci, device 0000:00:13.1 > OHCI PCI host controller > ohci_hcd > OHCI 1.0, NO legacy support registers, rh state running > control 0x28f RWC HCFS=operational IE PLE CBSR=3 > cmdstatus 0x00000 SOC=0 > intrstatus 0x00000024 FNO SF > intrenable 0x8000005a MIE RHSC UE RD WDH > ed_controlhead 0108d0e0 > hcca frame 0x6d8a > fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf > fmremaining 0x80001dd1 FRT FR=0x1dd1 > periodicstart 0x2a2f > lsthresh 0x0628 > hub poll timer off > roothub.a 02000b03 POTPGT=2 OCPM NPS PSM NDP=3(3) > roothub.b 00000000 PPCM=0000 DR=0000 > roothub.status 00008000 DRWE > roothub.portstatus [0] 0x00000100 PPS > roothub.portstatus [1] 0x00000303 LSDA PPS PES CCS > roothub.portstatus [2] 0x00000303 LSDA PPS PES CCS > > `lspci -vv -s 13.0`: > > 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/ > SB8x0/SB9x0 USB OHCI0 Controller (prog-if 10 [OHCI]) > Subsystem: Gigabyte Technology Co., Ltd GA-78/880-series motherboard > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 32, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 18 > NUMA node: 0 > Region 0: Memory at fe02b000 (32-bit, non-prefetchable) [size=4K] > Kernel driver in use: ohci-pci > > `lspci -vv -s 13.1`: > > 00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB > OHCI1 Controller (prog-if 10 [OHCI]) > Subsystem: Gigabyte Technology Co., Ltd GA-MA78GM-S2H motherboard > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 32, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 18 > NUMA node: 0 > Region 0: Memory at fe02a000 (32-bit, non-prefetchable) [size=4K] > Kernel driver in use: ohci-pci > `dmesg` of the suspend sequence with dynamic debug on `usbcore`: [ 1113.101923] PM: suspend entry (deep) [ 1113.145038] Filesystems sync: 0.043 seconds [ 1113.209491] Freezing user space processes [ 1113.211153] Freezing user space processes completed (elapsed 0.001 seconds) [ 1113.211163] OOM killer disabled. [ 1113.211165] Freezing remaining freezable tasks [ 1113.212471] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 1113.212497] printk: Suspending console(s) (use no_console_suspend to debug) [ 1113.214870] usb usb7: usb auto-resume [ 1113.215460] serial 00:03: disabled [ 1113.215540] usb 6-3: usb suspend, wakeup 0 [ 1113.216021] usb usb5: usb auto-resume [ 1113.216177] usb usb4: usb auto-resume [ 1113.216546] usb 6-2: usb suspend, wakeup 1 [ 1113.217234] usb usb3: usb auto-resume [ 1113.217406] usb usb2: usb auto-resume [ 1113.217440] hub 2-0:1.0: hub_resume [ 1113.217499] hub 2-0:1.0: hub_suspend [ 1113.217508] usb usb2: bus suspend, wakeup 0 [ 1113.218431] usb usb1: usb auto-resume [ 1113.218463] sd 4:0:0:0: [sda] Synchronizing SCSI cache [ 1113.220421] ata5.00: Entering standby power mode [ 1113.228391] hub 6-0:1.0: hub_suspend [ 1113.228413] usb usb6: bus suspend, wakeup 0 [ 1113.238347] hub 3-0:1.0: hub_resume [ 1113.238404] hub 3-0:1.0: hub_suspend [ 1113.238414] usb usb3: bus suspend, wakeup 0 [ 1113.263489] hub 7-0:1.0: hub_resume [ 1113.263522] hub 7-0:1.0: hub_suspend [ 1113.263531] usb usb7: bus suspend, wakeup 0 [ 1113.264405] hub 5-0:1.0: hub_resume [ 1113.264429] hub 4-0:1.0: hub_resume [ 1113.264450] hub 5-0:1.0: hub_suspend [ 1113.264458] usb usb5: bus suspend, wakeup 0 [ 1113.264600] hub 4-0:1.0: hub_suspend [ 1113.264621] usb usb4: bus suspend, wakeup 0 [ 1113.268364] hub 1-0:1.0: hub_resume [ 1113.268414] hub 1-0:1.0: hub_suspend [ 1113.268425] usb usb1: bus suspend, wakeup 0 [ 1114.710476] ohci-pci 0000:00:14.5: wakeup: 1 [ 1114.710501] ohci-pci 0000:00:14.5: --> PCI D0 [ 1114.710605] ohci-pci 0000:00:13.1: wakeup: 1 [ 1114.710610] ohci-pci 0000:00:13.1: --> PCI D0 [ 1114.710615] ohci-pci 0000:00:13.0: wakeup: 1 [ 1114.710635] ohci-pci 0000:00:13.0: --> PCI D0 [ 1114.710641] ehci-pci 0000:00:12.2: wakeup: 1 [ 1114.710669] ohci-pci 0000:00:12.1: wakeup: 1 [ 1114.710674] ohci-pci 0000:00:12.1: --> PCI D0 [ 1114.710705] ohci-pci 0000:00:12.0: wakeup: 1 [ 1114.710710] ohci-pci 0000:00:12.0: --> PCI D0 [ 1114.710752] ehci-pci 0000:00:13.2: wakeup: 1 [ 1114.722478] ehci-pci 0000:00:13.2: --> PCI D3hot [ 1114.722570] ehci-pci 0000:00:12.2: --> PCI D3hot [ 1114.722596] ACPI: PM: Preparing to enter system sleep state S3 [ 1114.722737] ACPI: PM: Saving platform NVS memory [ 1114.722777] Disabling non-boot CPUs ... [ 1114.724483] smpboot: CPU 1 is now offline [ 1114.725283] ACPI: PM: Low-level resume complete [ 1114.725303] ACPI: PM: Restoring platform NVS memory [ 1114.725347] LVT offset 1 assigned for vector 0x400 [ 1114.725359] LVT offset 1 assigned [ 1114.725707] Enabling non-boot CPUs ... [ 1114.725747] smpboot: Booting Node 0 Processor 1 APIC 0x1 [ 1114.728737] CPU1 is up [ 1114.729088] ACPI: PM: Waking up from system sleep state S3 [ 1114.729555] ahci 0000:00:11.0: set SATA to AHCI mode [ 1114.743246] serial 00:03: activated [ 1114.756206] [drm] PCIE gen 2 link speeds already enabled [ 1114.764122] usb usb1: root hub lost power or was reset [ 1114.764173] usb usb7: root hub lost power or was reset [ 1114.764205] usb usb4: root hub lost power or was reset [ 1114.764219] usb usb6: root hub lost power or was reset [ 1114.764237] usb usb4: usb resume [ 1114.764254] usb usb5: root hub lost power or was reset [ 1114.764271] usb usb1: usb resume [ 1114.764276] usb usb2: usb resume [ 1114.764294] usb usb3: usb resume [ 1114.764316] hub 2-0:1.0: hub_resume [ 1114.764380] usb usb5: usb resume [ 1114.764399] usb usb6: usb resume [ 1114.768550] usb usb7: usb resume [ 1114.769473] [drm] PCIE GART of 2048M enabled (table at 0x0000000000165000). [ 1114.769571] radeon 0000:01:00.0: WB enabled [ 1114.769574] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 [ 1114.769576] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 [ 1114.769578] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 [ 1114.769579] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c [ 1114.769581] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 [ 1114.769982] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 [ 1114.785155] hub 3-0:1.0: hub_resume [ 1114.819119] hub 5-0:1.0: hub_reset_resume [ 1114.819122] hub 5-0:1.0: trying to enable port power on non-switchable hub [ 1114.819145] hub 4-0:1.0: hub_reset_resume [ 1114.819151] hub 4-0:1.0: trying to enable port power on non-switchable hub [ 1114.819156] hub 1-0:1.0: hub_reset_resume [ 1114.819158] hub 1-0:1.0: trying to enable port power on non-switchable hub [ 1114.823143] hub 7-0:1.0: hub_reset_resume [ 1114.823149] hub 7-0:1.0: trying to enable port power on non-switchable hub [ 1114.830220] hub 6-0:1.0: hub_reset_resume [ 1114.830226] hub 6-0:1.0: trying to enable port power on non-switchable hub [ 1114.835158] usb usb6-port2: status 0307 change 0000 [ 1114.835175] usb usb6-port3: status 0307 change 0000 [ 1114.835224] usb 6-3: usb resume [ 1114.835228] usb 6-2: usb resume [ 1114.887136] usb 6-3: Waited 0ms for CONNECT [ 1114.887143] usb 6-3: finish reset-resume [ 1114.887160] usb 6-2: Waited 0ms for CONNECT [ 1114.887161] usb 6-2: finish reset-resume [ 1114.931454] ata5.00: ACPI cmd ef/03:08:00:00:00:a0(SET FEATURES) filtered out [ 1114.931462] ata5.00: ACPI cmd ef/03:20:00:00:00:a0(SET FEATURES) filtered out [ 1114.945495] [drm] ring test on 0 succeeded in 1 usecs [ 1114.945504] [drm] ring test on 1 succeeded in 1 usecs [ 1114.945508] [drm] ring test on 2 succeeded in 1 usecs [ 1114.945515] [drm] ring test on 3 succeeded in 3 usecs [ 1114.945521] [drm] ring test on 4 succeeded in 3 usecs [ 1114.958500] sd 4:0:0:0: [sda] Starting disk [ 1115.048845] ata4: SATA link down (SStatus 0 SControl 300) [ 1115.048886] ata2: SATA link down (SStatus 0 SControl 300) [ 1115.048916] ata1: SATA link down (SStatus 0 SControl 300) [ 1115.048946] ata3: SATA link down (SStatus 0 SControl 300) [ 1115.122985] [drm] ring test on 5 succeeded in 2 usecs [ 1115.122990] [drm] UVD initialized successfully. [ 1115.123034] [drm] ib test on ring 0 succeeded in 0 usecs [ 1115.123067] [drm] ib test on ring 1 succeeded in 0 usecs [ 1115.123098] [drm] ib test on ring 2 succeeded in 0 usecs [ 1115.123130] [drm] ib test on ring 3 succeeded in 0 usecs [ 1115.123160] [drm] ib test on ring 4 succeeded in 0 usecs [ 1115.158192] usb 6-2: reset low-speed USB device number 4 using ohci-pci [ 1115.726225] usb 6-3: reset low-speed USB device number 3 using ohci-pci [ 1115.779259] [drm] ib test on ring 5 succeeded [ 1116.033742] OOM killer enabled. [ 1116.033752] Restarting tasks ... [ 1116.033903] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 1116.033950] hub 5-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 1116.033959] hub 2-0:1.0: hub_suspend [ 1116.033973] hub 5-0:1.0: hub_suspend [ 1116.034013] usb usb2: bus auto-suspend, wakeup 1 [ 1116.034032] usb usb5: bus auto-suspend, wakeup 1 [ 1116.034113] hub 3-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 1116.034133] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 1116.034181] hub 4-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 1116.034195] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 1116.034207] hub 6-0:1.0: state 7 ports 3 chg 0000 evt 0008 [ 1116.035547] done. [ 1116.035977] PM: suspend exit [ 1116.048179] hub 3-0:1.0: hub_suspend [ 1116.048201] usb usb3: bus auto-suspend, wakeup 1 [ 1116.049119] hub 7-0:1.0: hub_suspend [ 1116.050939] usb usb7: bus auto-suspend, wakeup 1 [ 1116.050966] hub 4-0:1.0: hub_suspend [ 1116.051052] usb usb4: bus auto-suspend, wakeup 1 [ 1116.051075] hub 1-0:1.0: hub_suspend [ 1116.051083] usb usb1: bus auto-suspend, wakeup 1 [ 1116.529188] RTL8211E Gigabit Ethernet r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC) [ 1116.765376] r8169 0000:02:00.0 enp2s0: Link is Down [ 1119.704013] r8169 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control off Best Regards, Mingcong Bai
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..efd6374ccd1d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -3480,6 +3480,7 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) if (PMSG_IS_AUTO(msg)) goto err_wakeup; } + usb_enable_remote_wakeup(udev->bus->root_hub); } /* disable USB2 hardware LPM */ @@ -3543,8 +3544,10 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) /* Try to enable USB2 hardware LPM again */ usb_enable_usb2_hardware_lpm(udev); - if (udev->do_remote_wakeup) + if (udev->do_remote_wakeup) { (void) usb_disable_remote_wakeup(udev); + (void) usb_disable_remote_wakeup(udev->bus->root_hub); + } err_wakeup: /* System sleep transitions should never fail */
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards, so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> --- drivers/usb/core/hub.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)