Patch "Bluetooth: fix use-bdaddr-property quirk" has been added to the 6.1-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    Bluetooth: fix use-bdaddr-property quirk

to the 6.1-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     bluetooth-fix-use-bdaddr-property-quirk.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit b5ef8fa54bf7cc8962c4f9a9d0b340eb77f1e7fa
Author: Johan Hovold <johan+linaro@xxxxxxxxxx>
Date:   Wed May 31 11:04:24 2023 +0200

    Bluetooth: fix use-bdaddr-property quirk
    
    [ Upstream commit 6945795bc81ab7be22750ecfb365056688f2fada ]
    
    Devices that lack persistent storage for the device address can indicate
    this by setting the HCI_QUIRK_INVALID_BDADDR which causes the controller
    to be marked as unconfigured until user space has set a valid address.
    
    The related HCI_QUIRK_USE_BDADDR_PROPERTY was later added to similarly
    indicate that the device lacks a valid address but that one may be
    specified in the devicetree.
    
    As is clear from commit 7a0e5b15ca45 ("Bluetooth: Add quirk for reading
    BD_ADDR from fwnode property") that added and documented this quirk and
    commits like de79a9df1692 ("Bluetooth: btqcomsmd: use
    HCI_QUIRK_USE_BDADDR_PROPERTY"), the device address of controllers with
    this flag should be treated as invalid until user space has had a chance
    to configure the controller in case the devicetree property is missing.
    
    As it does not make sense to allow controllers with invalid addresses,
    restore the original semantics, which also makes sure that the
    implementation is consistent (e.g. get_missing_options() indicates that
    the address must be set) and matches the documentation (including
    comments in the code, such as, "In case any of them is set, the
    controller has to start up as unconfigured.").
    
    Fixes: e668eb1e1578 ("Bluetooth: hci_core: Don't stop BT if the BD address missing in dts")
    Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 37131a36700a1..9f9299b44f0bf 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -4564,16 +4564,14 @@ static int hci_dev_setup_sync(struct hci_dev *hdev)
 	 * BD_ADDR invalid before creating the HCI device or in
 	 * its setup callback.
 	 */
-	invalid_bdaddr = test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks);
-
+	invalid_bdaddr = test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) ||
+			 test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
 	if (!ret) {
 		if (test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks) &&
 		    !bacmp(&hdev->public_addr, BDADDR_ANY))
 			hci_dev_get_bd_addr_from_property(hdev);
 
-		if ((invalid_bdaddr ||
-		     test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) &&
-		    bacmp(&hdev->public_addr, BDADDR_ANY) &&
+		if (invalid_bdaddr && bacmp(&hdev->public_addr, BDADDR_ANY) &&
 		    hdev->set_bdaddr) {
 			ret = hdev->set_bdaddr(hdev, &hdev->public_addr);
 			if (!ret)



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux