Steev , inline comments! > >This patch adds support for QCA2066 firmware patch and nvm downloading. > > Is this actually correct? I ask because here I have the WCN6855 in the Lenovo Thinkpad X13s, and when attempting to use this driver, I end up with a board id of 08c, and according to the firmware, we should have a board id of b8c. > > [Tim] correct, I does not know where you get the WCN6855 firmware, for our side, we will use different name rule for android and linux , for android , we will add "b" in the front of board id, for linux we will not add this bit. So, the Thinkpad X13s is... well, it's a Thinkpad, and it comes with Windows. So the firmware that we have, comes from.... them? qc? [Tim] yeah , for wos , btfw name seems also the same with android. I think come from qc I honestly don't know the provenance of it, just that I grabbed the files from the Windows partition: So, all of the nvm patches that are provided by them with the windows driver, all start with 'b'. > I'm not sure how to phrase this, and just thinking out loud - if the qca2066 is the same as the wcn6855, just with an additional antenna, perhaps there should be some way to indicate it? In my patchset, I had a print of the name "Setting up wcn6855" and locally, I combined your patch with mine, although dropping the above qca2066 hunks in favor of my already written wcn6855 hunks, and then combined the two in the print so it says "Setting up qca2066/wcn6855" - is there any way to differentiate between what qti considers a qca2066 and what is considered the wcn6855? > [Tim] steve ,as I mentioned previously, we have different board id for qca2066 and wcn6855 , and then which will use different nvm config files based on board id. > I get that; I'm thinking of end users, who may know that they have a wcn6855, but if the messages are qca2066, they may not understand that it's the same chip. [Tim] I see, wcn6855 and qca2066 is belong to "hsp" btchip family , so maybe we can use "hsp" to instead. > Below is dmesg output, and so if we go by the wifi device check, we > end up seeing that we get > > chip_id 0x2 > chip_family 0xb > board_id 0x8c > soc_id 0x400c0210 > > > But with your driver (mine too for that matter, but then it's just doing the same bid bits)... > > [ 9.081003] Bluetooth: hci0: Frame reassembly failed (-84) > [ 9.141992] Bluetooth: hci0: QCA Product ID :0x00000013 > [ 9.141999] Bluetooth: hci0: QCA SOC Version :0x400c0210 > [ 9.142003] Bluetooth: hci0: QCA ROM Version :0x00000201 > [ 9.142007] Bluetooth: hci0: QCA Patch Version:0x000038e6 > [ 9.170612] Bluetooth: hci0: QCA controller version 0x02100201 > [ 9.170620] Bluetooth: hci0: QCA Downloading qca/hpbtfw21.tlv > > > [ 9.760537] Bluetooth: hci0: QCA board ID len 2,id = 0 8c > [ 9.760547] Bluetooth: hci0: QCA Downloading qca/hpnv21.08c > [ 9.760638] bluetooth hci0: Direct firmware load for qca/hpnv21.08c failed with error -2 > [ 9.760640] Bluetooth: hci0: QCA Failed to request file: qca/hpnv21.08c (-2) > [ 9.760643] Bluetooth: hci0: QCA Failed to download NVM (-2) > > Is there another way to check the board id or board family? Because it's not coming up with the correct one here. > [Tim] as my comments above, the read board id way is correct, only we have different name rule for android and linux . Right, I get that reading the board id is the right way - and if you see in my Windows firmware above (the firmware submitted to linux-firmware by you only seems to have nvm patches that start with '3', and no others..) I'm saying, should we also read the chip_family somehow, since the WiFi firmware seems to properly notice that we are chip_family 0xb, however, the bluetooth driver just returns '0'. And neither the submitted firmware, nor the firmware that Lenovo/Qualcomm ship to Windows users, have nvm patches that start with 0. [Tim] we detect the chip_family by detect product_id and soc_id , such as for "hsp" chip family, if product id equal 0x13 ,and soc_id & 0xffff0000 == 0x400c , we assume this chip is "hsp". You can refer the log as above. An additional note, neither my driver, nor yours, seems to work with BLE. I cannot connect a pair of AirPods to my Thinkpad in Linux, but I am able to do just fine in the Windows installation. I'm not sure if this is a known limitation already in linux or not. [Tim] I am not sure, maybe have IOT issue, need to check it case by case. > > --steev
