Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5862771imm; Mon, 23 Jul 2018 07:21:16 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf8TUlwdcE4kz/ndyzllZMvk5308lZXw1O6DPGaHnAYCzWU65FhmSMgSNsCBBRFO/q4GzQI X-Received: by 2002:a17:902:b717:: with SMTP id d23-v6mr13124120pls.105.1532355676909; Mon, 23 Jul 2018 07:21:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532355676; cv=none; d=google.com; s=arc-20160816; b=DxmTDkJ6x65gHq2qqRp0Day57uMa3pZ5ykFklS0aAKoqVKHHMbmpnRazspz9R3NVRc a4F+GnnkHsbkx5Tr2R0x4VcDCRFKbqVuaQBJ2qlinlfAXM21AHliduyqs0Wv1zRp/kw1 C9bx2lhxy/FEOABVQ4MFwCb880tvGEN6wPXGN4EHy5Bdgdd4PYpJzP2V2oZIc8e7Uz85 iDmUyCLdrlcFtaKk/gAE5BZ52MHoAOqgBDBwmhlFn8HY53QSTkx3Ik1STMhamB/3Q/OK Vqy7JsIOna0PGhEVw+4ctRedIuAedaT3tu6S21qUF0mysbLp0aQT3ql+dpk2HYmKUfU4 Dtvg== 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:arc-authentication-results; bh=g2j581FJ4AKk/Y69IXYSc0zSwsKwQjiVNcNBFqTm898=; b=F04+4YFI7qPz++mc9Tp/pulphVOJ+G4E4DuURxl4iF5uu5p0jeLuomI8w0Dyha478f 5iw2AeRPp7dQhXJD+8f1rXxBa5Ze93+urkWmnjPDvOzPRR45XyuT3WGqv2vJQ5DLMxdw W5z3BUQbfpPDthZNPqQLMYPmVOzLeMG5rm8qeGn80TCk9lcVBw1jJWk/ssqzA282Z2ic g8WqD5Ovd0cb3sS2ZKxuS48X9y/eBLl1U/8VtSn7YWBUOQ9zYXagtzyxXwcrmV7b24p+ Dvi6kL4S2jOXuP0eyW7H6758aAiWCcWXEJA48oH1vosJq8HshI103G+NFV4TcJONTtqz 4pZQ== 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 27-v6si8886333pgn.24.2018.07.23.07.21.01; Mon, 23 Jul 2018 07:21:16 -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 S2388338AbeGWPVM (ORCPT + 99 others); Mon, 23 Jul 2018 11:21:12 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:50394 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2388021AbeGWPVM (ORCPT ); Mon, 23 Jul 2018 11:21:12 -0400 Received: (qmail 2969 invoked by uid 2102); 23 Jul 2018 10:19:42 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Jul 2018 10:19:42 -0400 Date: Mon, 23 Jul 2018 10:19:42 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Kai-Heng Feng cc: arnd@arndb.de, , , , , , Subject: Re: [PATCH 1/5] misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection In-Reply-To: <20180723102744.15140-2-kai.heng.feng@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 Mon, 23 Jul 2018, Kai-Heng Feng 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 > --- > drivers/misc/cardreader/rtsx_usb.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/misc/cardreader/rtsx_usb.c b/drivers/misc/cardreader/rtsx_usb.c > index b97903ff1a72..fed83453e5c5 100644 > --- a/drivers/misc/cardreader/rtsx_usb.c > +++ b/drivers/misc/cardreader/rtsx_usb.c > @@ -723,8 +723,20 @@ 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) > +{ > + /* No need to wake up self again */ > + if (dev == data) > + return 0; Is this test actually needed? device_for_each_child() won't enumerate the device it is called for, only that device's children. > + > + dev_dbg(dev, "%s called\n", __func__); Not necessary. People can use ftrace if they want this information. Alan Stern > + pm_request_resume(dev); > + return 0; > +} > + > static int rtsx_usb_resume(struct usb_interface *intf) > { > + device_for_each_child(&intf->dev, &intf->dev, rtsx_usb_resume_child); > return 0; > } > > @@ -734,6 +746,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, &intf->dev, rtsx_usb_resume_child); > return 0; > } > >