On Tue, Apr 23, 2024 at 08:09:55AM -0700, Doug Anderson wrote: > On Tue, Apr 23, 2024 at 2:08 AM Johan Hovold <johan@xxxxxxxxxx> wrote: > > On Mon, Apr 22, 2024 at 10:50:33AM -0700, Doug Anderson wrote: > > > On Tue, Apr 16, 2024 at 2:17 AM Johan Hovold <johan+linaro@xxxxxxxxxx> wrote: > > > > > > As Chromium is the only known user of the 'local-bd-address' property, > > > > could you please confirm that your controllers use the 00:00:00:00:5a:ad > > > > address by default so that the quirk continues to be set as intended? > > > > > > I was at EOSS last week so didn't get a chance to test this, but I > > > just tested it now and I can confirm that it breaks trogdor. It > > > appears that trogdor devices seem to have a variant of your "default" > > > address. Instead of: > > > > > > 00:00:00:00:5a:ad > > > > > > We seem to have a default of this: > > > > > > 39:98:00:00:5a:ad > > > > > > ...so almost the same, but not enough the same to make it work with > > > your code. I checked 3 different trogdor boards and they were all the > > > same, though I can't 100% commit to saying that every trogdor device > > > out there has that same default address... > > > > > > Given that this breaks devices and also that it's already landed and > > > tagged for stable, what's the plan here? Do we revert? Do we add the > > > second address in and hope that there aren't trogdor devices out in > > > the wild that somehow have a different default? > > > > This patch is currently queued for 6.10 so there should be time to get > > this sorted. > > > > My fallback plan was to add further (device-specific) default addresses > > in case this turned out to be needed (e.g. this is what the Broadcom > > driver does). The offending commit was just sent on to the networking tree for 6.9 so I went ahead and added the Trogdor default address to the address check for now: https://lore.kernel.org/r/20240425075503.24357-1-johan+linaro@xxxxxxxxxx/ We can always amend this later if it turns out to be needed. > > I assume all Trogdor boards use the same controller, WCN3991 IIUC, but > > if you're worried about there being devices out there using a different > > address we could possibly also use the new > > "qcom,local-bd-address-broken" DT property as an indicator to set the > > bdaddr quirk. > > They all should use the same controller, but I'm just worried because > I don't personally know anything about how this address gets > programmed nor if there is any guarantee from Qualcomm that it'll be > consistent. There are a whole pile of boards in the field, so unless > we have some certainty that they all have the same address it feels > risky. Hopefully Janaki and Qualcomm will provide some answers soon. And otherwise we have another fall back in that we can use the "qcom,local-bd-address-broken" property for Trogdor. > > We have Qualcomm on CC here so perhaps Janaki, who should have access to > > the documentation, can tell us what the default address on these older > > controllers looks like? > > > > Janaki, are there further default addresses out there that we need to > > consider? > > > > Perhaps "39:98" can even be inferred from the hardware id somehow (cf. > > bcm4377_is_valid_bdaddr())? > > > > Doug, could you please also post the QCA version info for Trogdor that's > > printed on boot? > > You want this: > > [ 9.610575] ath10k_snoc 18800000.wifi: qmi chip_id 0x320 > chip_family 0x4001 board_id 0x67 soc_id 0x400c0000 > [ 9.620634] ath10k_snoc 18800000.wifi: qmi fw_version 0x322102f2 > fw_build_timestamp 2021-08-02 05:27 fw_build_id > QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 > [ 14.607163] ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target > 0x00000008 chip_id 0x00000000 sub 0000:0000 > ...or this... > > [ 12.899095] Bluetooth: hci0: setting up wcn399x > [ 13.526154] Bluetooth: hci0: QCA Product ID :0x0000000a > [ 13.531805] Bluetooth: hci0: QCA SOC Version :0x40010320 > [ 13.537384] Bluetooth: hci0: QCA ROM Version :0x00000302 > [ 13.543002] Bluetooth: hci0: QCA Patch Version:0x00000de9 > [ 13.565775] Bluetooth: hci0: QCA controller version 0x03200302 Thanks, the Bluetooth driver output was what I was looking for but the wifi output may also provide some insight. > Just as a random guess from looking at "8" in the logs, maybe the > extra 8 in 3998 is the "target" above? Yeah, possibly, but it seems we won't be able to use the version info without further details from Qualcomm. > ...though that also makes me think that perhaps this chip doesn't > actually have space for a MAC address at all. Maybe they decided to > re-use the space to store the hardware ID and other information on all > of these devices? All of these controllers apparently have storage for the hardware ids so I'd be surprised if they didn't have room also for the address. Looking at the backstory for this, it seems like Qualcomm intentionally broke the bdaddr quirk so that controllers which had been provisioned with a valid address would continue to work back when WCN3990 was the only device that set the quirk. So presumably WCN3990 and later controllers all have OTP storage for the address (even if I guess in theory it could have been done just for, say, WCN3998 which was added just after): 5971752de44c ("Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990") (2019-02-19, matthias) e668eb1e1578 ("Bluetooth: hci_core: Don't stop BT if the BD address missing in dts") (2019-04-18, qcom) 523760b7ff88 ("Bluetooth: hci_qca: Added support for WCN3998") (2019-04-26, qcom) Johan
