All of lore.kernel.org
 help / color / mirror / Atom feed
* pull-request: wireless-drivers-next-2020-12-03
@ 2020-12-03 18:57 Kalle Valo
  2020-12-04 19:17 ` Jakub Kicinski
  0 siblings, 1 reply; 9+ messages in thread
From: Kalle Valo @ 2020-12-03 18:57 UTC (permalink / raw)
  To: netdev; +Cc: linux-wireless

Hi,

here's a pull request to net-next tree, more info below. Please let me know if
there are any problems.

Kalle

The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

  Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-2020-12-03

for you to fetch changes up to 9eb597c74483ad5c230a884449069adfb68285ea:

  Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2020-12-02 21:46:55 +0200)

----------------------------------------------------------------
wireless-drivers-next patches for v5.11

First set of patches for v5.11. rtw88 getting improvements to work
better with Bluetooth and other driver also getting some new features.
mhi-ath11k-immutable branch was pulled from mhi tree to avoid
conflicts with mhi tree.

Major changes:

rtw88

* major bluetooth co-existance improvements

wilc1000

* Wi-Fi Multimedia (WMM) support

ath11k

* Fast Initial Link Setup (FILS) discovery and unsolicited broadcast
  probe response support

* qcom,ath11k-calibration-variant Device Tree setting

* cold boot calibration support

* new DFS region: JP

wnc36xx

* enable connection monitoring and keepalive in firmware

ath10k

* firmware IRAM recovery feature

mhi

* merge mhi-ath11k-immutable branch to make MHI API change go smoothly

----------------------------------------------------------------
Ajay Singh (5):
      wilc1000: added 'ndo_set_mac_address' callback support
      wilc1000: free resource in wilc_wlan_txq_add_net_pkt() for failure path
      wilc1000: free resource in wilc_wlan_txq_add_mgmt_pkt() for failure path
      wilc1000: call complete() for failure in wilc_wlan_txq_add_cfg_pkt()
      wilc1000: added queue support for WMM

Alex Dewar (2):
      ath10k: sdio: remove redundant check in for loop
      ath11k: Handle errors if peer creation fails

Allen Pais (2):
      ath11k: convert tasklets to use new tasklet_setup() API
      wireless: mt7601u: convert tasklets to use new tasklet_setup() API

Aloka Dixit (1):
      ath11k: FILS discovery and unsolicited broadcast probe response support

Arnd Bergmann (5):
      ath6kl: fix enum-conversion warning
      net: hostap: fix function cast warning
      rtlwifi: fix -Wpointer-sign warning
      rtw88: remove extraneous 'const' qualifier
      ath9k: work around false-positive gcc warning

Ben Greear (1):
      ath10k: Don't iterate over not-sdata-in-driver interfaces.

Bhaumik Bhatt (1):
      net: qrtr: Unprepare MHI channels during remove

Brian Norris (1):
      rtw88: wow: print key type when failing

Bryan O'Donoghue (4):
      wcn36xx: Set LINK_FAIL_TX_CNT to 1000 on all wcn36xx
      wcn36xx: Enable firmware link monitoring
      wcn36xx: Enable firmware offloaded keepalive
      wcn36xx: Send NULL data packet when exiting BMPS

Carl Huang (1):
      ath11k: fix ZERO address in probe request

Chin-Yen Lee (4):
      rtw88: sync the power state between driver and firmware
      rtw88: store firmware feature in firmware header
      rtw88: add C2H response for checking firmware leave lps
      rtw88: decide lps deep mode from firmware feature.

Ching-Te Ku (33):
      rtw88: coex: separate BLE HID profile from BLE profile
      rtw88: coex: fixed some wrong register definition and setting
      rtw88: coex: update coex parameter to improve A2DP quality
      rtw88: coex: reduce magic number
      rtw88: coex: coding style adjustment
      rtw88: coex: Modify the timing of set_ant_path/set_rf_para
      rtw88: coex: add separate flag for manual control
      rtw88: coex: modified for BT info notify
      rtw88: coex: change the parameter for A2DP when WLAN connecting
      rtw88: coex: update WLAN 5G AFH parameter for 8822b
      rtw88: coex: add debug message
      rtw88: coex: simplify the setting and condition about WLAN TX limitation
      rtw88: coex: update TDMA settings for different beacon interval
      rtw88: coex: remove unnecessary feature/function
      rtw88: coex: add write scoreboard action when WLAN in critical procedure
      rtw88: coex: Add force flag for coexistence table function
      rtw88: coex: add the mechanism for RF4CE
      rtw88: coex: update the TDMA parameter when leave LPS
      rtw88: coex: Change antenna setting to enhance free-run performance
      rtw88: coex: fix BT performance drop during initial/power-on step
      rtw88: coex: remove write scan bit to scoreboard in scan and connect notify
      rtw88: coex: remove unnecessary WLAN slot extend
      rtw88: coex: change the decode method from firmware
      rtw88: coex: run coexistence when WLAN entering/leaving LPS
      rtw88: coex: add debug message
      rtw88: coex: update the mechanism for A2DP + PAN
      rtw88: coex: update AFH information while in free-run mode
      rtw88: coex: change the coexistence mechanism for HID
      rtw88: coex: change the coexistence mechanism for WLAN connected
      rtw88: coex: add function to avoid cck lock
      rtw88: coex: add action for coexistence in hardware initial
      rtw88: coex: upgrade coexistence A2DP mechanism
      rtw88: coex: add feature to enhance HID coexistence performance

Christophe JAILLET (3):
      ath11k: Fix an error handling path
      ath10k: Fix an error handling path
      ath10k: Release some resources in an error handling path

Dmitry Safonov (1):
      brcmsmac: ampdu: Check BA window size before checking block ack

Govind Singh (1):
      ath11k: Remove unused param from wmi_mgmt_params

Govindaraj Saminathan (1):
      ath11k: cold boot calibration support

Gustavo A. R. Silva (3):
      ray_cs: Use fallthrough pseudo-keyword
      wlcore: Use fallthrough pseudo-keyword
      mwifiex: Fix fall-through warnings for Clang

Jia-Ju Bai (4):
      rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA
      rtlwifi: rtl8192ce: avoid accessing the data mapped to streaming DMA
      rtlwifi: rtl8192de: avoid accessing the data mapped to streaming DMA
      rtlwifi: rtl8723ae: avoid accessing the data mapped to streaming DMA

Jisheng Zhang (1):
      mwifiex: Remove duplicated REG_PORT definition

Kaixu Xia (1):
      rtlwifi: rtl8192de: remove the useless value assignment

Kalle Valo (6):
      ath10k: remove repeated words in comments
      ath10k: ath10k_pci_init_irq(): workaround for checkpatch fallthrough warning
      ath11k: remove repeated words in comments and warnings
      Merge mhi-ath11k-immutable into ath-next
      ath11k: dp_rx: fix monitor status dma unmap direction
      Merge ath-next from git://git.kernel.org/.../kvalo/ath.git

Karthikeyan Periyasamy (3):
      ath11k: Fix single phy hw mode
      ath11k: Fix the hal descriptor mask
      ath11k: fix wmi init configuration

Lavanya Suresh (1):
      ath11k: Add new dfs region name for JP

Lee Jones (32):
      ath: regd: Provide description for ath_reg_apply_ir_flags's 'reg' param
      ath: dfs_pattern_detector: Fix some function kernel-doc headers
      ath: dfs_pri_detector: Demote zero/half completed kernel-doc headers
      ath9k: ar9330_1p1_initvals: Remove unused const variable 'ar9331_common_tx_gain_offset1_1'
      ath9k: ar9340_initvals: Remove unused const variable 'ar9340Modes_ub124_tx_gain_table_1p0'
      ath9k: ar9485_initvals: Remove unused const variable 'ar9485_fast_clock_1_1_baseband_postamble'
      ath9k: ar9003_2p2_initvals: Remove unused const variables
      ath9k: ar5008_phy: Demote half completed function headers
      ath9k: dynack: Demote non-compliant function header
      wil6210: wmi: Correct misnamed function parameter 'ptr_'
      rsi: rsi_91x_usb: Fix some basic kernel-doc issues
      rsi: rsi_91x_usb_ops: Source file headers are not good candidates for kernel-doc
      brcmfmac: bcmsdh: Fix description for function parameter 'pktlist'
      brcmfmac: pcie: Provide description for missing function parameter 'devinfo'
      brcmfmac: fweh: Add missing description for 'gfp'
      wl1251: cmd: Rename 'len' to 'buf_len' in the documentation
      prism54: isl_ioctl: Fix one function header and demote another
      wl3501_cs: Fix misspelling and provide missing documentation
      mwifiex: pcie: Remove a couple of unchecked 'ret's
      wlcore: spi: Demote a non-compliant function header, fix another
      rtw88: rtw8822c: Remove unused variable 'corr_val'
      rtlwifi: rtl8192cu: mac: Fix some missing/ill-documented function parameters
      rtlwifi: rtl8192cu: trx: Demote clear abuse of kernel-doc format
      rtlwifi: halbtc8723b2ant: Remove a bunch of set but unused variables
      rtlwifi: phy: Remove set but unused variable 'bbvalue'
      rtlwifi: halbtc8821a1ant: Remove set but unused variable 'wifi_rssi_state'
      rtlwifi: rtl8723be: Remove set but unused variable 'lc_cal'
      rtlwifi: rtl8188ee: Remove set but unused variable 'reg_ea4'
      rtlwifi: halbtc8821a2ant: Remove a bunch of unused variables
      rtlwifi: rtl8723be: Remove set but unused variable 'cck_highpwr'
      rtlwifi: rtl8821ae: phy: Remove a couple of unused variables
      rtlwifi: rtl8821ae: Place braces around empty if() body

Loic Poulain (2):
      bus: mhi: Remove auto-start option
      net: qrtr: Start MHI channels during init

Maharaja Kennadyrajan (1):
      ath11k: Fix the rx_filter flag setting for peer rssi stats

Marek Vasut (3):
      rsi: Fix TX EAPOL packet handling against iwlwifi AP
      rsi: Move card interrupt handling to RX thread
      rsi: Clean up loop in the interrupt handler

Markov Mikhail (1):
      rt2x00: save survey for every channel visited

Matthias Brugger (1):
      brcmfmac: expose firmware config files through modinfo

P Praneesh (1):
      ath11k: add processor_id based ring_selector logic

Ping-Ke Shih (2):
      rtw88: 8723d: add cck pd seetings
      rtw88: add CCK_PD debug log

Qinglang Miao (1):
      cw1200: fix missing destroy_workqueue() on error in cw1200_init_common

Rakesh Pillai (1):
      ath10k: Fix the parsing error in service available event

Ramya Gnanasekar (1):
      ath11k: Fix beamformee STS in HE cap

Remi Depommier (2):
      brcmfmac: fix SDIO access for big-endian host
      brcmfmac: Fix incorrect type in assignment

Rikard Falkeborn (1):
      ath10k: Constify static qmi structs

Ritesh Singh (3):
      ath11k: vdev delete synchronization with firmware
      ath11k: peer delete synchronization with firmware
      ath11k: remove "ath11k_mac_get_ar_vdev_stop_status" references

Sebastian Andrzej Siewior (18):
      orinoco: Remove BUG_ON(in_interrupt/irq())
      airo: Invoke airo_read_wireless_stats() directly
      airo: Always use JOB_STATS and JOB_EVENT
      airo: Replace in_atomic() usage.
      hostap: Remove in_atomic() check.
      zd1211rw: Remove in_atomic() usage.
      rtlwifi: Remove in_interrupt() usage in is_any_client_connect_to_ap().
      rtlwifi: Remove in_interrupt() usage in halbtc_send_bt_mp_operation()
      orinoco: Move context allocation after processing the skb
      orinoco: Prepare stubs for in_interrupt() removal
      orinoco: Annotate ezusb_xmit()
      orinoco: Annotate ezusb_init()
      orinoco: Annotate firmware loading
      orinoco: Annotate ezusb_read_pda()
      orinoco: Annotate ezusb_write_ltv()
      orinoco: Remove ezusb_doicmd_wait()
      orinoco: Annotate ezusb_docmd_wait()
      orinoco: Annotate ezusb_read_ltv()

Seung-Woo Kim (1):
      brcmfmac: Fix memory leak for unpaired brcmf_{alloc/free}

Sven Eckelmann (7):
      dt: bindings: add new dt entry for ath11k calibration variant
      ath11k: search DT for qcom,ath11k-calibration-variant
      ath11k: Initialize complete alpha2 for regulatory change
      ath11k: Fix number of rules in filtered ETSI regdomain
      ath11k: Don't cast ath11k_skb_cb to ieee80211_tx_info.control
      ath11k: Reset ath11k_skb_cb before setting new flags
      ath11k: Build check size of ath11k_skb_cb

Tamizh Chelvam (1):
      ath10k: fix compilation warning

Tian Tao (1):
      wlcore: Switch to using the new API kobj_to_dev()

Tokunori Ikegami (2):
      rtl8xxxu: Add Buffalo WI-U3-866D to list of supported devices
      Revert "rtl8xxxu: Add Buffalo WI-U3-866D to list of supported devices"

Tom Rix (3):
      wireless: remove unneeded break
      airo: remove trailing semicolon in macro definition
      wl1251: remove trailing semicolon in macro definition

Tsuchiya Yuto (3):
      mwifiex: fix mwifiex_shutdown_sw() causing sw reset failure
      mwifiex: update comment for shutdown_sw()/reinit_sw() to reflect current state
      mwifiex: pcie: skip cancel_work_sync() on reset failure path

Vasanthakumar Thiagarajan (1):
      ath11k: Remove unnecessary data sync to cpu on monitor buffer

Venkateswara Naralasetty (1):
      ath10k: add target IRAM recovery feature support

Wang Hai (1):
      qtnfmac: fix error return code in qtnf_pcie_probe()

Wang Qing (1):
      rtlwifi: fix spelling typo of workaround

WeitaoWangoc (1):
      rtlwifi: Fix non-canonical address access issues

Wen Gong (1):
      ath10k: cancel rx worker in hif_stop for SDIO

Yejune Deng (1):
      cw1200: replace a set of atomic_add()

Zhang Changzhong (2):
      brcmfmac: fix error return code in brcmf_cfg80211_connect()
      rsi: fix error return code in rsi_reset_card()

 .../bindings/net/wireless/qcom,ath11k.yaml         |    6 +
 drivers/bus/mhi/core/init.c                        |    9 -
 drivers/bus/mhi/core/internal.h                    |    1 -
 drivers/net/wireless/ath/ath10k/core.c             |   85 +-
 drivers/net/wireless/ath/ath10k/core.h             |    8 +
 drivers/net/wireless/ath/ath10k/debug.c            |    2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c           |    1 -
 drivers/net/wireless/ath/ath10k/mac.c              |   21 +-
 drivers/net/wireless/ath/ath10k/p2p.c              |    2 +-
 drivers/net/wireless/ath/ath10k/pci.c              |    2 +-
 drivers/net/wireless/ath/ath10k/qmi.c              |    4 +-
 drivers/net/wireless/ath/ath10k/rx_desc.h          |    2 +-
 drivers/net/wireless/ath/ath10k/sdio.c             |   20 +-
 drivers/net/wireless/ath/ath10k/usb.c              |    7 +-
 drivers/net/wireless/ath/ath10k/wmi-tlv.c          |    4 +-
 drivers/net/wireless/ath/ath10k/wmi.c              |   11 +-
 drivers/net/wireless/ath/ath10k/wmi.h              |    7 +-
 drivers/net/wireless/ath/ath11k/ahb.c              |   27 +
 drivers/net/wireless/ath/ath11k/core.c             |   41 +-
 drivers/net/wireless/ath/ath11k/core.h             |   22 +-
 drivers/net/wireless/ath/ath11k/dp.c               |    2 +-
 drivers/net/wireless/ath/ath11k/dp.h               |    2 +-
 drivers/net/wireless/ath/ath11k/dp_rx.c            |   18 +-
 drivers/net/wireless/ath/ath11k/dp_tx.c            |   13 +-
 drivers/net/wireless/ath/ath11k/hal_desc.h         |    8 +-
 drivers/net/wireless/ath/ath11k/hw.c               |    4 +-
 drivers/net/wireless/ath/ath11k/hw.h               |    1 +
 drivers/net/wireless/ath/ath11k/mac.c              |  198 ++-
 drivers/net/wireless/ath/ath11k/mac.h              |    2 -
 drivers/net/wireless/ath/ath11k/mhi.c              |    4 -
 drivers/net/wireless/ath/ath11k/pci.c              |    7 +-
 drivers/net/wireless/ath/ath11k/peer.c             |   44 +-
 drivers/net/wireless/ath/ath11k/peer.h             |    2 +
 drivers/net/wireless/ath/ath11k/qmi.c              |   78 +-
 drivers/net/wireless/ath/ath11k/qmi.h              |    5 +
 drivers/net/wireless/ath/ath11k/reg.c              |    7 +-
 drivers/net/wireless/ath/ath11k/reg.h              |    1 +
 drivers/net/wireless/ath/ath11k/rx_desc.h          |    2 +-
 drivers/net/wireless/ath/ath11k/testmode.c         |    4 +-
 drivers/net/wireless/ath/ath11k/wmi.c              |  294 +++-
 drivers/net/wireless/ath/ath11k/wmi.h              |   52 +-
 drivers/net/wireless/ath/ath6kl/testmode.c         |    1 -
 drivers/net/wireless/ath/ath6kl/wmi.c              |    4 +-
 drivers/net/wireless/ath/ath9k/ar5008_phy.c        |   15 +-
 .../net/wireless/ath/ath9k/ar9003_2p2_initvals.h   |   14 -
 .../net/wireless/ath/ath9k/ar9330_1p1_initvals.h   |    7 -
 drivers/net/wireless/ath/ath9k/ar9340_initvals.h   |  101 --
 drivers/net/wireless/ath/ath9k/ar9485_initvals.h   |    7 -
 drivers/net/wireless/ath/ath9k/dynack.c            |   11 +-
 drivers/net/wireless/ath/ath9k/hw.c                |    1 -
 drivers/net/wireless/ath/dfs_pattern_detector.c    |   14 +-
 drivers/net/wireless/ath/dfs_pri_detector.c        |    9 +-
 drivers/net/wireless/ath/regd.c                    |    1 +
 drivers/net/wireless/ath/wcn36xx/main.c            |    2 +
 drivers/net/wireless/ath/wcn36xx/smd.c             |    4 +-
 drivers/net/wireless/ath/wil6210/wmi.c             |    2 +-
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  |    2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c         |    3 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.c    |    1 +
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c    |    7 +-
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c    |   26 +-
 .../wireless/broadcom/brcm80211/brcmsmac/ampdu.c   |   11 +-
 drivers/net/wireless/cisco/airo.c                  |  126 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |    2 -
 drivers/net/wireless/intersil/hostap/hostap_hw.c   |   17 +-
 .../net/wireless/intersil/hostap/hostap_ioctl.c    |   15 +-
 drivers/net/wireless/intersil/orinoco/hermes.c     |    1 +
 drivers/net/wireless/intersil/orinoco/hermes.h     |   15 +
 drivers/net/wireless/intersil/orinoco/hw.c         |   32 +-
 .../net/wireless/intersil/orinoco/orinoco_usb.c    |  168 ++-
 drivers/net/wireless/intersil/prism54/isl_ioctl.c  |    5 +-
 drivers/net/wireless/marvell/mwifiex/main.c        |    6 +-
 drivers/net/wireless/marvell/mwifiex/pcie.c        |   24 +-
 drivers/net/wireless/marvell/mwifiex/pcie.h        |    2 +
 drivers/net/wireless/marvell/mwifiex/sdio.h        |    2 -
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |    2 +
 drivers/net/wireless/marvell/mwifiex/sta_event.c   |    1 +
 drivers/net/wireless/marvell/mwifiex/uap_cmd.c     |    1 +
 drivers/net/wireless/marvell/mwifiex/wmm.c         |    1 +
 drivers/net/wireless/mediatek/mt7601u/dma.c        |   12 +-
 drivers/net/wireless/microchip/wilc1000/cfg80211.c |    7 +-
 drivers/net/wireless/microchip/wilc1000/hif.c      |   17 +
 drivers/net/wireless/microchip/wilc1000/hif.h      |    1 +
 drivers/net/wireless/microchip/wilc1000/netdev.c   |   38 +
 drivers/net/wireless/microchip/wilc1000/netdev.h   |   11 +-
 drivers/net/wireless/microchip/wilc1000/wlan.c     |  335 ++++-
 drivers/net/wireless/microchip/wilc1000/wlan.h     |   30 +
 drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c |    6 +-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c     |   62 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00.h        |   10 +
 drivers/net/wireless/ray_cs.c                      |    6 +-
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c    |   48 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c    |    4 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c    |   27 +-
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c       |   28 +-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c    |    1 -
 .../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   |    4 +-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c   |    6 +-
 .../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c   |    6 +-
 .../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c   |    7 +-
 .../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c   |    2 +-
 .../net/wireless/realtek/rtlwifi/rtl8192de/phy.c   |    2 +-
 .../net/wireless/realtek/rtlwifi/rtl8192de/trx.c   |    6 +-
 .../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c    |    1 -
 .../net/wireless/realtek/rtlwifi/rtl8723ae/phy.c   |    4 +-
 .../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c   |    6 +-
 .../net/wireless/realtek/rtlwifi/rtl8723be/phy.c   |    4 +-
 .../net/wireless/realtek/rtlwifi/rtl8723be/trx.c   |    4 +-
 .../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c   |   96 +-
 .../net/wireless/realtek/rtlwifi/rtl8821ae/table.c |    4 +-
 .../net/wireless/realtek/rtlwifi/rtl8821ae/table.h |    4 +-
 drivers/net/wireless/realtek/rtlwifi/usb.c         |    1 -
 drivers/net/wireless/realtek/rtw88/coex.c          | 1538 +++++++++++++++-----
 drivers/net/wireless/realtek/rtw88/coex.h          |   47 +-
 drivers/net/wireless/realtek/rtw88/debug.c         |   27 +-
 drivers/net/wireless/realtek/rtw88/debug.h         |    1 +
 drivers/net/wireless/realtek/rtw88/fw.c            |    6 +-
 drivers/net/wireless/realtek/rtw88/fw.h            |   11 +-
 drivers/net/wireless/realtek/rtw88/mac80211.c      |    9 +-
 drivers/net/wireless/realtek/rtw88/main.c          |   59 +-
 drivers/net/wireless/realtek/rtw88/main.h          |   41 +-
 drivers/net/wireless/realtek/rtw88/phy.c           |    6 +
 drivers/net/wireless/realtek/rtw88/ps.c            |  135 +-
 drivers/net/wireless/realtek/rtw88/ps.h            |    3 +-
 drivers/net/wireless/realtek/rtw88/reg.h           |   17 +-
 drivers/net/wireless/realtek/rtw88/rtw8723d.c      |   96 +-
 drivers/net/wireless/realtek/rtw88/rtw8723d.h      |    3 +
 drivers/net/wireless/realtek/rtw88/rtw8821c.c      |   16 +-
 drivers/net/wireless/realtek/rtw88/rtw8821c.h      |    2 -
 drivers/net/wireless/realtek/rtw88/rtw8822b.c      |   55 +-
 drivers/net/wireless/realtek/rtw88/rtw8822c.c      |  119 +-
 drivers/net/wireless/realtek/rtw88/wow.c           |    8 +-
 drivers/net/wireless/rsi/rsi_91x_hal.c             |    3 +-
 drivers/net/wireless/rsi/rsi_91x_sdio.c            |    6 +-
 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c        |  173 +--
 drivers/net/wireless/rsi/rsi_91x_usb.c             |   36 +-
 drivers/net/wireless/rsi/rsi_91x_usb_ops.c         |    2 +-
 drivers/net/wireless/rsi/rsi_sdio.h                |    8 +-
 drivers/net/wireless/st/cw1200/bh.c                |   10 +-
 drivers/net/wireless/st/cw1200/main.c              |    2 +
 drivers/net/wireless/st/cw1200/wsm.c               |    8 +-
 drivers/net/wireless/ti/wl1251/cmd.c               |    2 +-
 drivers/net/wireless/ti/wl1251/debugfs.c           |    2 +-
 drivers/net/wireless/ti/wlcore/main.c              |    4 +-
 drivers/net/wireless/ti/wlcore/spi.c               |    3 +-
 drivers/net/wireless/ti/wlcore/sysfs.c             |    2 +-
 drivers/net/wireless/wl3501_cs.c                   |    8 +-
 drivers/net/wireless/zydas/zd1211rw/zd_usb.c       |   15 -
 include/linux/mhi.h                                |    2 -
 net/qrtr/mhi.c                                     |    6 +
 150 files changed, 3496 insertions(+), 1488 deletions(-)

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-03 18:57 pull-request: wireless-drivers-next-2020-12-03 Kalle Valo
@ 2020-12-04 19:17 ` Jakub Kicinski
  2020-12-07 10:40   ` Kalle Valo
  0 siblings, 1 reply; 9+ messages in thread
From: Jakub Kicinski @ 2020-12-04 19:17 UTC (permalink / raw)
  To: Kalle Valo; +Cc: netdev, linux-wireless

On Thu,  3 Dec 2020 18:57:32 +0000 (UTC) Kalle Valo wrote:
> wireless-drivers-next patches for v5.11
> 
> First set of patches for v5.11. rtw88 getting improvements to work
> better with Bluetooth and other driver also getting some new features.
> mhi-ath11k-immutable branch was pulled from mhi tree to avoid
> conflicts with mhi tree.

Pulled, but there are a lot of fixes in here which look like they
should have been part of the other PR, if you ask me. There's also 
a patch which looks like it renames a module parameter. Module
parameters are considered uAPI.

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-04 19:17 ` Jakub Kicinski
@ 2020-12-07 10:40   ` Kalle Valo
  2020-12-07 19:35     ` Brian Norris
  0 siblings, 1 reply; 9+ messages in thread
From: Kalle Valo @ 2020-12-07 10:40 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: netdev, linux-wireless

Jakub Kicinski <kuba@kernel.org> writes:

> On Thu,  3 Dec 2020 18:57:32 +0000 (UTC) Kalle Valo wrote:
>> wireless-drivers-next patches for v5.11
>> 
>> First set of patches for v5.11. rtw88 getting improvements to work
>> better with Bluetooth and other driver also getting some new features.
>> mhi-ath11k-immutable branch was pulled from mhi tree to avoid
>> conflicts with mhi tree.
>
> Pulled, but there are a lot of fixes in here which look like they
> should have been part of the other PR, if you ask me.

Yeah, I'm actually on purpose keeping the bar high for patches going to
wireless-drivers (ie. the fixes going to -rc releases). This is just to
keep things simple for me and avoiding the number of conflicts between
the trees.

> There's also a patch which looks like it renames a module parameter.
> Module parameters are considered uAPI.

Ah, I have been actually wondering that if they are part of user space
API or not, good to know that they are. I'll keep an eye of this in the
future so that we are not breaking the uAPI with module parameter
changes.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-07 10:40   ` Kalle Valo
@ 2020-12-07 19:35     ` Brian Norris
  2020-12-07 20:10       ` Jakub Kicinski
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Norris @ 2020-12-07 19:35 UTC (permalink / raw)
  To: Kalle Valo, Jakub Kicinski; +Cc: <netdev@vger.kernel.org>, linux-wireless

On Mon, Dec 7, 2020 at 2:42 AM Kalle Valo <kvalo@codeaurora.org> wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
> > On Thu,  3 Dec 2020 18:57:32 +0000 (UTC) Kalle Valo wrote:
> > There's also a patch which looks like it renames a module parameter.
> > Module parameters are considered uAPI.
>
> Ah, I have been actually wondering that if they are part of user space
> API or not, good to know that they are. I'll keep an eye of this in the
> future so that we are not breaking the uAPI with module parameter
> changes.

Is there some reference for this rule (e.g., dictate from on high; or
some explanation of reasons)? Or limitations on it? Because as-is,
this sounds like one could never drop a module parameter, or remove
obsolete features. It also suggests that debug-related knobs (which
can benefit from some amount of flexibility over time) should go
exclusively in debugfs (where ABI guarantees are explicitly not made),
even at the expense of usability (dropping a line into
/etc/modprobe.d/ is hard to beat).

That's not to say I totally disagree with the original claim, but I'm
just interested in knowing precisely what it means.

And to put a precise spin on this: what would this rule say about the following?

http://git.kernel.org/linus/f06021a18fcf8d8a1e79c5e0a8ec4eb2b038e153
iwlwifi: remove lar_disable module parameter

Should that parameter have never been introduced in the first place,
never be removed, or something else? I think I've seen this sort of
pattern before, where features get phased in over time, with module
parameters as either escape hatches or as opt-in mechanisms.
Eventually, they stabilize, and there's no need (or sometimes, it's
actively harmful) to keep the knob around.

Or the one that might (?) be in question here:
fc3ac64a3a28 rtw88: decide lps deep mode from firmware feature.

The original module parameter was useful for enabling new power-saving
features, because the driver didn't yet know which chip(s)/firmware(s)
were stable with which power features. Now, the driver has learned how
to figure out the optimal power settings, so it's dropping the old
param and adding an "escape hatch", in case there are problems.

I'd say this one is a bit more subtle than the lar_disable example,
but I'm still not sure that really qualifies as a "user-visible"
change.

Brian

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-07 19:35     ` Brian Norris
@ 2020-12-07 20:10       ` Jakub Kicinski
  2020-12-08  7:14         ` Emmanuel Grumbach
                           ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Jakub Kicinski @ 2020-12-07 20:10 UTC (permalink / raw)
  To: Brian Norris; +Cc: Kalle Valo, <netdev@vger.kernel.org>, linux-wireless

On Mon, 7 Dec 2020 11:35:53 -0800 Brian Norris wrote:
> On Mon, Dec 7, 2020 at 2:42 AM Kalle Valo <kvalo@codeaurora.org> wrote:
> > Jakub Kicinski <kuba@kernel.org> writes:  
> > > On Thu,  3 Dec 2020 18:57:32 +0000 (UTC) Kalle Valo wrote:
> > > There's also a patch which looks like it renames a module parameter.
> > > Module parameters are considered uAPI.  
> >
> > Ah, I have been actually wondering that if they are part of user space
> > API or not, good to know that they are. I'll keep an eye of this in the
> > future so that we are not breaking the uAPI with module parameter
> > changes.  
> 
> Is there some reference for this rule (e.g., dictate from on high; or
> some explanation of reasons)? Or limitations on it? Because as-is,
> this sounds like one could never drop a module parameter, or remove
> obsolete features.

TBH its one of those "widely accepted truth" in networking which was
probably discussed before I started compiling kernels so I don't know
the full background. But it seems pretty self-evident even without
knowing the casus that made us institute the rule.

Module parameters are certainly userspace ABI, since user space can
control them either when loading the module or via sysfs.

> It also suggests that debug-related knobs (which
> can benefit from some amount of flexibility over time) should go
> exclusively in debugfs (where ABI guarantees are explicitly not made),
> even at the expense of usability (dropping a line into
> /etc/modprobe.d/ is hard to beat).

Indeed, debugfs seems more appropriate.

> That's not to say I totally disagree with the original claim, but I'm
> just interested in knowing precisely what it means.
> 
> And to put a precise spin on this: what would this rule say about the following?
> 
> http://git.kernel.org/linus/f06021a18fcf8d8a1e79c5e0a8ec4eb2b038e153
> iwlwifi: remove lar_disable module parameter
> 
> Should that parameter have never been introduced in the first place,
> never be removed, or something else? I think I've seen this sort of
> pattern before, where features get phased in over time, with module
> parameters as either escape hatches or as opt-in mechanisms.
> Eventually, they stabilize, and there's no need (or sometimes, it's
> actively harmful) to keep the knob around.
> 
> Or the one that might (?) be in question here:
> fc3ac64a3a28 rtw88: decide lps deep mode from firmware feature.
> 
> The original module parameter was useful for enabling new power-saving
> features, because the driver didn't yet know which chip(s)/firmware(s)
> were stable with which power features. Now, the driver has learned how
> to figure out the optimal power settings, so it's dropping the old
> param and adding an "escape hatch", in case there are problems.
> 
> I'd say this one is a bit more subtle than the lar_disable example,
> but I'm still not sure that really qualifies as a "user-visible"
> change.

If I'm reading this right the pattern seems to be that module
parameters are used as chicken bits. It's an interesting problem, 
I'm not sure this use case was discussed. My concern would be that 
there is no guarantee users will in fact report the new feature 
fails for them, and therefore grow to depend on the chicken bits.

Since updating software is so much easier than re-etching silicon
I'd personally not use chicken bits in software, especially with
growing adoption of staggered update roll outs. Otherwise I'd think
debugfs is indeed a better place for them.

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-07 20:10       ` Jakub Kicinski
@ 2020-12-08  7:14         ` Emmanuel Grumbach
  2020-12-08 15:01         ` Edward Cree
  2020-12-09  2:52         ` Brian Norris
  2 siblings, 0 replies; 9+ messages in thread
From: Emmanuel Grumbach @ 2020-12-08  7:14 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Brian Norris, Kalle Valo, <netdev@vger.kernel.org>, linux-wireless

On Mon, Dec 7, 2020 at 10:14 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 7 Dec 2020 11:35:53 -0800 Brian Norris wrote:
> > On Mon, Dec 7, 2020 at 2:42 AM Kalle Valo <kvalo@codeaurora.org> wrote:
> > > Jakub Kicinski <kuba@kernel.org> writes:
> > > > On Thu,  3 Dec 2020 18:57:32 +0000 (UTC) Kalle Valo wrote:
> > > > There's also a patch which looks like it renames a module parameter.
> > > > Module parameters are considered uAPI.
> > >
> > > Ah, I have been actually wondering that if they are part of user space
> > > API or not, good to know that they are. I'll keep an eye of this in the
> > > future so that we are not breaking the uAPI with module parameter
> > > changes.
> >
> > Is there some reference for this rule (e.g., dictate from on high; or
> > some explanation of reasons)? Or limitations on it? Because as-is,
> > this sounds like one could never drop a module parameter, or remove
> > obsolete features.
>
> TBH its one of those "widely accepted truth" in networking which was
> probably discussed before I started compiling kernels so I don't know
> the full background. But it seems pretty self-evident even without
> knowing the casus that made us institute the rule.
>
> Module parameters are certainly userspace ABI, since user space can
> control them either when loading the module or via sysfs.
>
> > It also suggests that debug-related knobs (which
> > can benefit from some amount of flexibility over time) should go
> > exclusively in debugfs (where ABI guarantees are explicitly not made),
> > even at the expense of usability (dropping a line into
> > /etc/modprobe.d/ is hard to beat).
>
> Indeed, debugfs seems more appropriate.

I don't think that a module parameter and a debugfs knob are
technically equivalent and the only difference would be whether it is
considered ABI or not. The usability of a module parameter is hard to
beat as Brian said, but I think the difference goes beyond usability
~= ease of use. A debugfs hook can't be available at the very start of
the module. You first have to register your debugfs knobs to the
parent dir. And if you want your parent dir to belong to the subsystem
you register to, then you first need to register to the subsystem
which means that a fair amount of code has been running already. A
debugfs hook won't allow you to parametrize this piece of code.

>
> > That's not to say I totally disagree with the original claim, but I'm
> > just interested in knowing precisely what it means.
> >
> > And to put a precise spin on this: what would this rule say about the following?
> >
> > http://git.kernel.org/linus/f06021a18fcf8d8a1e79c5e0a8ec4eb2b038e153
> > iwlwifi: remove lar_disable module parameter
> >
> > Should that parameter have never been introduced in the first place,
> > never be removed, or something else? I think I've seen this sort of
> > pattern before, where features get phased in over time, with module
> > parameters as either escape hatches or as opt-in mechanisms.
> > Eventually, they stabilize, and there's no need (or sometimes, it's
> > actively harmful) to keep the knob around.
> >
> > Or the one that might (?) be in question here:
> > fc3ac64a3a28 rtw88: decide lps deep mode from firmware feature.
> >
> > The original module parameter was useful for enabling new power-saving
> > features, because the driver didn't yet know which chip(s)/firmware(s)
> > were stable with which power features. Now, the driver has learned how
> > to figure out the optimal power settings, so it's dropping the old
> > param and adding an "escape hatch", in case there are problems.
> >
> > I'd say this one is a bit more subtle than the lar_disable example,
> > but I'm still not sure that really qualifies as a "user-visible"
> > change.
>
> If I'm reading this right the pattern seems to be that module
> parameters are used as chicken bits. It's an interesting problem,
> I'm not sure this use case was discussed. My concern would be that
> there is no guarantee users will in fact report the new feature
> fails for them, and therefore grow to depend on the chicken bits.
>
> Since updating software is so much easier than re-etching silicon
> I'd personally not use chicken bits in software, especially with
> growing adoption of staggered update roll outs. Otherwise I'd think
> debugfs is indeed a better place for them.

In this specific case, having put the lar_disable functionality under
debugfs would have meant that the user would have had to:
1) Load the driver
2) write the debugfs hook
3) take the interface down
4) take the interface up

to make the configuration take effect which is hard because typically
the user doesn't control the interface directly but it is controlled
by the wpa_supplicant.
Don't get me wrong, I'm not saying the choice made for this module
parameter was right or wrong, I don't even want to get into that
discussion, I'm just saying that debugfs is not an infra that allows
you to do what you'd do with a module parameter.
In a sense, I guess I'm having the same discussion with our System
guys for whom module parameter = registry key in windows :)

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-07 20:10       ` Jakub Kicinski
  2020-12-08  7:14         ` Emmanuel Grumbach
@ 2020-12-08 15:01         ` Edward Cree
  2020-12-09  2:23           ` Brian Norris
  2020-12-09  2:52         ` Brian Norris
  2 siblings, 1 reply; 9+ messages in thread
From: Edward Cree @ 2020-12-08 15:01 UTC (permalink / raw)
  To: Jakub Kicinski, Brian Norris; +Cc: Kalle Valo, netdev, linux-wireless

On 07/12/2020 20:10, Jakub Kicinski wrote:
> On Mon, 7 Dec 2020 11:35:53 -0800 Brian Norris wrote:
>> Is there some reference for this rule (e.g., dictate from on high; or
>> some explanation of reasons)? Or limitations on it?
> 
> TBH its one of those "widely accepted truth" in networking which was
> probably discussed before I started compiling kernels so I don't know
> the full background.

My understanding is that it's because users can have them in their
 modprobe.conf, which causes breakage if an update removes the param.
 I think the module insert fails if there are unrecognised parameters
 there.

>> this sounds like one could never drop a module parameter, or remove
>> obsolete features.
Not far from the truth.  If you stop the network from coming up on
 boot you can really ruin a sysadmin's day :-/
But usually you can remove the feature, and leave the modparam not
 connected to anything, except maybe a deprecation warning printk if
 it's set to something other than the default.

-ed

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-08 15:01         ` Edward Cree
@ 2020-12-09  2:23           ` Brian Norris
  0 siblings, 0 replies; 9+ messages in thread
From: Brian Norris @ 2020-12-09  2:23 UTC (permalink / raw)
  To: Edward Cree
  Cc: Jakub Kicinski, Kalle Valo, <netdev@vger.kernel.org>,
	linux-wireless

On Tue, Dec 8, 2020 at 7:01 AM Edward Cree <ecree.xilinx@gmail.com> wrote:
> My understanding is that it's because users can have them in their
>  modprobe.conf, which causes breakage if an update removes the param.
>  I think the module insert fails if there are unrecognised parameters
>  there.

That's a nice understanding, but I believe it's an incorrect one:

# echo 'options rtw88_pci doesnotexist=helloworld' >> /etc/modprobe.d/rtw.conf
# modprobe rtw88_pci; echo $?
0

In fact, while I was already quite aware about the removal Jakub is
highlighting (in the rtw88 driver), I was a user of the parameter, and
was quite happy to see it die (because now the driver does the Right
Thing automatically). I still left the option in my modprobe.conf,
while I finished staging upgrades of all my systems. I ran into no
problems, and now that the migration is done, I killed the
modprobe.conf entry.

Brian

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: pull-request: wireless-drivers-next-2020-12-03
  2020-12-07 20:10       ` Jakub Kicinski
  2020-12-08  7:14         ` Emmanuel Grumbach
  2020-12-08 15:01         ` Edward Cree
@ 2020-12-09  2:52         ` Brian Norris
  2 siblings, 0 replies; 9+ messages in thread
From: Brian Norris @ 2020-12-09  2:52 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: Kalle Valo, <netdev@vger.kernel.org>, linux-wireless

Hi Jakub,

On Mon, Dec 7, 2020 at 12:10 PM Jakub Kicinski <kuba@kernel.org> wrote:
> On Mon, 7 Dec 2020 11:35:53 -0800 Brian Norris wrote:
> > On Mon, Dec 7, 2020 at 2:42 AM Kalle Valo <kvalo@codeaurora.org> wrote:
> > > Jakub Kicinski <kuba@kernel.org> writes:
> > > > On Thu,  3 Dec 2020 18:57:32 +0000 (UTC) Kalle Valo wrote:
> > > > There's also a patch which looks like it renames a module parameter.
> > > > Module parameters are considered uAPI.
> > >
> > > Ah, I have been actually wondering that if they are part of user space
> > > API or not, good to know that they are. I'll keep an eye of this in the
> > > future so that we are not breaking the uAPI with module parameter
> > > changes.
> >
> > Is there some reference for this rule (e.g., dictate from on high; or
> > some explanation of reasons)? Or limitations on it? Because as-is,
> > this sounds like one could never drop a module parameter, or remove
> > obsolete features.
>
> TBH its one of those "widely accepted truth" in networking which was
> probably discussed before I started compiling kernels so I don't know
> the full background. But it seems pretty self-evident even without
> knowing the casus that made us institute the rule.
>
> Module parameters are certainly userspace ABI, since user space can
> control them either when loading the module or via sysfs.

I'm not sure it's as self-evident as you claim. Similar arguments
could be made of debugfs (it's even typically mounted under /sys, so
one could accidentally think it *is* sysfs!), except that somewhere
along the line it has been decreed to not be a stable interface.

But anyway, I can acknowledge it's a "widely accepted truth [in some
circles]" and act accordingly (e.g., closer review on their
introduction). I'll also maintain my counter-acknowledgment, that this
approach is not universal. Taking another subystem (fs/) as an
example, I didn't have to look far for similar approaches, where
module parameters were removed as features became obsolete, handled
automatically, etc.:

d3df14535f4a ext4: mballoc: make mb_debug() implementation to use pr_debug()
1565bdad59e9 fscrypt: remove struct fscrypt_ctx
73d03931be2f erofs: kill use_vmap module parameter

Although to be fair, I did find at least one along the way where the
author made a special attempt at a "deprecation notice" while handling
it gracefully:

791205e3ec60 pstore/ram: Introduce max_reason and convert dump_oops

I wouldn't be surprised if that module parameter disappears eventually
though, with little fanfare.

> > It also suggests that debug-related knobs (which
> > can benefit from some amount of flexibility over time) should go
> > exclusively in debugfs (where ABI guarantees are explicitly not made),
> > even at the expense of usability (dropping a line into
> > /etc/modprobe.d/ is hard to beat).
>
> Indeed, debugfs seems more appropriate.

I'll highlight (and agree with) Emmanuel's notice that debugfs is not
a suitable replacement in some cases. I'd still agree debugfs is
better where possible though, because it's clearer about the
(in)stability guarantees, and harder for users to "set and forget"
(per your below notes).

> > Should that parameter have never been introduced in the first place,
> > never be removed, or something else? I think I've seen this sort of
> > pattern before, where features get phased in over time, with module
> > parameters as either escape hatches or as opt-in mechanisms.
> > Eventually, they stabilize, and there's no need (or sometimes, it's
> > actively harmful) to keep the knob around.
...
> If I'm reading this right the pattern seems to be that module
> parameters are used as chicken bits. It's an interesting problem,
> I'm not sure this use case was discussed. My concern would be that
> there is no guarantee users will in fact report the new feature
> fails for them, and therefore grow to depend on the chicken bits.

That's a valid concern. I'm not sure what to do about that, beyond
documentation (which such users probably fail to read) or maybe loud
WARN() prints (which such users could easily ignore).

> Since updating software is so much easier than re-etching silicon
> I'd personally not use chicken bits in software, especially with
> growing adoption of staggered update roll outs.

I'm not sure I understand this sentence; it's perfectly easy to handle
all manner of changed/dropped module params through staged rollout. If
a param is deleted, one can keep it in their modprobe.d configs until
it's fully phased out. If it's renamed with a slightly different
purpose, encode both purposes in your configs. Et cetera.

Brian

> Otherwise I'd think
> debugfs is indeed a better place for them.

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-12-09  2:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-03 18:57 pull-request: wireless-drivers-next-2020-12-03 Kalle Valo
2020-12-04 19:17 ` Jakub Kicinski
2020-12-07 10:40   ` Kalle Valo
2020-12-07 19:35     ` Brian Norris
2020-12-07 20:10       ` Jakub Kicinski
2020-12-08  7:14         ` Emmanuel Grumbach
2020-12-08 15:01         ` Edward Cree
2020-12-09  2:23           ` Brian Norris
2020-12-09  2:52         ` Brian Norris

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.