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]
Message-ID: <Pine.LNX.4.44L0.1809130936350.1990-100000@iolanthe.rowland.org>
Date:   Thu, 13 Sep 2018 09:41:26 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux USB Mailing List <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 1/5] misc: rtsx_usb: Use USB remote wakeup signaling for
 card insertion detection

On Thu, 13 Sep 2018, Kai-Heng Feng wrote:

> I am working on the next version of this series, and the last missing  
> puzzle is to differentiate system-wide resume from runtime resume in  
> usb_driver's resume() and reset_resume() callback.
> 
> The parent device, rtsx_usb, has two child devices, rtsx_usb_ms and  
> rtsx_usb_sdmmc.
> pm_request_resume() is used in rtsx_usb's resume() to facilitate USB remote  
> wakeup signaling, so we don't need to poll the card slot status.
> But this has a side effect: during system resume the rtsx_usb calls  
> pm_request_resume() in its resume(), so child devices calls their  
> runtime_resume() instead of resume() callback.

Have you actually observed this?  It shouldn't happen.  
pm_request_resume() schedules a runtime resume on the PM work queue, 
but this work queue is frozen during system sleep.  It doesn't unfreeze 
until after all the devices have been restored to full power.  Thus the 
child device's resume() callback should be invoked before 
runtime_resume().

> So, is it reasonable to pass pm_message_t to resume() and reset_resume()  
> callbacks and use PMSG_IS_AUTO() to differentiate them?

It should not be necessary to do this.

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ