ath10k fail to load firmware

[Michal Kazior]

On 2 August 2016 at 14:10, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> On 19 July 2016 at 09:09, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>> Perry from Dell has ath10k device, which do not work with current
>>> linux-firmware. It's on RHEL kernel, however wirelss stack and drivers
>>> are from 4.7-rc1 (I did not update to 4.7 final yet, since I do not see
>>> ath10k fix, which could possibly help here). Partial dmesg is in
>>> the attachment.
>>
>> hw.3 qca6174 chips tend to require very specific board data for proper
>> calibration.
>>
>>   [ 3838.601884] ath10k_pci 0000:01:00.0: failed to fetch board data
>> for bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,subsystem-device=0310
>> from ath10k/QCA6174/hw3.0/board-2.bin
>>   [ 3838.601920] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>> crc32 ed5f849a
>>
>> Your board-2.bin doesn't contain the matching board data and the
>> driver then falls back to the older board API1 which is pretty much
>> doomed to fail on qca6174 hw.3.
>>
>> @Kalle: Perhaps ath10k needs to fail early with an adequate message
>> for qca6174 hw.3 if board API2 lookup fails (e.g. hw_params flag
>> because this seems to be quite closely coupled with hardware itself).
>
> Sounds like a good idea. Or maybe we should always fail when using
> board-2.bin (no matter what hw version is used)? Dunno.

Hmm, failing if no matching entry is found in board-2.bin sounds good
but doesn't cover the case when user doesn't even have board-2.bin in
the first place.

The downside of forcing board-2.bin for qca6174 hw3.2+ would be more
difficult one-shot testing via board.bin (it's easier to copy eeprom*
file from windows driver as board.bin than to re-generate board-2.bin)
- but maybe this isn't really something we should care about so much
to allow board.bin for hw that normally can't work with it.


Michał