Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3164315imm; Mon, 13 Aug 2018 07:06:03 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyFI8cLYwcZu5mEOvGZzYNWQ7I+xidTM5dIArGtm1aM1Xu648UROQbA7WVEhF9707dpY1U3 X-Received: by 2002:a63:a919:: with SMTP id u25-v6mr17689503pge.211.1534169163322; Mon, 13 Aug 2018 07:06:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534169163; cv=none; d=google.com; s=arc-20160816; b=oXUglDXmZVJof6uLD6xN7BKWDBkEeH89/biKsHcuAFJm4V3eO2Cx2gZiaCII4TB5gU 5ngbqm1mEU5n7KduAp2Hd+/h6+YDW3DP6nguWyzHk/QseZo21xa/P5jn9APFZeAd4GYC xe0e5UqxjjOfHiwpntDdiqdIA69ozZvym8tJve9AsYcLZZrc79XJLEZHXZZNTrAWDHNJ 90i+/WtlUdZcnRdYJm3pOMWiQtO78ya2ZpvawdG15bSTMPSm/fissDZgoemWk3u1nWcK fXBPIooKyX0pVgJK8ky6qmAFQHhmJoXmLOsxaO12lp7AT8uYwvsyI6VtjJ75LSp9vZ/5 h3pA== 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=9n+epadb/H/qBst8gQY48oir8p0XM6UNrabFjxF08QA=; b=yw9B8npAdmUyjbDiGco4WHH54K9Vu3CEimKWPesme6Fv4T9os9+QHx93wbopl4x6k6 JcLFfqjQfalVdf6/DtpznTPspck2wpCrmdS4e+2lg+VGrwkla7EzmZHGVWbcxLoqh/Tv xeZkNLZJVu7fHqBcyu7yvYtQARzLvZu1kXNk3aMLPITohE1ICjOmsMdFjUDw5OtNcxvw cVnqZ6/VrHkBDrp+LAmLvlHKPdtyLKRVWcK6D0Xywe9QtsLQvUfe+SDoQeXx4Z2mqZLn 470WNE4Av7oqN/I7TIWt5Q361qxgWsAz43/yf6O/zq8E4XSs3EEIFyv8o8E8/26tR7I6 HsAw== 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 s2-v6si20620783pfs.2.2018.08.13.07.05.48; Mon, 13 Aug 2018 07:06:03 -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 S1729180AbeHMQrY (ORCPT + 99 others); Mon, 13 Aug 2018 12:47:24 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:45734 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728293AbeHMQrY (ORCPT ); Mon, 13 Aug 2018 12:47:24 -0400 Received: (qmail 1653 invoked by uid 2102); 13 Aug 2018 10:04:57 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Aug 2018 10:04:57 -0400 Date: Mon, 13 Aug 2018 10:04:57 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Anshuman Gupta cc: oneukum@suse.com, , Subject: Re: [Query] USB device autosuspend and its runtime usage count. In-Reply-To: <1534157102-29526-1-git-send-email-anshuman.gupta@intel.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, 13 Aug 2018, Anshuman Gupta wrote: > On Mon, Aug 13, 2018 at 01:19:26PM +0530, Oliver Neukum wrote: > > On Mo, 2018-08-13 at 12:15 +0530, Anshuman Gupta wrote: > > > Hi , > > > I need to test a functionality with USB autosuspend with latest kernel > > > Linux 4.18-rc8. I am trying to autosuspend a USB key board, i enabled > > > its autosuspend by doing echo "auto" to its "control" attributes. > > > I am expecting USB keyboard to go to autosuspend after autosuspend_delay_ms. > > > But USB key board is not going to autosuspend because its runtime usage > > > count is not equal to zero. > > > > > > Below are the log snippets: > > > > > > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5/power/runtime_enabled > > > enabled > > > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5/power/control > > > auto > > > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5/power/autosuspend_delay_ms > > > 2000 > > > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5/power/runtime_status > > > active > > > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5/power/runtime_usage > > > 1 > > > root@intel-Kabylake-Client-platform:# sleep 60; cat /sys/bus/usb/devices/1-5/power/runtime_usage > > > 1 > > > > > > My USB keyboard runtime usage reference count is not decreasing to zero. > > > Here am i missing something regarding runtime usage count or is it some issue with > > > my kernel or OS? > > > > Very hard to say without further information. Is the HID device the > > only interface of the whole device? > yes, HID device is only the interface for given device, below here lsusb -t log for usb dev 1-5. > > root@intel-Kabylake-Client-platform:# lsusb -t > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M > |__ Port 5: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M > |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M > > > Does the device support remote wakeup? > yes, from lsusb logs it seems, it is supporting remote wakeup. > > root@intel-Kabylake-Client-platform:# lsusb > Bus 001 Device 003: ID 04d9:1702 Holtek Semiconductor, Inc. Keyboard LKS02 > > root@intel-Kabylake-Client-platform:# lsusb -v -d 04d9:1702 | grep Remote > Remote Wakeup > > > Is an LED on? > Num lock led was on, but switching it off also does not help. > > > > Usbhid does support autosuspend, but its criteria must be met. > > And all interface drivers must call the device idle. > All of its interfaces are in runtime suspend > > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5\:1.0/power/runtime_status > suspended > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5\:1.1/power/runtime_status > suspended > root@intel-Kabylake-Client-platform:# cat /sys/bus/usb/devices/1-5/power/runtime_active_kids > 0 What matters is not the power/* settings for the interfaces themselves, but rather the power/* settings for the interfaces' children. Alan Stern