On 2 August 2016 at 14:10, Valo, Kalle <[email protected]> wrote: > Michal Kazior <[email protected]> writes: > >> On 19 July 2016 at 09:09, Stanislaw Gruszka <[email protected]> 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ł _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
