Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp244324ybc; Tue, 19 Nov 2019 00:16:46 -0800 (PST) X-Google-Smtp-Source: APXvYqwqHGOeZ6ToEe3Zt3BmEfwdacnfEL1pNtyq3IgCAWQ/ee5Ph1dEFNuROJjbqf4RdwQaDRJX X-Received: by 2002:a17:906:5397:: with SMTP id g23mr32176351ejo.93.1574151406021; Tue, 19 Nov 2019 00:16:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574151406; cv=none; d=google.com; s=arc-20160816; b=LhY5uZySh5PwpGP131b/4BghoSr4l3TvVfAuivPKAiJ1D+Tye/OLZ866HMa+CAV9IE MMGtIP0j7/A7YXOozAscstsRD6JlG20ApU6y7dDlcz4UrrjPNhK6/R1r8NhA7z7eCDbC 0U1pGSfnUs5cjLKnldyONKeHpW0LJMoawkv/F1s29ceKi6pYHXQ8ZGjWC26j0wIdETkH 98uU8PPOzUI5XbtTglAyBFJ1sfoXrctsVzRWc3UvJFw3B77lH5SlPjgUh9F5f/LwKnN3 X949jEW99U9LtN5ar1u+mID4PSC5Yn67eAbUHPFTuP4PmAgO7HJuvOm+pNlZ/0tNinSj jQLw== 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=uIH5bSSNQkILZo2q9CVrgjrXhJJ6l4bfcY4wuDDuYrg=; b=fioT5zVGKsI3mn6/HdwkhulYFIGeUxPPk2ks2CfPstWtqHI7BO83HyonX37dt1ULzz IJD5zxfQnnnFZJTBntVFlUBKIDc2NIZCmst0bWOQb4ulcafenIjgDxqOlBYnxeZAtiCT AU0a+wXnXWtWYuPNUi+tbMk3TLyw8A74PTn+gVl2Zso/7fQuS7D6cndF7rS8MqPW3wNF pjoBYZfeSzpJpYN3hWSp/u/xy5J4eon6Bjv2YbNNGFDWs5jeHOLWrd/5Jr0Gb08XbyhT d0nzvnEqaPbNI7qteKkP8fxT/ousE4kSu+niC31KmdFXTfxX6RHrYhzBi8iczM4/u97w KNsg== 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 ob19si14105279ejb.56.2019.11.19.00.16.08; Tue, 19 Nov 2019 00:16:46 -0800 (PST) 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 S1725815AbfKSIQF convert rfc822-to-8bit (ORCPT + 99 others); Tue, 19 Nov 2019 03:16:05 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:48384 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725306AbfKSIQF (ORCPT ); Tue, 19 Nov 2019 03:16:05 -0500 Received: from marcel-macbook.holtmann.net (p4FF9F0D1.dip0.t-ipconnect.de [79.249.240.209]) by mail.holtmann.org (Postfix) with ESMTPSA id F1362CECEF; Tue, 19 Nov 2019 09:25:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: [PATCH v2] bluetooth: bcm: Use HCI_QUIRK_USE_BDADDR_PROPERTY From: Marcel Holtmann In-Reply-To: Date: Tue, 19 Nov 2019 09:16:03 +0100 Cc: Johan Hedberg , linux-bluetooth@vger.kernel.org, Ondrej Jirman , Jernej Skrabec Content-Transfer-Encoding: 8BIT Message-Id: References: <20191119060221.3297340-1-a.heider@gmail.com> <4DB6C9B7-8454-449C-90B4-4A1B3AD82495@holtmann.org> To: Andre Heider X-Mailer: Apple Mail (2.3601.0.10) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Andre, >>> Some devices ship with the controller default address, like the >>> Orange Pi 3 (BCM4345C5). >>> >>> Allow the bootloader to set a valid address through the device tree. >>> >>> Signed-off-by: Andre Heider >>> --- >>> drivers/bluetooth/btbcm.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c >>> index 2d2e6d862068..9d16162d01ea 100644 >>> --- a/drivers/bluetooth/btbcm.c >>> +++ b/drivers/bluetooth/btbcm.c >>> @@ -439,6 +439,7 @@ int btbcm_finalize(struct hci_dev *hdev) >>> btbcm_check_bdaddr(hdev); >>> >>> set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks); >>> + set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); >>> >>> return 0; >>> } >> have you actually tested this? I might be mistaken, but the code that I read in hci_dev_do_open() would drop this into unconfigured state since HCI_QURIK_INVALID_BDADDR is still set. > > I thought so, but double-checking something obviously failed... > > What would be an acceptable solution to this HCI_QUIRK_USE_BDADDR_PROPERTY|HCI_QUIRK_INVALID_BDADDR situation? > > Getting rid of the quirk in the driver in e.g. set_bdaddr() doesn't sound right. > > How about: > > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c > index 04bc79359a17..7bc384be89f8 100644 > --- a/net/bluetooth/hci_core.c > +++ b/net/bluetooth/hci_core.c > @@ -1470,7 +1470,8 @@ static int hci_dev_do_open(struct hci_dev *hdev) > * start up as unconfigured. > */ > if (test_bit(HCI_QUIRK_EXTERNAL_CONFIG, &hdev->quirks) || > - test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks)) > + (test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) && > + !test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks))) > hci_dev_set_flag(hdev, HCI_UNCONFIGURED); > > /* For an unconfigured controller it is required to > > That works for me (double-checked this time ;) I am not sure yet. I mean we define what HCI_QUIRK_USE_BDADDR_PROPERTY actually means. Right now it means this: 1) Run though ->setup 2) If no public BD_ADDR is set, then try to read from DT 3) If found, try to set, if set fails, abort dev_up Now there is also another problem that no public BD_ADDR means BDADDR_ANY right now. Which means, for Broadcom chips that is never the case. So HCI_QUIRK_USE_BDADDR_PROPERTY doesn’t even work since their invalid addresses are not BDDADDR_ANY. The first change needs to be something along these lines: if (test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) { - if (!bacmp(&hdev->public_addr, BDADDR_ANY)) + if (!bacmp(&hdev->public_addr, BDADDR_ANY) || + test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks)) hci_dev_get_bd_addr_from_property(hdev); But that is not fully correct either. We also have to consider HCI_QUIRK_NON_PERSISTENT_SETUP. So this is not an easy fix since we need to spell out the semantics of the interactions of these 3 quirks first. Regards Marcel