Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3616459pxb; Mon, 25 Jan 2021 23:34:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzXZvkBi3aoijjzG0qKVmBgYKHP0h2VGLcPLENG468wu2d2uEPK9KEw8mWLOkC2EiQiZnhK X-Received: by 2002:aa7:d1d4:: with SMTP id g20mr3579009edp.244.1611646451609; Mon, 25 Jan 2021 23:34:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611646451; cv=none; d=google.com; s=arc-20160816; b=RMAzci2oC3GR+f7AMmffuE9jM4ZpHSwhGS9QzG7MScUKl2eHo/CtkzzIXMyvvHihuq dlvlnT7hqIAA189mBrAvC47w9W/o4BCT9uaFwfTTYLurPCZsFLorPWuIwCvEdKcdMLqq AjAvynbc6gD6vtq0sGSeOAu3FocV323b4TdRN4kVGL6MDrFhCVxgfma1Bg9a3JTyUr5A +Jy3dGCuKdyQms/sWFZkwNCTKoSdeynpmz/Is/n+Iv6WfMfoJ8Lb7tqWg1dSQ6J4u5Nu d9lBafwjmkp7BoYJExEaFe5sXWvXTJGRhdLXvebNblXLFzqpuK3UzabVoqXFsSKtX+T2 sjIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=TdO95X6KUrpfV8sBkTSJZKOINBAsVOmT98PqUI/0QKY=; b=Sdm/xv3i2TZeLobKPZNVd5J6hSpOLIecT6RDnC1idNP/uA7tSR6UgsiuILIPYmRf3a dVcI2urnWdfFBtjrfdkmN0bNKiDxncIFwMn+WgjvbDwxp7pQUJF+YMIfX1DLBjQMW8qi fnCAdv9kg0V4Zg7ykU+O3z+KzhRXs5WR+vLpbo0InTdC8BZDB6lq0hyew6Kvk7lSPqyE kqg/f1GtGdysdpQjoRszuUcIgBx8lxV0l5DFl211uAYAT68WcGmadZeIqNri/FMxJ7fy umNW8AQbFZy6UvNY0vcfplmzuSdvQKCJwEx1LIngfgoKV0wNKpcGEnwmzMG7nGLItDQg j7vQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bc26si8353557edb.508.2021.01.25.23.33.47; Mon, 25 Jan 2021 23:34:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731975AbhAZHar convert rfc822-to-8bit (ORCPT + 99 others); Tue, 26 Jan 2021 02:30:47 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:48839 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730379AbhAYPq7 (ORCPT ); Mon, 25 Jan 2021 10:46:59 -0500 Received: from marcel-macbook.holtmann.net (p4ff9f11c.dip0.t-ipconnect.de [79.249.241.28]) by mail.holtmann.org (Postfix) with ESMTPSA id EAD99CECCA; Mon, 25 Jan 2021 16:20:27 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: [PATCH v3] Bluetooth: Keep MSFT ext info throughout ahci_dev's life cycle From: Marcel Holtmann In-Reply-To: <20210121163801.v3.1.Id9bc5434114de07512661f002cdc0ada8b3d6d02@changeid> Date: Mon, 25 Jan 2021 16:13:02 +0100 Cc: Bluetooth Kernel Mailing List , Alain Michaud , Archie Pusaka , Luiz Augusto von Dentz , Abhishek Pandit-Subedi , "David S. Miller" , Johan Hedberg , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <070E7413-A3E3-4FEB-80BC-D3DD922DA19B@holtmann.org> References: <20210121163801.v3.1.Id9bc5434114de07512661f002cdc0ada8b3d6d02@changeid> To: Miao-chen Chou X-Mailer: Apple Mail (2.3654.40.0.2.32) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Miao-chen, > This moves msft_do_close() from hci_dev_do_close() to > hci_unregister_dev() to avoid clearing MSFT extension info. This also > avoids retrieving MSFT info upon every msft_do_open() if MSFT extension > has been initialized. > > The following test steps were performed. > (1) boot the test device and verify the MSFT support debug log in syslog > (2) restart bluetoothd and verify msft_do_close() doesn't get invoked > > Signed-off-by: Miao-chen Chou > Reviewed-by: Abhishek Pandit-Subedi > Reviewed-by: Archie Pusaka > --- > Hi Maintainers, > > This patch fixes the life cycle of MSFT HCI extension. The current > symmetric calls to msft_do{open,close} in hci_dev_do_{open,close} cause > incorrect MSFT features during bluetoothd start-up. After the kernel > powers on the controller to register the hci_dev, it performs > hci_dev_do_close() which call msft_do_close() and MSFT data gets wiped > out. And then during the startup of bluetoothd, Adv Monitor Manager > relies on reading the MSFT features from the kernel to present the > feature set of the controller to D-Bus clients. However, the power state > of the controller is off during the init of D-Bus interfaces. As a > result, invalid MSFT features are returned by the kernel, since it was > previously wiped out due to hci_dev_do_close(). then just keep the values around and not wipe them. However I prefer still to keep the symmetry and re-read the value every time we init. We can make sure to release the msft_data on unregister. Regards Marcel