Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752660AbeABKGj convert rfc822-to-8bit (ORCPT + 1 other); Tue, 2 Jan 2018 05:06:39 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:42079 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbeABKGh (ORCPT ); Tue, 2 Jan 2018 05:06:37 -0500 X-Google-Smtp-Source: ACJfBovvvmOUcElpmN8C1xflKsRVGudnY3y+RXJUhKbbqOlPBVaZGCTAfW4YdyvXlO77syN1n3jgww== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" From: Kai Heng Feng In-Reply-To: Date: Tue, 2 Jan 2018 18:06:30 +0800 Cc: Brian Norris , Greg Kroah-Hartman , Marcel Holtmann , Linux USB Mailing List , Linux Bluetooth mailing list , Linux Kernel , stable@vger.kernel.org, Leif Liddy , Matthias Kaehlcke , Guenter Roeck Content-Transfer-Encoding: 8BIT Message-Id: <26F3D10E-A72A-400D-BD07-1F4AFF109417@canonical.com> References: <20171220110008.11856-1-kai.heng.feng@canonical.com> <20171220185308.GA176644@google.com> To: Daniel Drake X-Mailer: Apple Mail (2.3445.5.20) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > On 21 Dec 2017, at 7:43 PM, Daniel Drake wrote: > > On Wed, Dec 20, 2017 at 6:53 PM, Brian Norris wrote: >> >> On Wed, Dec 20, 2017 at 07:00:07PM +0800, Kai-Heng Feng wrote: >>> This commit causes a regression on some QCA ROME chips. The USB device >>> reset happens in btusb_open(), hence firmware loading gets interrupted. >> >> Oh, did you really confirm that's the root of the problem? I was only >> hypothesizing, with some informed observation and code review; but I >> didn't fully convince myself. If so, that's interesting. > > I have the same doubt. Can you explain how/why firmware uploading and > btusb_open() overlap, and how this is avoided with your patch? QCA ROME chip uploads its firmware inside btusb_open(). The behavior is like below: - btusb_probe() - btusb_open() - btusb_suspend(), reset_resume gets set. - btusb_open() again, hub resets the device, then the issue happens. I didn’t dig really deep for the issue, I simply tried usb core quirks, it reset the USB device before btusb_probe(). It might be that using the USB quirk only papers over the real issue. > If they do overlap, is that not a bug in the stack that should be fixed instead? > If the fix belongs in btusb and this BTUSB_RESET_RESUME thing really > is problematic, should it be totally removed instead? I think so. That’s why I need some insight from the original patch author. Kai-Heng > > Daniel