Kalle Valo kvalo at
Sat Apr 21 02:20:28 PDT 2018

Hi Erik,

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

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

  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

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

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

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

More information about the ath10k mailing list