ath10k-pending-sdio-usb-201804210910

[Kalle Valo]

Hi Erik,

I just rebased my ath10k-pending-sdio-usb-branch:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/?h=ath10k-pending-sdio-usb

Starting from this rebase I'm starting to write proper changelog for
every rebase, this is for tag ath10k-pending-sdio-usb-201804210910:

* rebase to current ath.git master branch (v4.17-rc1)

* ath10k-add-start_once-support: fix hw.h conflict in start_once

* ath10k_sdio-dma-bounce-buffers: fix conflict, convert to devm_kzalloc()

* cherry pick 1ccd0d53059a ("ath10k_sdio: virtual scatter gather for
  receive") from Erik's which I had missed during rebase. also fold
  "ath10k: sdio: fix type mismatch in func prototype" to this commit

Also I started to write a TODO list for what needs to be done in that
branch to get everything merged:

o log messages do not start with "ath10k_usb", only "usb":
 
 [ 2830.062742] usb 2-1.3: Failed to submit usb control message: -110

o new warning:

  usb 2-1.3: invalid hw_params.n_cipher_suites 0

o usb support seems pretty unstable, with few ip link set up/down
  cycles:

  usb 2-1.3: Failed to submit usb control message: -110
  usb 2-1.3: unable to send the bmi data to the device: -110
  usb 2-1.3: unable to write to the device (-110)
  usb 2-1.3: settings HTC version failed
  usb 2-1.3: Could not init core: -22

o struct ath10k_bus_params::is_high_latency should be changed to enum
  (eg ATH10K_HTT_MODE_HL and ATH10K_HTT_MODE_LL)

o the num_peers and max_num_peers mess should be fixed

o struct ath10k::is_started looks fishy, adding another state variable
  feels like a new source of problems. Can't we use ar->state and
  check ATH10K_STATE_ON instead?

o I think we should disable firmware restart for hardware which have
  start_once enabled. AFAICS there's no way restart firmware in that
  case (which is bad, I hope we could find a way. I guess for some
  SDIO boards it might be possible to control target power but not for
  USB).

o switching to use ieee80211_rx_ni() needs more explanation in the
  commit log (is it for usb or sdio etc) and we should check for
  regressions (confirmation that it won't break other hardware,
  throughput problems etc)

o board-usb.bin and board-sdio.bin should not be used, instead use
  board-2.bin (which has the bus attribute) or board.bin

o the ar->hif.bus checks should be avoided

o sdio dma bounce buffer and common read write function should be
  removed

It seems that there are multiple people involved with this now so I
think some sort of coordination is needed so that we don't need
duplicate work. Not sure how to do that, any ideas?

-- 
Kalle Valo