Some devices differ slightly and require different
board files. If wrong board data is used they
crash or behave incorrectly.
These devices can be differentiated by looking at
PCI subsystem device id. That is the case for
qca61x4 devices at least.
The board specific filename is constructed as:
board-<bus>-<id>.bin
For PCI in particular it is:
board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin
These files are looked in device/hw specific
directories. Hence for Killer 1525 (qca6174 hw2.1)
ath10k will request:
/lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin
To not break any existing setups (e.g. in case
some devices in the wild already have subsys ids)
if a board specific file isn't found a generic one
is used which is the one which would be used until
now. This guarantees that after upgrading a driver
device will not suddenly stop working due to
now-missing specific board file. If this is the
case a "fallback" string is appended to the info
string when driver boots.
Keep in mind this is distinct from cal-pci-*.bin
files which contain full calibration data and MAC
address. Cal data is aimed at systems where
calibration data is stored out of band, e.g. on
nand flash instead of device EEPROM - an approach
taken by some AP/router vendors.
Board files are more of a template and needs some
bits to be filled in by the OTP program using
device EEPROM contents.
One could argue to map subsystem ids to some board
design codename strings instead of using raw ids
when building the board filename. Using a mapping
however would make it a lot more cumbersome and
time consuming (due to how patches propagate over
various kernel trees) to add support for some new
device board designs. Adding a board file is a lot
quicker and doesn't require recompilation.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
de57e2c8e1