linux-kernel - Re: `ohci_rh_resume()` called during `usb_dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 Jul 2018 10:21:45 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Paul Menzel <pmenzel+linux-usb@...gen.mpg.de>
cc:     linux-usb@...r.kernel.org, <linux-kernel@...r.kernel.org>
Subject: Re: `ohci_rh_resume()` called during `usb_dev_suspend()`

On Tue, 24 Jul 2018, Paul Menzel wrote:

> Dear Linux folks,
> 
> 
> Profiling the suspend to and resume/wake-up from ACPI S3 with 
> `sleepgraph.py` on an ASRock E350M1, I noticed that resume methods are 
> called during suspend.
> 
> Here is an excerpt from the callgraph.
> 
> >   600.376906 |   0)   kworker-81   |               |  /* device_pm_callback_start: usb usb5, parent: 0000:00:14.5, type [suspend] */
> >   600.376909 |   0)   kworker-81   |               |    usb_dev_suspend() {
> >   600.376911 |   0)   kworker-81   |               |      usb_suspend() {
> >   600.376913 |   0)   kworker-81   |               |        __pm_runtime_resume() {
> >   600.376915 |   0)   kworker-81   |               |          _cond_resched() {
> >   600.376917 |   0)   kworker-81   |   0.565 us    |            rcu_all_qs();
> >   600.376921 |   0)   kworker-81   |   4.034 us    |          } /* _cond_resched */
> >   600.376922 |   0)   kworker-81   |   0.505 us    |          _raw_spin_lock_irqsave();
> >   600.376926 |   0)   kworker-81   |               |          rpm_resume() {
> >   600.376928 |   0)   kworker-81   |   0.573 us    |            _raw_spin_lock();
> >   600.376934 |   0)   kworker-81   |   0.706 us    |            rpm_resume();
> >   600.376937 |   0)   kworker-81   |   0.556 us    |            _raw_spin_lock();
> >   600.376942 |   0)   kworker-81   |   0.721 us    |            __rpm_get_callback();
> >   600.376946 |   0)   kworker-81   |   0.564 us    |            dev_pm_disable_wake_irq_check();
> >   600.376949 |   0)   kworker-81   |               |            rpm_callback() {
> >   600.376952 |   0)   kworker-81   |               |              __rpm_callback() {
> >   600.376954 |   0)   kworker-81   |               |                usb_runtime_resume() {
> >   600.376956 |   0)   kworker-81   |               |                  usb_resume_both() {
> >   600.376959 |   0)   kworker-81   |               |                    generic_resume() {
> >   600.376960 |   0)   kworker-81   |               |                      hcd_bus_resume() {
> >   600.376963 |   0)   kworker-81   |               |                        ohci_bus_resume [ohci_hcd]() {
> >   600.376964 |   0)   kworker-81   |   0.588 us    |                          _raw_spin_lock_irq();
> >   600.376968 |   0)   kworker-81   |               |                          ohci_rh_resume [ohci_hcd]() {
> >   600.377043 |   0)   kworker-81   |               |                            msleep() {
> 
> Please find the full callgraph and the HTML output attached.
> 
> Is that expected?

I can't tell exactly what's happening from your callgraph and HTML, but
yes, in general it is expected.

The reason is because some devices have different wakeup settings for
runtime suspend and system suspend: A device that is enabled for wakeup
signalling during runtime suspend often is not enabled for wakeup
during system suspend.

As a result, the device's wakeup setting has to be changed when the 
system goes to sleep, and to do that, we have to wake the device up 
temporarily if it is already in runtime suspend.

Alan Stern