Received: by 10.192.165.148 with SMTP id m20csp571244imm; Fri, 20 Apr 2018 11:24:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/HZ4ADNQPwWe3Gphpk1GeMJS65UJsQ46Js0PTLGwwEF1ztvL6TTnLE/y5RsAWzOh9TBZbK X-Received: by 10.101.99.22 with SMTP id g22mr9547832pgv.410.1524248662435; Fri, 20 Apr 2018 11:24:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524248662; cv=none; d=google.com; s=arc-20160816; b=joH6DqLzAlaVwhbMJH5BQoVCRBYi7iR3zwkgQi/CeadthW/eNNScua5NWbngfnHP0M CgaJWvzWSqiztHSDqsfIcjuT5H/tfpcaWgsq26e24Oj1qUQnWLAduAhGIvstgHhoadH8 PMgyZjP+/K10PkyY21YYexc8t+KvQV27W4wOx7cBdpa3RWJzKLX9RfWeg4zRPuG53C5k xF3voKaTEjdQXBY/2OHQagHcGiXYX35bRJGDoBADRtUu8SpfY85ryxq6VhuCnKsherxd Rvd5XUl+UkVrl66he9IW3mEoywUaLkF4IixmlPy85uQTOmU79mBJ6SWwjmL26HXHdBPn 5LgA== 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=L6YsXjgQ7ice8TJwFiynR89lVJOKRV8cLQvAPWoYPDY=; b=oLtaq3enyKnWyYSqEgh6O2l0uxlCgXxnv7y3cORiUSxQ+sOC/wq7GAjRYwFSTteScs zB89203698nnTT9yekiiKknqX/pJMcaWPkwerfBc3aoc7Je4y+543lS9mhsdIMYMljJ6 saIWU18Tf8N1U61r8L35cv1S6El0WsEZuTv3PNYmZaNkjJES2N/ydvR6ZRBvjzv3gBpM gg3O4Jr9+Io47FP306B2esT5JAdeUXlrKmiQ7B9ESAh0Boo5iXzulJMmZ8NC2N+q3GlI JCsHmZXT7oW/zGWGc0a2xHO7Z4+GOVtIoGJgwRYoEopkmKXoIHsyGT6e599mTl2GgBty 42Yw== 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 l15si1957914pgu.659.2018.04.20.11.24.06; Fri, 20 Apr 2018 11:24:22 -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 S1753705AbeDTSWx (ORCPT + 99 others); Fri, 20 Apr 2018 14:22:53 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:49792 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753583AbeDTSWw (ORCPT ); Fri, 20 Apr 2018 14:22:52 -0400 Received: (qmail 6164 invoked by uid 2102); 20 Apr 2018 14:22:51 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2018 14:22:51 -0400 Date: Fri, 20 Apr 2018 14:22:51 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Ravi Chandra Sadineni cc: gregkh@linuxfoundation.org, , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH V5] USB: Increment wakeup count on remote wakeup. In-Reply-To: <20180420180821.194380-1-ravisadineni@chromium.org> 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 Fri, 20 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 > --- > > V5: Added the description of changes between different versions of patches. > V4: Moved the wakeup count increment logic to the existing if which is > safegaurded by hcd_root_hub_lock spinlock. > V3: Added a gaurd to check if rh_registered is set before accessing > root_hub pointer. > V2: Fixed the build failure error due to uninitialized dev pointer. Acked-by: Alan Stern