Received: by 10.192.165.148 with SMTP id m20csp4137302imm; Mon, 30 Apr 2018 12:26:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq9Mgc+r1C821w1whToehWzOpjEqt6C7CnLsDGCRUe0+XDRZfdpwifDJNQnqoJIfiUZbkpA X-Received: by 2002:a17:902:108a:: with SMTP id c10-v6mr13889472pla.111.1525116364497; Mon, 30 Apr 2018 12:26:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525116364; cv=none; d=google.com; s=arc-20160816; b=WY4mC+qoEc2z+l8vjDo2aOGTKHy3HlFzg02u26FtPq2ln6M8fL9aPju39zjELM/M+Z mgCIvo9izmW2jBHNsKArhx9Qg6f7lq2i+L4pn0HiqxmWpmmygqmyEV3thLyKkLLlSC4l vrgxgMpe6KnF08qsTNFdyWZd11H520xz6svqxGhVI1xmol+G4fuUCUea7Yijr7xyRXB+ FgxsjhN/KaT+vy8g6wdMl4VPTb7T/pGa5N/KQ9ld53akMjSkeCAz2rQjRpsrhcRN4iLD uca1L9LMOl8nssmVKrD8wkmKVkylQaRttoPsvnWeeekWnSKTYnZJD9RxFk3H+N8EI2St Kupw== 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=5TCKwLz4dmea7CsZKt7MyMHIQUS/0H+oAKMc/3AgWcQ=; b=iITkgOXYQVxpCfMFPGFOeeouQI/xZRSyTjoI1QT01pq2mMtTqlEzXeLFsQrHyZCcBK E1VAgj8WRo565h86WU0eycrHI1al01k/LznjIcILqfy+AbyHmDw1cVfL33Feq70/eOyG fGdZGQhrIHVo1VJ1Tl2/EiFLDBtK6une1jAR2+96PnVjl5tizCUuDToWv4mkuGcFcUEK BuLHOix30cWbV60GzmrurcxsLsWcQOsw8JxWQzonK33ahd24P34PJaO8po2tVokeZam3 JGJ1a/rtjSGba/EjOE7y9jhUFl+s4ZsRckAn2FSQ0atouzmqKAa4j2PF3FyX49un/Qnf ujtw== 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 n29-v6si869171pgd.345.2018.04.30.12.25.50; Mon, 30 Apr 2018 12:26:04 -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 S1755243AbeD3TYH (ORCPT + 99 others); Mon, 30 Apr 2018 15:24:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:57840 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755222AbeD3TYG (ORCPT ); Mon, 30 Apr 2018 15:24:06 -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 782F522DA3; Mon, 30 Apr 2018 19:24:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 782F522DA3 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 3.18 09/25] USB: Increment wakeup count on remote wakeup. Date: Mon, 30 Apr 2018 12:23:16 -0700 Message-Id: <20180430183911.200062195@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180430183910.801976983@linuxfoundation.org> References: <20180430183910.801976983@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 3.18-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 @@ -2289,6 +2289,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 @@ -633,12 +633,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); } @@ -3363,8 +3368,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))