ath11k: incorrect board_id retrieval

From: Sven Eckelmann <sven@narfation.org>
To: ath11k@lists.infradead.org
Subject: ath11k: incorrect board_id retrieval
Date: Fri, 26 Nov 2021 15:48:17 +0100	[thread overview]
Message-ID: <1734146.k9CKHTOI9D@ripper> (raw)

Hi,

I've noticed that manufacturers of cards gave me various information what 
board_id they expected a device (QCN9074) is detected as. But ath11k only 
retrieves the board id as 0xff - thus the ath11k driver is always loading the 
wrong BDF. Commercially available boards with a problem like this are:

* 8devices Pineapple
  - 2GHz: 160 (0xa0)
  - 5GHz: 161 (0xa1)
  - 6GHz: 162 (0xa2)
* Compex WLE3000H5
* (maybe there is not a single one which works?)

If I would use these boards in one with a devicetree then I could just 
overwrite it using qcom,board_id (and/or qcom,ath11k-calibration-variant). But 
this isn't the case when I want to use a couple of these cards in a simple x86 
system. All off them (even when they are significantly different) are reported
as

    ath11k_pci 0000:03:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff

So I would have to hack the driver to implement my own (pci id? based)
board.bin retrieval code.

So my question would be: Is the ath11k based board_id retrieval just broken? 
Or are these cards broken?

The way the firmware is initialized definitely changed between ath10k and 
ath11k. Previously, the otp.bin took care of retrieving the (pre-cal) data 
from the EEPROM/OTP on the card or retrieved it via driver from the host 
systems flash/filesystem. And then the otp.bin was reporting the board_id to 
the driver. Based on that, the driver was able to select the correct BDF.

But now, the firmware is started and immediately afterwards, it is already 
asked to report the target capabilities. And the target capabilities are 
including the board_id - the part which doesn't seem to work correctly. Only 
after that, the driver sends the BDF + (pre)caldata. So the firmware (if the 
precaldata comes from the flash/filesystem) doesn't have the chance to get the 
board_id [1] from the (pre)caldata. Which sounds wrong to me. But I have no
access to anything which would allow me to check how it should actually work.

Kind regards,
	Sven

[1] i think it was the refDesignId, projectId or something like this in ath10k

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k