Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2095992imm; Thu, 20 Sep 2018 07:44:03 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbpoEPrc/1yMJSUCEVFkc2nrL4hJhf8aY3tSi8+GVC75InyPVpjBmuVsljkNMVYKKQGPe93 X-Received: by 2002:a62:8186:: with SMTP id t128-v6mr41100558pfd.192.1537454643154; Thu, 20 Sep 2018 07:44:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537454643; cv=none; d=google.com; s=arc-20160816; b=GpkB6T8R5XRHTS8uvG/QD2dIYhoXp859plxBs5t8IPddSbgtjq7/AkJ/9AfvJ8q19f dbbnVPzo9HBDeLojMnSLXdzVP4EEaUoNjo9HqVH8bi8x679uaeuKQoGkLAX++YQUuE1g Xh0/uUdhebgSYQh4f6+xNDagoI/BPY1lYcPIaM0nPWgfBE0XZen0cgZawlQij4qaLcX5 Nh/OUU8YHc/wTBVrWi/z1HbBcC8nU6ZP7tcc4Up6OFdY+XtA3248pZK/kgnEYBIu6xm4 Mqf6j7xi9d3e1xcj4ezDq6QdCsMtkxSTBb8AOaVhMmMrD/rzB1IuywNAzEo3JMzix//j A8DA== 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; bh=w2Z7TU3yhnpn1YazadwFrP6TU5D5B2IMgxWPW5/IRyg=; b=DUvDggbcdBAJI5kfMqH7IfCyuM57AEckVk7o+8OrVSkDBr0QZwmYBa6+fiqVqhB0Yi vDQn7/ZXyI1OzgWxQFqylnbvLBAFLydoeD/THfwcUzNcZCUSZiyKDnZ+eNWoDy+X8Sti O7j/g8A2Pq1ayCkYZkkJoQmtAX3DN1EL9r5SZZwM3BDUXKYMaZsuMZhvNDC+aR8zCyj7 ft2MPiTghtywotjNxjXYGJTOFRKQsNS4Aa1576zZuS+WypuOk7VxnZ3ONWvN2TMeYQfR wLvcMQ5z7moaDutE5aU50ptguJ+fJxIZjE26NZC/1ICFohlUy5J3+OfZk629rdXP6p5r nE/Q== 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 q16-v6si23381823pgm.185.2018.09.20.07.43.46; Thu, 20 Sep 2018 07:44: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 S1732857AbeITU1a (ORCPT + 99 others); Thu, 20 Sep 2018 16:27:30 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:33384 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1730984AbeITU1a (ORCPT ); Thu, 20 Sep 2018 16:27:30 -0400 Received: (qmail 3520 invoked by uid 2102); 20 Sep 2018 10:43:40 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Sep 2018 10:43:40 -0400 Date: Thu, 20 Sep 2018 10:43:40 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: AceLan Kao cc: Felipe Balbi , Daniel Drake , Joe Perches , Mathias Nyman , , Subject: Re: [PATCH] usb: core: disable USB2 LPM when suspending In-Reply-To: <20180920070940.14773-1-acelan.kao@canonical.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 Thu, 20 Sep 2018, AceLan Kao wrote: > We found a S5 current leakage issue on Dell DW1820 WiFi/BT combo card > which uses Qualcomm QCA6174 SoC. It also comes with WiFi and BT failure > when encountered current leakage issue. > 1. Power on, both WiFi and BT work. > 2. Power off and found a current leakage issue(consumes ~0.5W) > 3. Power on, no WiFi and BT devices can be found in lspci and lsusb. > 4. Power off, there is no current leakage issue at S5. > 5. continue to 1. > > From Qualcomm's report: > Based on the USB sniffer log, the difference between Linux and Windows > is USB LPM setting(no LPM transaction on Windows) which may leads to > the voltage leakage on Linux S5 state. > > After checked the LPM related code and found, when system is going to > enter S5, it resumes the USB devices from runtime suspend and enables > USB2 LPM, and then it calls usb_dev_poweroff() -> usb_suspend(), and > leave USB2 LPM stays enabled. But usb_suspend() -> usb_suspend_both() -> usb_suspend_device() -> generic_suspend() -> usb_port_suspend() -> usb_set_usb2_hardware_lpm(udev, 0). So why does USB2 LPM stay enabled? > Disable USB2 LPM in usb_suspend() fixes the issue mentioned above, > and try 30 times of s2idle, S3 and S5, the USB devices keep working > well. Disable USB2 LPM seems do no harm to the system. > > Signed-off-by: AceLan Kao > --- > drivers/usb/core/driver.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c > index e76e95f62f76..ac5e60d7104f 100644 > --- a/drivers/usb/core/driver.c > +++ b/drivers/usb/core/driver.c > @@ -1463,6 +1463,9 @@ int usb_suspend(struct device *dev, pm_message_t msg) > struct usb_device *udev = to_usb_device(dev); > int r; > > + if (udev->usb2_hw_lpm_enabled == 1) > + usb_set_usb2_hardware_lpm(udev, 0); At this point the device may still be in runtime suspend. Is that really okay? Alan Stern > + > unbind_no_pm_drivers_interfaces(udev); > > /* From now on we are sure all drivers support suspend/resume >