1. 30 11月, 2015 3 次提交
  2. 23 11月, 2015 1 次提交
  3. 05 11月, 2015 1 次提交
  4. 29 10月, 2015 3 次提交
  5. 14 10月, 2015 2 次提交
    • M
      ath10k: select board data based on BMI chip id and board id · db0984e5
      Manikanta Pubbisetty 提交于
      QCA99X0 uses radio specific board names based on chip id and
      board id combinations. We get these IDs from the target using BMI after otp.bin
      has been started.
      
      This patch reorders the call to the function ath10k_core_fetch_board_file
      so that we have OTP binary before requesting for boardid-chipid. We get this
      OTP data after parsing firmware-N.bin.
      
      [kvalo@qca.qualcomm.com: try BMI_PARAM_GET_EEPROM_BOARD_ID with
       all boards and detect if command is not supported]
      Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      db0984e5
    • M
      ath10k: add board 2 API support · 0a51b343
      Manikanta Pubbisetty 提交于
      QCA6174 needs different board files based on board type. To make it easier to
      distribute multiple board files and automatically choose correct board file
      create a simple TLV file format following the same principles as with FW IEs.
      The file is named board-2.bin and contain multiple board files. Each board file
      then can have multiple names.
      
      ath10k searches for file board-N.bin (where N is the interface version number
      for the board file, just like we for firmware files) in /lib/firmware/*, for
      example for qca99x0 it will try to find it here:
      
      /lib/firmware/ath10k/QCA99X0/hw2.0/board-2.bin
      
      If ath10k doesn't find board-2.bin then it will fallback to the old board.bin file.
      
      This patch adds a simple name scheme using pci device id which for now will be
      used by qca6174:
      
      bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x
      
      This removes the old method of having subsystem ids in ar->spec_board_id and
      using that in the board file name.
      Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
      [kvalo@qca.qualcomm.com: simplified the file format, rewrote commit log, other smaller changes]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0a51b343
  6. 06 10月, 2015 3 次提交
    • K
      ath10k: fix whitespace usage · 9a14969f
      Kalle Valo 提交于
      checkpatch found:
      
      drivers/net/wireless/ath/ath10k/core.c:574: Blank lines aren't necessary before a close brace '}'
      drivers/net/wireless/ath/ath10k/mac.c:4067: Missing a blank line after declarations
      drivers/net/wireless/ath/ath10k/mac.c:4083: Missing a blank line after declarations
      drivers/net/wireless/ath/ath10k/mac.c:4084: spaces required around that '>>=' (ctx:WxV)
      drivers/net/wireless/ath/ath10k/pci.c:1507: Missing a blank line after declarations
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      9a14969f
    • K
      ath10k: indentation fixes · 617b0f4d
      Kalle Valo 提交于
      checkpatch found:
      
      drivers/net/wireless/ath/ath10k/core.c:513: Alignment should match open parenthesis
      drivers/net/wireless/ath/ath10k/core.c:1266: code indent should use tabs where possible
      drivers/net/wireless/ath/ath10k/core.c:1267: code indent should use tabs where possible
      drivers/net/wireless/ath/ath10k/core.c:1268: code indent should use tabs where possible
      drivers/net/wireless/ath/ath10k/core.c:1269: code indent should use tabs where possible
      drivers/net/wireless/ath/ath10k/mac.c:4659: Alignment should match open parenthesis
      drivers/net/wireless/ath/ath10k/mac.c:6271: Alignment should match open parenthesis
      drivers/net/wireless/ath/ath10k/pci.c:2260: Alignment should match open parenthesis
      drivers/net/wireless/ath/ath10k/wmi.c:3510: Alignment should match open parenthesis
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      617b0f4d
    • K
      ath10k: fix checkpatch warning about logical continuations · be62e92a
      Kalle Valo 提交于
      checkpatch found:
      
      drivers/net/wireless/ath/ath9k/core.c:490: Logical continuations should be on the previous line
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      be62e92a
  7. 17 9月, 2015 2 次提交
    • K
      ath10k: add ATH10K_FW_FEATURE_RAW_MODE_SUPPORT to ath10k_core_fw_feature_str[] · 5af82fa6
      Kalle Valo 提交于
      This was missed in the original commit adding the flag and ath10k only printed "bit10":
      
      ath10k_pci 0000:02:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.70.6-2 api 3
      htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features no-p2p,bit10
      
      Also add a build test to avoid this happening again.
      
      Fixes: ccec9038 ("ath10k: enable raw encap mode and software crypto engine")
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5af82fa6
    • B
      ath10k: implement mesh support · b6c7bafa
      Bob Copeland 提交于
      Add support for mesh to ath10k.  We simply use an AP virtual interface
      in the firmware in order to enable beaconing without TSF adoption, and
      use the raw (802.11) transmit mode.
      
      Due to firmware limitations, the firmware must operate in raw
      (non-native 802.11) mode.  As this is configured at firmware init time,
      a new "rawmode" modparam is added, and mesh interfaces are available
      only if rawmode=true.  The firmware must advertise support for rawmode;
      tested successfully with firmware 10.2.4.70.6-2.
      
      When the module is loaded with (newly implemented) modparam rawmode=1, it
      will enable operating an open mesh STA via something like the following:
      
          ip link set wlan0 down
          iw dev wlan0 set type mp
          ip link set wlan0 up
          iw dev wlan0 set freq 5745 80 5775
          iw dev wlan0 mesh join mesh-vht
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      b6c7bafa
  8. 09 9月, 2015 2 次提交
    • V
      ath10k: drop probe responses when too many are queued · 7b7da0a0
      Vivek Natarajan 提交于
      In a noisy environment, when multiple interfaces are created,
      the management tx descriptors are fully occupied by the probe
      responses from all the interfaces. This prevents a new station
      from a successful association.
      
      Fix this by limiting the probe responses when the specified
      threshold limit is reached.
      Signed-off-by: NVivek Natarajan <nataraja@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7b7da0a0
    • V
      ath10k: fix DMA alloc failure for target requested memory chunks · a925a376
      Vasanthakumar Thiagarajan 提交于
      During long hours of stress testing like AP interface up/down along
      with continuous ping flood from a station doing connect/disconnect,
      it is observed that the system is not able to allocate DMA consistent
      memory of size > 512KB chunks as requested by firmware in WMI_SERVICE_EVENTID.
      With the system memory getting fragmented during the run based on the
      size of the memory requested, the failure to return physically continguous
      memory of high order can happen. Once the system gets to this situation,
      bringing up the wifi interface will fail and a system reboot may be needed
      to make it work again. This problem is obseved with QCA99X0.
      
      To fix this issue, allocate the DMA memory requested by firmware during
      device probe time and keep it during the life time of the device. WMI service
      ready event handler is changed to allocate the memory chunks if it is
      not already allocated or if the memory allocated for the previous ready
      event is not same as the current requested ones. After this patch the
      memory usage when wifi is inactive will be inceased by few 100KB to
      3MB based on the target type.
      
      Failure happens with the following stack trace
      
      [29557.488773] kworker/u4:1: page allocation failure: order:8, mode:0xd0
      [29557.494297] CPU: 0 PID: 8402 Comm: kworker/u4:1 Not tainted 3.14.43 #7
      [29557.500793] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
      [29557.508602] [<c021e9b0>] (unwind_backtrace) from [<c021ba90>] (show_stack+0x10/0x14)
      [29557.516580] [<c021ba90>] (show_stack) from [<c03bdddc>] (dump_stack+0x88/0xcc)
      [29557.523612] [<c03bdddc>] (dump_stack) from [<c0290e34>] (warn_alloc_failed+0xdc/0x108)
      [29557.531515] [<c0290e34>] (warn_alloc_failed) from [<c0292d88>] (__alloc_pages_nodemask+0x4f0/0x654)
      [29557.540485] [<c0292d88>] (__alloc_pages_nodemask) from [<c0222b48>] (__dma_alloc_buffer.isra.20+0x2c/0x104)
      [29557.550260] [<c0222b48>] (__dma_alloc_buffer.isra.20) from [<c0222c34>] (__alloc_remap_buffer.isra.23+0x14/0xb8)
      [29557.560413] [<c0222c34>] (__alloc_remap_buffer.isra.23) from [<c022305c>] (__dma_alloc+0x224/0x2b8)
      [29557.569490] [<c022305c>] (__dma_alloc) from [<c0223208>] (arm_dma_alloc+0x84/0x90)
      [29557.577010] [<c0223208>] (arm_dma_alloc) from [<bf5159d0>] (ath10k_wmi_event_service_ready_work+0x2f8/0x420 [ath10k_core])
      [29557.588055] [<bf5159d0>] (ath10k_wmi_event_service_ready_work [ath10k_core]) from [<c024260c>] (process_one_work+0x20c/0x328)
      [29557.599305] [<c024260c>] (process_one_work) from [<c02432d0>] (worker_thread+0x228/0x360)
      [29557.607470] [<c02432d0>] (worker_thread) from [<c0247f88>] (kthread+0xd8/0xec)
      [29557.614750] [<c0247f88>] (kthread) from [<c0208d18>] (ret_from_fork+0x14/0x3c)
      [29557.712751] Normal: 696*4kB (UEMR) 512*8kB (UEMR) 367*16kB (UEMR) 404*32kB (UEMR) 455*64kB (UEMR) 424*128kB (UEMR) 379*256kB (UMR) 327*512kB (UMR) 1*1024kB (R) 0*2048kB 0*4096kB = 374544kB
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a925a376
  9. 26 8月, 2015 1 次提交
    • M
      ath10k: add qca6164 support · 36582e5d
      Michal Kazior 提交于
      This adds additional 0x0041 PCI Device ID
      definition to ath10k for QCA6164 which is a 1
      spatial stream sibling of the QCA6174 (which is 2
      spatial stream chip).
      
      The QCA6164 needs a dedicated board.bin file which
      is different than the one used for QCA6174. If the
      board.bin is wrong the device will crash early
      while trying to boot firmware. The register dump
      will look like this:
      
       ath10k_pci 0000:02:00.0: firmware register dump:
       ath10k_pci 0000:02:00.0: [00]: 0x05010000 0x000015B3 0x000A012D 0x00955B31
       ...
      
      Note the value 0x000A012D.
      
      Special credit goes to Alan Liu
      <alanliu@qca.qualcomm.com> for providing support
      help which enabled me to come up with this patch.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      36582e5d
  10. 19 8月, 2015 1 次提交
  11. 17 8月, 2015 1 次提交
  12. 30 7月, 2015 1 次提交
    • R
      ath10k: fix memory alloc failure in qca99x0 during wmi svc rdy event · c8ecfc1c
      Raja Mani 提交于
      Host memory required for firmware is allocated while handling
      wmi service ready event. Right now, wmi service ready is handled
      in tasklet context and it calls dma_alloc_coherent() with atomic
      flag (GFP_ATOMIC) to allocate memory in host needed for firmware.
      The problem is, dma_alloc_coherent() with GFP_ATOMIC fails in
      the platform (at least in AP platform) where it has less atomic
      pool memory (< 2mb). QCA99X0 requires around 2 MB of host memory
      for one card, having additional QCA99X0 card in the same platform
      will require similarly amount of memory. So, it's not guaranteed that
      all the platform will have enough atomic memory pool.
      
      Fix this issue, by handling wmi service ready event in workqueue
      context and calling dma_alloc_coherent() with GFP_KERNEL. mac80211 work
      queue will not be ready at the time of handling wmi service ready.
      So, it can't be used to handle wmi service ready. Also, register work
      gets scheduled during insmod in existing ath10k_wq and waits for
      wmi service ready to completed. Both workqueue can't be used for
      this purpose. New auxiliary workqueue is added to handle wmi service
      ready.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c8ecfc1c
  13. 29 7月, 2015 1 次提交
    • D
      ath10k: enable raw encap mode and software crypto engine · ccec9038
      David Liu 提交于
      This patch enables raw Rx/Tx encap mode to support software based
      crypto engine. This patch introduces a new module param 'cryptmode'.
      
       cryptmode:
      
         0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
            encapsulation to the firmware. This is the default mode.
         1: Use sofware crypto engine globally with raw mode TX/RX
            encapsulation to the firmware.
      
      Known limitation:
         A-MSDU must be disabled for RAW Tx encap mode to perform well when
         heavy traffic is applied.
      
      Testing: (by Michal Kazior <michal.kazior@tieto.com>)
      
           a) Performance Testing
      
            cryptmode=1
             ap=qca988x sta=killer1525
              killer1525  ->  qca988x     194.496 mbps [tcp1 ip4]
              killer1525  ->  qca988x     238.309 mbps [tcp5 ip4]
              killer1525  ->  qca988x     266.958 mbps [udp1 ip4]
              killer1525  ->  qca988x     477.468 mbps [udp5 ip4]
              qca988x     ->  killer1525  301.378 mbps [tcp1 ip4]
              qca988x     ->  killer1525  297.949 mbps [tcp5 ip4]
              qca988x     ->  killer1525  331.351 mbps [udp1 ip4]
              qca988x     ->  killer1525  371.528 mbps [udp5 ip4]
             ap=killer1525 sta=qca988x
              qca988x     ->  killer1525  331.447 mbps [tcp1 ip4]
              qca988x     ->  killer1525  328.783 mbps [tcp5 ip4]
              qca988x     ->  killer1525  375.309 mbps [udp1 ip4]
              qca988x     ->  killer1525  403.379 mbps [udp5 ip4]
              killer1525  ->  qca988x     203.689 mbps [tcp1 ip4]
              killer1525  ->  qca988x     222.339 mbps [tcp5 ip4]
              killer1525  ->  qca988x     264.199 mbps [udp1 ip4]
              killer1525  ->  qca988x     479.371 mbps [udp5 ip4]
      
            Note:
             - only open network tested for RAW vs nwifi performance comparison
             - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps)
             - used iperf
             - OTA, devices a few cm apart from each other, no shielding
             - tcpX/udpX, X - means number of threads used
      
            Overview:
             - relative Tx performance drop is seen but is within reasonable and
               expected threshold (A-MSDU must be disabled with RAW Tx)
      
           b) Connectivity Testing
      
            cryptmode=1
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
      
            Note:
             - each test takes all possible endpoint pairs and pings
             - each pair-ping flushes arp table
             - ip6 is used
      
           c) Testbed Topology:
      
            1ap1sta:
              [ap] ---- [sta]
      
              endpoints: ap, sta
      
            1ap1sta2br:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                  [br0]            [br1]
      
              endpoints: veth0, veth2, br0, br1
              note: STA works in 4addr mode, AP has wds_sta=1
      
            1ap1sta2br1vlan:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                [br0]              [br1]
                  |                  |
                [vlan0_id2]        [vlan1_id2]
      
              endpoints: vlan0_id2, vlan1_id2
              note: STA works in 4addr mode, AP has wds_sta=1
      
      Credits:
      
          Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the
          amsdu issue, contributed a workaround (already squashed into this
          patch), and contributed the throughput and connectivity tests results.
      Signed-off-by: NDavid Liu <cfliu.tw@gmail.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Tested-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ccec9038
  14. 02 7月, 2015 3 次提交
    • R
      ath10k: configure frag desc memory to target for qca99X0 · d9156b5f
      Raja Mani 提交于
      Pre qca99X0 chipsets follows the model where dynamically allocate
      memory for frag desc on getting new skb for TX. But, this is not
      going to be the case in qca99X0. It expects frag desc memory to be
      allocated at boot time and let the driver to reuse allocated memory
      after every TX completion. So there won't be any dynamic frag memory
      memory allocation in qca99X0 during data transmission.
      
      qca99X0 hardware doesn't need fragment desc address to be programmed
      in msdu descriptor for every data transaction. It needs to know only
      starting address of fragment descriptor at the time of the boot.
      During data transmission, qca99X0 hardware can retrieve corresponding
      frag addr by adding programmed frag desc base addr + msdu id.
      
      Allocate continuous fragment descriptor memory (same size as number of
      descriptor) at the time of target initialization and configure allocated
      dma address to the target via HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG.
      
      How this is allocated continuous memory is going to be used is not
      covered in this patch. It just allocates memory and hand over to firmware.
      If we don't do it at init time, qca99X0 will stall when firmware tries
      to do TX.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d9156b5f
    • R
      ath10k: set max spatial stream to 4 for 10.4 fw · 5c8726ec
      Raja Mani 提交于
      10.4 fw supports upto 4 spatial stream. Limit max spatial
      stream to 4 for 10.4 firmware and to 3 for non 10.4 firmware.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5c8726ec
    • R
      ath10k: add 10.4 fw specific htt msg definitions · 721ad3ca
      Raja Mani 提交于
      New htt event table is added for 10.4 firmware. Following new htt
      events are available only 10.4. adding this to generic htt event
      table,
      	HTT_T2H_MSG_TYPE_EN_STATS,
      	HTT_T2H_MSG_TYPE_TX_FETCH_IND,
      	HTT_T2H_MSG_TYPE_TX_FETCH_CONF,
      	HTT_T2H_MSG_TYPE_TX_LOW_LATENCY_IND
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      721ad3ca
  15. 30 6月, 2015 6 次提交
  16. 16 6月, 2015 1 次提交
  17. 01 6月, 2015 1 次提交
  18. 29 5月, 2015 1 次提交
    • M
      ath10k: handle cycle counter wraparound · 587f7031
      Michal Kazior 提交于
      When QCA988X cycle counter HW register wraps
      around it resets to 0x7fffffff instead of 0. All
      other cycle counter related registers are divided
      by 2 so they never wraparound themselves. QCA61X4
      has a uniform CC and it wraparounds in a regular
      fashion though.
      
      Worst case wraparound time is approx 24 seconds
      (2**31 / 88MHz). Since scan channel visit times
      are max 5 seconds (offchannel case) it is
      guaranteed there's been at most 1 wraparound and
      it is possible to compute survey active time
      value. It is, however, impossible to determine the
      point at which Rx Clear Count has been divided by
      two so it is not reported upon wraparound.
      
      This fixes some occasional incorrect survey data
      on QCA988X as some channels (depending on how/when
      scan/offchannel requests were requested) would
      have approx 24 sec active time which wasn't
      actually the case.
      
      This should improve hostapd ACS a little bit.
      Reported-by: NSrinivasa Duvvuri <sduvvuri@chromium.org>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      587f7031
  19. 05 5月, 2015 1 次提交
    • K
      ath10k: add ATH10K_FW_FEATURE_IGNORE_OTP_RESULT · d9153546
      Kalle Valo 提交于
      qca6174 otp binary seems to always return an error to the host, even if the
      calibration succeeded. Add a firmware feature flag to detect if the firmware
      image which have this problem and workaround the issue in ath10k by ignoring
      the error code.
      
      I was also considering making this hw specific flag but as this is strictly a
      firmware issue it's best to handle this via a firmware feature flag so that it
      will be easy to disable the workaround.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d9153546
  20. 22 4月, 2015 2 次提交
    • M
      ath10k: allow loading device specific board files · de57e2c8
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      de57e2c8
    • M
      ath10k: share board file loading code across FW APIs · d0ed74f3
      Michal Kazior 提交于
      There's no need to implement the same thing twice.
      Reduce code duplication.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d0ed74f3
  21. 09 4月, 2015 1 次提交
  22. 02 4月, 2015 2 次提交