Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3337145ybd; Tue, 25 Jun 2019 00:30:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqwA2MDBIIUzZnhFBv086mgU3rilfebbQqX07Gx2Bkdd89QrgU8bR6jwi0Q5IbXDLOeTUNzU X-Received: by 2002:a63:610e:: with SMTP id v14mr638309pgb.221.1561447809579; Tue, 25 Jun 2019 00:30:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561447809; cv=none; d=google.com; s=arc-20160816; b=dgVBBSNUKY2z8U+GAYtBNa+mfmNnUlG4gzE/L87Y4W06FWED69IyIVjDLpESZWWemV gGU/s7wT267UwlN3C1Gu5WK/VOjDG6fY1X0DR9atLxuS1Vo1228i2ehG6ri13vC5b3/Q MhitHXhfALtEAr3pTrTWMtJFN4bfYeTcOGCDe+eVli0o3r/GCSNl0NFQ4R7vhVdKeBq9 3Vk8nCD31cH2x1ZJT90MGuSJ5rXnAVWkUIWXLD9IpulLBTOrNGcEjKGO8Qd1cSd10dIw mowgDjB4KP/V+5siqEJqBXJPh98IGyG9aA8OruV7lnGnM6EwaSPKHzgGCbp7CqyzqGxA qqog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=LhuDpJcyU9NWnJ06xCAtUd3+TxkSg1xi/FRYZf9ug04=; b=H5xEl0aN3oP6G5XOVYJjPOLcbu6brgdIoiKvslfAJ7oETya4TtpIQWJsqwuSJadRmm resbIZ2xN3gooIPC+pps2rtF0g91yW3aZ++5n/Df2ldVMx9MDea/l6q5oRoWDspPX8tm /572XvGzKfXwXRZxKg0s2oW5OdZsMazKBQTn/0rlRcg58nY1WHU/s+WZl5btxkGmhkVr cTBqa1tDCKaLvK6bAexSq7iRCFYbCEfRSTYQDI8aMXDMBFCMbTNpGiEsMKpz7NIIDHVP u7JU4Hqqkvo265onyMo4yNg6HW0KVdG8Spb0+A5rnZq5nXUSDv/IJ7t13vrmg46Whg7F ZkpQ== 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 g12si2028288pjs.67.2019.06.25.00.29.52; Tue, 25 Jun 2019 00:30:08 -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 S1728454AbfFYFnG convert rfc822-to-8bit (ORCPT + 99 others); Tue, 25 Jun 2019 01:43:06 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:33704 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726533AbfFYFnG (ORCPT ); Tue, 25 Jun 2019 01:43:06 -0400 Received: from marcel-macpro.fritz.box (p4FEFC3D2.dip0.t-ipconnect.de [79.239.195.210]) by mail.holtmann.org (Postfix) with ESMTPSA id 5349FCF2B1; Tue, 25 Jun 2019 07:51:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH v2] Bluetooth: btrtl: HCI reset on close for Realtek BT chip From: Marcel Holtmann In-Reply-To: Date: Tue, 25 Jun 2019 07:43:03 +0200 Cc: Jian-Hong Pan , Johan Hedberg , Linux Bluetooth mailing list , Linux Kernel Content-Transfer-Encoding: 8BIT Message-Id: References: <20190624062114.20303-1-jian-hong@endlessm.com> To: Daniel Drake X-Mailer: Apple Mail (2.3445.104.11) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, >> Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly >> after on-off several times. Bluetooth daemon sets BT mode failed when >> this issue happens. > > You could also mention that scanning must be active while turning off > for this bug to be hit. > >> bluetoothd[1576]: Failed to set mode: Failed (0x03) >> >> If BT is tunred off, then turned on again, it works correctly again. > > Typo: turned > >> According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set >> during probing. So, this patch makes Realtek's BT reset on close to fix >> this issue. > > Checked the vendor driver - I see what you are referring to, so the > change seems correct. > > #if HCI_VERSION_CODE >= KERNEL_VERSION(3, 7, 1) > if (!reset) > set_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks); > RTKBT_DBG("set_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks);"); > #endif > > However I'm pretty sure this is not saying that kernel 3.7.0 did not > need the reset. I think it just means that the flag did not exist > before Linux-3.7.1, so they added the ifdef to add some level of > compatibility with older kernel versions. I think you can remove > "since kernel v3.7.1." from the comment. > > After those changes you can add: > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429 > Reviewed-by: Daniel Drake if someone wants to use HCI_Reset to ensure that all their connections and radio usage is reset, then they should do that via the hdev->shutdown handler. Look at btusb.c if you need an example. This quirk is for hardware that can not use HCI_Reset on init which is Bluetooth 1.0b hardware. Regards Marcel