ath11k: incorrect board_id retrieval

[Seevalamuthu M (QUIC)]

Hi Sven,

> -----Original Message-----
> From: ath11k <ath11k-bounces at lists.infradead.org> On Behalf Of Sven
> Eckelmann
> Sent: Friday, November 26, 2021 8:18 PM
> To: ath11k at lists.infradead.org
> Subject: ath11k: incorrect board_id retrieval
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> 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?


[seevalam] : Incase of QCN9074 in x86 setup, need to program OTP with board_id. Please fuse board id in OTP and try.

> 
> 
> 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath11k[seevalam] 

Regards,
Seevalamuthu M