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;
Content-Type: text/plain;
        charset=us-ascii;
        delsp=yes;
        format=flowed
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [PATCH 1/5] misc: rtsx_usb: Use USB remote wakeup signaling for
 card insertion detection
From:   Kai-Heng Feng <kai.heng.feng@canonical.com>
In-Reply-To: <20180731061721.15831-2-kai.heng.feng@canonical.com>
Date:   Thu, 13 Sep 2018 18:31:11 +0800
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux USB Mailing List <linux-usb@vger.kernel.org>
Content-Transfer-Encoding: 7bit
Message-Id: <9C387477-5253-497B-8BE2-8245AB88C551@canonical.com>
References: <20180731061721.15831-1-kai.heng.feng@canonical.com>
 <20180731061721.15831-2-kai.heng.feng@canonical.com>
To:     Alan Stern <stern@rowland.harvard.edu>,
        Ulf Hansson <ulf.hansson@linaro.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Alan, Ulf,

at 14:17, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:

> Although rtsx_usb doesn't support card removal detection, card insertion
> will resume rtsx_usb by USB remote wakeup signaling.
>
> When rtsx_usb gets resumed, also resumes its child devices,
> rtsx_usb_sdmmc and rtsx_usb_ms, to notify them there's a card in its
> slot.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>  drivers/misc/cardreader/rtsx_usb.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/misc/cardreader/rtsx_usb.c  
> b/drivers/misc/cardreader/rtsx_usb.c
> index b97903ff1a72..f7a66f614085 100644
> --- a/drivers/misc/cardreader/rtsx_usb.c
> +++ b/drivers/misc/cardreader/rtsx_usb.c
> @@ -723,8 +723,15 @@ static int rtsx_usb_suspend(struct usb_interface  
> *intf, pm_message_t message)
>  	return 0;
>  }
>
> +static int rtsx_usb_resume_child(struct device *dev, void *data)
> +{
> +	pm_request_resume(dev);
> +	return 0;
> +}
> +
>  static int rtsx_usb_resume(struct usb_interface *intf)
>  {
> +	device_for_each_child(&intf->dev, NULL, rtsx_usb_resume_child);
>  	return 0;
>  }
>
> @@ -734,6 +741,7 @@ static int rtsx_usb_reset_resume(struct usb_interface  
> *intf)
>  		(struct rtsx_ucr *)usb_get_intfdata(intf);
>
>  	rtsx_usb_reset_chip(ucr);
> +	device_for_each_child(&intf->dev, NULL, rtsx_usb_resume_child);
>  	return 0;
>  }

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.

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

Kai-Heng

>
> -- 
> 2.17.1