Received: by 10.192.165.148 with SMTP id m20csp4181276imm; Mon, 30 Apr 2018 13:20:14 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpgdXp0vFJAfds28MADvR9MuC3NSbjN4abXw4hyLUemINoGpnljJdBFXPp4B42YEDerzC1g X-Received: by 10.98.93.153 with SMTP id n25mr13205570pfj.143.1525119614092; Mon, 30 Apr 2018 13:20:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525119614; cv=none; d=google.com; s=arc-20160816; b=l7V+N8aFJZj6UpCLlwCDxguLBGvuaqOF/Vj0zNRPAGc2w/gUOeHfYQiAH00/7xlI8D 495kCyWzqq51B4ImXYMsHhY2wARMi2oM+i0PbWNzc9Y+wzjUaGIwRcmI9kLkwyPb2kfH 6rTuJ7YhOXS5Q56GBwotsYXHtBg3NjgaMf4Rq672Oaux9D7DzsoOS5gK8YVVyuVHV7U+ vZvjlja1ZrdO5l54P+Lyk4LyWIlE/85gB0yedpDJ0nPGseIbIN9dyZUHq51KBXtXn0ql UZzc7oxvw2jwwKZ6Cnp+TQwVAt+ERGBL1SuOKljCRvHU1WdcVeQtF19GF9ORO+GXNfDg QP+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dmarc-filter :arc-authentication-results; bh=OMsYUaYq/h2rJYHTz4Flno/cAEdJh87ldDVo5rC/Dd0=; b=NML9pqnjb1L1G5nf/+kSjjZmQxkZfeg9H46FtXUXRb1ERbE2kfOwrbTjBfyBg1q1Gv 7QQaD+w6F8Eor0JOhj5eQ/14jb0bRmgzDdWb/WC7d/nJle91iADRwHba350tdDkjAJAZ M2CIwwxym6fot+LgKsxWY8AmMbRWv2vxkMkfyNZuOEYnvmsG4ZNhutEODAo6AdD3fmDK U8i3rqx1YqdLRyTDpNWCQRcX7h3DX6aq7rlGJNnf5auRNSD9t385UgzAbfdHYUCJRVo0 Eq89XIb/SnqUSjAA7iMNFFygzk4/o6BTUZuLLcZ+0q/T32ee1FqtUClAxnjYaTSmE7Wl qIWQ== 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 1-v6si7941719ply.464.2018.04.30.13.19.29; Mon, 30 Apr 2018 13:20:14 -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 S1755986AbeD3UPm (ORCPT + 99 others); Mon, 30 Apr 2018 16:15:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:33126 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932088AbeD3T1C (ORCPT ); Mon, 30 Apr 2018 15:27:02 -0400 Received: from localhost (unknown [104.132.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F3CBC22DAC; Mon, 30 Apr 2018 19:27:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3CBC22DAC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ravi Chandra Sadineni , Alan Stern Subject: [PATCH 4.14 20/91] USB: Increment wakeup count on remote wakeup. Date: Mon, 30 Apr 2018 12:24:02 -0700 Message-Id: <20180430184005.266250935@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180430184004.216234025@linuxfoundation.org> References: <20180430184004.216234025@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 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 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ravi Chandra Sadineni commit 83a62c51ba7b3c0bf45150c4eac7aefc6c785e94 upstream. 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 Acked-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/hcd.c | 1 + drivers/usb/core/hub.c | 10 +++++++++- 2 files changed, 10 insertions(+), 1 deletion(-) --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -2376,6 +2376,7 @@ void usb_hcd_resume_root_hub (struct usb spin_lock_irqsave (&hcd_root_hub_lock, flags); if (hcd->rh_registered) { + pm_wakeup_event(&hcd->self.root_hub->dev, 0); set_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags); queue_work(pm_wq, &hcd->wakeup_work); } --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -650,12 +650,17 @@ void usb_wakeup_notification(struct usb_ 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); } @@ -3415,8 +3420,11 @@ int usb_port_resume(struct usb_device *u /* 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))