Received: by 10.192.165.148 with SMTP id m20csp501775imm; Fri, 20 Apr 2018 10:09:30 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+OoSAe5AAZwOUGFIThHKLIZFTTPqO+ueIpbP35asH181nw/WcMRxzgazbPSn3TZZkZsU7R X-Received: by 10.99.101.66 with SMTP id z63mr9226824pgb.383.1524244170070; Fri, 20 Apr 2018 10:09:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524244170; cv=none; d=google.com; s=arc-20160816; b=g2vqWIz527UQTiR7R4xmpAVWgKKoLLrDO1ymxI+TPTKNp7hVutguXBR8ss47hVivfc 7ymLVbeggG4uNsbbdzdCxsIGdUFAgbjkZm0uPtAL5rvZPn2wbwgHtIW9ynhBvJIT7mvm Zn2tQi0XWJgLkCCToHkqFdaazbHd4O/Rv0vmHEzJd3S5fibTYC+qPT03KP5Q7HmKy2Qx dEyzz9Fr8KlmTB6pOg8VqZFs7J9PFAYCe73N3/KJztCc0oQsNNpK0kCv3sIp4YBdwM5P h2G+ZERQ0XZYZkk9q1H0bsbbVoDkl2lqxnn6nNKlWXiIQVZ3yNrt+X/CZSkf2hhZZqH9 9sSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=Hc+iBTVtQ0iiuPqVZIq9wewOwS88mzvRW4+/126+0hU=; b=C/aXwWp178GEfJ55gS67vHoVz6TY3VboJWViGI8I4cUpNUCSFpG+qntgRuV+FnX8kF W43z5jV+XrKa9oz8msLNwv/c/dzS7HlTzpP+RkMLYq0NsLcFhpImy4r3wL8QOzkpfA4W rejm+RE6aqMesrfXUvBUdn1Q96SlM1ltnnytGshkmfhnq/R5CEXBbxmCwitkGiXEjmvE cZ/ijHW7S+gHUCo9EImLQWCE6GnRiq10/Z8qE4GRL4A2wGt7qxUMVAEM5XQKqvU9WCac WYUHdINfZ9NMSp4W2lYexpRbYZKUGIEJfO2dd6zpZm10mZdAP9Y+dAOX51Rp2O3OrP1o yU5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZdznHRVF; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i21si5603225pfj.208.2018.04.20.10.09.15; Fri, 20 Apr 2018 10:09:30 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=ZdznHRVF; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753812AbeDTRH0 (ORCPT + 99 others); Fri, 20 Apr 2018 13:07:26 -0400 Received: from mail-vk0-f68.google.com ([209.85.213.68]:45897 "EHLO mail-vk0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753520AbeDTRHY (ORCPT ); Fri, 20 Apr 2018 13:07:24 -0400 Received: by mail-vk0-f68.google.com with SMTP id 203so5667660vka.12 for ; Fri, 20 Apr 2018 10:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hc+iBTVtQ0iiuPqVZIq9wewOwS88mzvRW4+/126+0hU=; b=ZdznHRVFHcwiKFKznpXeFQcTvu7gH3oNzv84ToyJsDsi2rWQYH+GTEAQbMWujhD6y/ IKsGp1rgnh4KNn44TdIXs6/qC7kPZipW8rEjgQbJz44ajXOTDrk1OO0ajp4gGZyLnpTU SPPW/e5sIovjPGjl74cNJvfo7tPOfQRsGmVzTRD4HVjDROoiDf0+Ux+GMVEOyL5iwnJX CF1NLHEcY3L1GnV6KrDc+LEbeqCecPMHcu8CKEt/meHRnYJq+DSrt4+2+bMY4tLP/zsb uTjwEpU0QGCp9TE+OvBq3U8w1yWG23/b94RVQQ9rR5Cvdy0w1TTGzCA0dPKi9hLvAYY8 s/VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hc+iBTVtQ0iiuPqVZIq9wewOwS88mzvRW4+/126+0hU=; b=fRDWlWtbqr03ZzkP1Y3yVp02d8s3FVC0lG/+Q4s2YU0iAy4qwG3JZrTWBK1tjFOKU+ jTBYlJWSM0NYA+O233+vyk5BUuYqoY/uY8pVm7mAtaIb/ksO3soYSIc5fK8H5wKUh9w0 nTAWpNm2QLkOkW75CleMc9jDOtFWxYQCOBkLRypO9fE2+GWL8T3FVPCxkZhmnm3B+J6r Ytosk2ldc6E9pxMi0agoocCD+s5GHU1twAnR0Z03yjHYi8M9jaIVU5/OYg7Y0FaVQ6w0 IQUow87INvLa7l+El6FzLjIZHo2wDHGKD3z+9uYiAopg8RAF7j+uqUQ0lBy+k+7FhJMg 4mBA== X-Gm-Message-State: ALQs6tDKDBLReRkEsrS7XZz+0Os7ZVjXNZnRnge/xDThhbd9SqdQQ6/m j9kZdV/geuiqBoc9IAuAbOBJeW1fsaJirE8lTTsMTg== X-Received: by 10.31.176.129 with SMTP id z123mr8259156vke.119.1524244042690; Fri, 20 Apr 2018 10:07:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.116.199 with HTTP; Fri, 20 Apr 2018 10:07:02 -0700 (PDT) In-Reply-To: References: <20180420002752.181261-1-ravisadineni@chromium.org> From: Ravi Chandra Sadineni Date: Fri, 20 Apr 2018 10:07:02 -0700 Message-ID: Subject: Re: [PATCH V2] USB: Increment wakeup count on remote wakeup. To: Alan Stern Cc: Ravi Chandra Sadineni , gregkh@linuxfoundation.org, martin.blumenstingl@googlemail.com, chunfeng.yun@mediatek.com, johan@kernel.org, arvind.yadav.cs@gmail.com, Dmitry Torokhov , anton.bondarenko.sama@gmail.com, f.fainelli@gmail.com, keescook@chromium.org, mathias.nyman@linux.intel.com, felipe.balbi@linux.intel.com, ekorenevsky@gmail.com, peter.chen@nxp.com, joe@perches.com, Todd Broch , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Rajat Jain , Benson Leung Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2018 at 7:12 AM, Alan Stern wrote: > On Thu, 19 Apr 2018, Ravi Chandra Sadineni wrote: > >> On chromebooks we depend on wakeup count to identify the wakeup source. >> But currently USB devices do not increment the wakeup count when they >> trigger the remote wake. This patch addresses the same. >> >> Resume condition is reported differently on USB 2.0 and USB 3.0 devices. >> >> On USB 2.0 devices, a wake capable device, if wake enabled, drives >> resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). >> The upstream facing port then sets C_PORT_SUSPEND bit and reports a >> port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port >> has resumed before driving the resume signal from the host and >> C_PORT_SUSPEND is set, then the device attached to the given port might >> be the reason for the last system wakeup. Increment the wakeup count for >> the same. >> >> On USB 3.0 devices, a function may signal that it wants to exit from device >> suspend by sending a Function Wake Device Notification to the host (USB3.0 >> spec section 8.5.6.4) Thus on receiving the Function Wake, increment the >> wakeup count. >> >> Signed-off-by: Ravi Chandra Sadineni >> --- >> drivers/usb/core/hcd.c | 2 ++ >> drivers/usb/core/hub.c | 10 +++++++++- >> 2 files changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c >> index 777036ae63674..ee0f3ec57ce49 100644 >> --- a/drivers/usb/core/hcd.c >> +++ b/drivers/usb/core/hcd.c >> @@ -2374,7 +2374,9 @@ static void hcd_resume_work(struct work_struct *work) >> void usb_hcd_resume_root_hub (struct usb_hcd *hcd) >> { >> unsigned long flags; >> + struct device *dev = &hcd->self.root_hub->dev; >> >> + pm_wakeup_event(dev, 0); >> spin_lock_irqsave (&hcd_root_hub_lock, flags); >> if (hcd->rh_registered) { >> set_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags); > > In general, hcd->self.root_hub is guaranteed to be non-NULL only when > hcd->rh_registered is set. Therefore the assignment to dev and the > call to pm_wakeup_event() should be moved within this "if" statement. > > The rest of the patch looks okay. Added the check in V3. Thanks. > > Alan Stern > >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >> index f6ea16e9f6bb9..aa9968d90a48c 100644 >> --- a/drivers/usb/core/hub.c >> +++ b/drivers/usb/core/hub.c >> @@ -653,12 +653,17 @@ void usb_wakeup_notification(struct usb_device *hdev, >> unsigned int portnum) >> { >> struct usb_hub *hub; >> + struct usb_port *port_dev; >> >> if (!hdev) >> return; >> >> hub = usb_hub_to_struct_hub(hdev); >> if (hub) { >> + port_dev = hub->ports[portnum - 1]; >> + if (port_dev && port_dev->child) >> + pm_wakeup_event(&port_dev->child->dev, 0); >> + >> set_bit(portnum, hub->wakeup_bits); >> kick_hub_wq(hub); >> } >> @@ -3434,8 +3439,11 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg) >> >> /* Skip the initial Clear-Suspend step for a remote wakeup */ >> status = hub_port_status(hub, port1, &portstatus, &portchange); >> - if (status == 0 && !port_is_suspended(hub, portstatus)) >> + if (status == 0 && !port_is_suspended(hub, portstatus)) { >> + if (portchange & USB_PORT_STAT_C_SUSPEND) >> + pm_wakeup_event(&udev->dev, 0); >> goto SuspendCleared; >> + } >> >> /* see 7.1.7.7; affects power usage, but not budgeting */ >> if (hub_is_superspeed(hub->hdev)) >> > Thanks, Ravi