Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp714914imm; Thu, 13 Sep 2018 06:43:40 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbLeJhQscCUtITXEr1RIO5Xbdo4+4xHjCg4AANMDJDzyEOSgGhxFW7MH7BK0jLHKEXuj1y8 X-Received: by 2002:a63:2150:: with SMTP id s16-v6mr7343069pgm.267.1536846220538; Thu, 13 Sep 2018 06:43:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536846220; cv=none; d=google.com; s=arc-20160816; b=oliisIvimmguoM7T854jnm5CLt9o2dmnubb6Z1yBV8NJ/l/p3ibTJhKUSM/Ot58Yk8 XeHNh5W2FFhxJ+MJX1lVuxukLrsNbQ7rAybmnWo778T13LmsE4mvhho+gnZArEbdC6si Gy7UHBm3g+ggkeioc14pmVFd17RpHgQmzU5B4WGgqgJ2cS4U7V/CJUoCFTw0MquAd11u 0MB0ys0bJ7adAXy/gV/H3qKh5IJAZflDr8ra5KwCfgtReRzB7Aq5a+1zgOEY+y39Dr8U ByiVQWbuT9VYAAr0jEOTBwq5MVcI7NCed5P8FaziTDthLtsj2BQ+qPbTzhhocKbLHFb5 GeMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=LwQznWM/5nOvvmfOZ7EMcMhZrFt5EdBiaXQqABqhqTs=; b=y7Z4lnclGc0V9gfzJTCYvYp7B6kZuR9/koV4bJ+wFhY9BGfiuOq8Cm1AhqWI9cG74k H37CI5fprRxcLTrtxJl79kCjrJp7U/oBk7vNjObokQCq3brDk47KLgmF93Hbw217lNZI XGh8GhFZf+BNUI/mF6ZsJNEjy9QtS7RTHkKeKOw2UQ7aXyn2NuBwyavhdk9RMbpEjceh Pl1pSmj/vm5tYN4hE+2sm176OYoqvlKeImI3xc0/d2u9CABBTuGuc/9I/vxaKtpuRWvc xYEBGNmT7T67Dkx4BVo+5EmNZ8NucEt6LnWBdsf3Z0iSb8DLRy/+eWDOZ8R1Dw/QkApG A15g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i5-v6si4111924pgg.84.2018.09.13.06.43.25; Thu, 13 Sep 2018 06:43:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729534AbeIMSu6 (ORCPT + 99 others); Thu, 13 Sep 2018 14:50:58 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:54898 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728786AbeIMSu5 (ORCPT ); Thu, 13 Sep 2018 14:50:57 -0400 Received: (qmail 2102 invoked by uid 2102); 13 Sep 2018 09:41:26 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Sep 2018 09:41:26 -0400 Date: Thu, 13 Sep 2018 09:41:26 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Kai-Heng Feng cc: Ulf Hansson , Linux Kernel Mailing List , Linux USB Mailing List Subject: Re: [PATCH 1/5] misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection In-Reply-To: <9C387477-5253-497B-8BE2-8245AB88C551@canonical.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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