Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6680785ybe; Wed, 18 Sep 2019 07:24:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyx1oxLRPOB0ZEyc9iJoBBqe7U0zd4wJsWk2GOcqSem30MTRXUIBqVvEBz+GnOEV065VQPH X-Received: by 2002:a50:f09d:: with SMTP id v29mr10421185edl.4.1568816688160; Wed, 18 Sep 2019 07:24:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568816688; cv=none; d=google.com; s=arc-20160816; b=baMw0YeC3fEzvSX4hU5cHvNHzvy9jjwfyhsfajGZCfVn4oA4SjGv23Tnn4q2mtD4wT MtvUoq0phUoGEEtmOBmFFfP9aBLGNw4n2NINXf1uBeQjS4qGG1blZL+msX9RTZee4+zq NStR329U/HzZSjzb3Wos2kvooPcL+JQTbBvcVc5IDz9DYibQPdyN5Yx+B5JwPViXaNK4 AXIQMKlutlcZt8k0ZozP5RmAzHgT7TZoN0CnHHfeOXZFgJ1FSrUvWysBSrs4G12cYj7B VMR9P/1UMBD/NaU3BlGMOK9cPiF7RDWQ1ihssqfw5tsWN+dlsCWE61vev7Y9avYgcMNz +Hjg== 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=8FMQLsUcD9MZKQUga+4XNsejCjjiwF/LjjLTbdyynvA=; b=GA2Sd9V8XB/D4HNjMcfZczsre6ScnogfvR+rnI2pY5FUtCh1E1q466Iu2WkojNPSiG NPSujyxqK5GNS5ZFdOCWXHbLLOKH0klRY0huho4XboaOgnw6Leh9rdmsM91UPCG0Nb6y 5Rv8hpTVHXfTWtOMU/WGXghU3cWcSShYSgHiybOErCmt0so4uXuLBjPqSPX40XXPovxf cTM8tFfxnjUVW7bUVtQJhDZSpOiFe0XLkfYp1komiuqU4+VUIlz8GNV7pJvoQnMibTTD Ute3ieZElCjZ5qN0q82Y39UE40BpNsN81yinSyG15zUBmBCSi825YbKdO3rV+ULzAHC5 DYaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-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 j6si2874324ejm.157.2019.09.18.07.24.10; Wed, 18 Sep 2019 07:24:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-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-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730457AbfIROXP (ORCPT + 99 others); Wed, 18 Sep 2019 10:23:15 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:53198 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1730211AbfIROXP (ORCPT ); Wed, 18 Sep 2019 10:23:15 -0400 Received: (qmail 2743 invoked by uid 2102); 18 Sep 2019 10:23:14 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Sep 2019 10:23:14 -0400 Date: Wed, 18 Sep 2019 10:23:14 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Abhishek Pandit-Subedi cc: linux-bluetooth@vger.kernel.org, , , Kai-Heng Feng , Hui Peng , , Johan Hedberg , Suzuki K Poulose , Mark Brown , "Rafael J. Wysocki" , Wolfram Sang , , Marcel Holtmann , Len Brown , Mathias Payer , Dmitry Torokhov , Greg Kroah-Hartman , Mans Rullgard , Pavel Machek , YueHaibing Subject: Re: [PATCH 0/2] Reset realtek bluetooth devices during user suspend In-Reply-To: <20190917212702.35747-1-abhishekpandit@chromium.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org On Tue, 17 Sep 2019, Abhishek Pandit-Subedi wrote: > On a Realtek USB bluetooth device, I wanted a simple and consistent way > to put the device in reset during suspend (2 reasons: to save power and > disable BT as a wakeup source). Resetting it in the suspend callback > causes a detach and the resume callback is not called. Hence the changes > in this series to do the reset in suspend_noirq. What about people who _want_ BT to be a wakeup source? Why does putting the device in reset save power? That is, a suspended device is very strictly limited in the amount of current it's allowed to draw from the USB bus; why should it draw significantly less when it is reset? > I looked into using PERSIST and reset on resume but those seem mainly > for misbehaving devices that reset themselves. They are, but that doesn't mean you can't use them for other things too. > This patch series has been tested with Realtek BT hardware as well as > Intel BT (test procedure = disable as wake source, user suspend and > observe a detach + reattach on resume). This series really seems like overkill for a single kind of device. Is there any way to turn off the device's BT radio during suspend (if wakeup is disabled) and then turn it back on during resume? Wouldn't that accomplish what you want just as well? Alan Stern