* pull-request: wireless-next-2023-03-30
@ 2023-03-30 20:56 Johannes Berg
2023-03-31 7:06 ` Jakub Kicinski
2023-03-31 7:10 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 14+ messages in thread
From: Johannes Berg @ 2023-03-30 20:56 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Hi,
Here's new content for -next, this time with a bunch
of the promised iwlwifi work, but also lots of changes
in other drivers and some new stack features.
I also mention it in the tag, but Kalle moved all the
plain C files out of drivers/net/wireless/ into dirs,
just FYI.
Please pull or let me know if there's any problem.
Thanks,
johannes
The following changes since commit 95b744508d4d5135ae2a096ff3f0ee882bcc52b3:
qede: remove linux/version.h and linux/compiler.h (2023-03-10 21:29:54 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git tags/wireless-next-2023-03-30
for you to fetch changes up to aa2aa818cd1198cfa2498116d57cd9f13fea80e4:
wifi: clean up erroneously introduced file (2023-03-30 22:50:12 +0200)
----------------------------------------------------------------
Major stack changes:
* TC offload support for drivers below mac80211
* reduced neighbor report (RNR) handling for AP mode
* mac80211 mesh fast-xmit and fast-rx support
* support for another mesh A-MSDU format
(seems nobody got the spec right)
Major driver changes:
Kalle moved the drivers that were just plain C files
in drivers/net/wireless/ to legacy/ and virtual/ dirs.
hwsim
* multi-BSSID support
* some FTM support
ath11k
* MU-MIMO parameters support
* ack signal support for management packets
rtl8xxxu
* support for RTL8710BU aka RTL8188GU chips
rtw89
* support for various newer firmware APIs
ath10k
* enabled threaded NAPI on WCN3990
iwlwifi
* lots of work for multi-link/EHT (wifi7)
* hardware timestamping support for some devices/firwmares
* TX beacon protection on newer hardware
----------------------------------------------------------------
Abhishek Kumar (1):
wifi: ath10k: snoc: enable threaded napi on WCN3990
Abhishek Naik (1):
wifi: iwlwifi: mvm: Add debugfs to get TAS status
Abinaya Kalaiselvan (1):
wifi: ath11k: Add tx ack signal support for management packets
Aditya Kumar Singh (3):
wifi: ath11k: use proper regulatory reference for bands
wifi: ath11k: add support to parse new WMI event for 6 GHz
wifi: ath11k: add debug prints in regulatory WMI event processing
Alexey V. Vissarionov (1):
wifi: ath6kl: minor fix for allocation size
Aloka Dixit (6):
wifi: mac80211: generate EMA beacons in AP mode
wifi: mac80211_hwsim: move beacon transmission to a separate function
wifi: mac80211_hwsim: Multiple BSSID support
wifi: mac80211_hwsim: EMA support
cfg80211: support RNR for EMA AP
mac80211: support RNR for EMA AP
Avraham Stern (7):
wifi: iwlwifi: mvm: read synced time from firmware if supported
wifi: iwlwifi: mvm: report hardware timestamps in RX/TX status
wifi: iwlwifi: mvm: implement PHC clock adjustments
wifi: iwlwifi: mvm: select ptp cross timestamp from multiple reads
wifi: iwlwifi: mvm: support enabling and disabling HW timestamping
wifi: iwlwifi: mvm: add set_hw_timestamp to mld ops
wifi: iwlwifi: mvm: adjust iwl_mvm_scan_respect_p2p_go_iter() for MLO
Bagas Sanjaya (1):
wifi: mac80211: use bullet list for amsdu_mesh_control formats list
Benjamin Berg (2):
wifi: iwlwifi: mvm: use appropriate link for rate selection
wifi: iwlwifi: mvm: initialize max_rc_amsdu_len per-link
Bitterblue Smith (2):
wifi: rtl8xxxu: RTL8192EU always needs full init
wifi: rtl8xxxu: Support new chip RTL8710BU aka RTL8188GU
Ching-Te Ku (7):
wifi: rtw89: coex: Add more error_map and counter to log
wifi: rtw89: coex: Add WiFi role info v2
wifi: rtw89: coex: Add traffic TX/RX info and its H2C
wifi: rtw89: coex: Add register monitor report v2 format
wifi: rtw89: coex: Fix wrong structure assignment at null data report
wifi: rtw89: coex: Add v2 Bluetooth scan info
wifi: rtw89: coex: Add v5 firmware cycle status report
Christian Marangi (1):
wifi: ath11k: fix SAC bug on peer addition with sta band migration
Christophe JAILLET (1):
wifi: wcn36xx: Slightly optimize PREPARE_HAL_BUF()
Colin Ian King (1):
wifi: ath12k: Fix spelling mistakes in warning messages and comments
Dan Carpenter (2):
wifi: ath12k: use kfree_skb() instead of kfree()
wifi: ath5k: fix an off by one check in ath5k_eeprom_read_freq_list()
Dongliang Mu (1):
wifi: rtw88: fix memory leak in rtw_usb_probe()
Douglas Anderson (2):
wifi: ath11k: Use platform_get_irq() to get the interrupt
wifi: ath5k: Use platform_get_irq() to get the interrupt
Fedor Pchelkin (2):
wifi: ath9k: hif_usb: fix memory leak of remain_skbs
wifi: ath6kl: reduce WARN to dev_dbg() in callback
Felix Fietkau (6):
wifi: mac80211: add support for letting drivers register tc offload support
wifi: mac80211: fix race in mesh sequence number assignment
wifi: mac80211: mesh fast xmit support
wifi: mac80211: use mesh header cache to speed up mesh forwarding
wifi: mac80211: add mesh fast-rx support
wifi: mac80211: implement support for yet another mesh A-MSDU format
Gregory Greenman (22):
wifi: iwlwifi: mvm: fix NULL deref in iwl_mvm_mld_disable_txq
wifi: iwlwifi: mvm: vif preparation for MLO
wifi: iwlwifi: mvm: sta preparation for MLO
wifi: iwlwifi: mvm: adjust smart fifo configuration to MLO
wifi: iwlwifi: mvm: adjust mld_mac_ctxt_/beacon_changed() for MLO
wifi: iwlwifi: mvm: adjust some PS and PM methods to MLD
wifi: iwlwifi: mvm: adjust SMPS for MLO
wifi: iwlwifi: mvm: add link_conf parameter for add/remove/change link
wifi: iwlwifi: mvm: replace bss_info_changed() with vif_cfg/link_info_changed()
wifi: iwlwifi: mvm: adjust internal stations to MLO
wifi: iwlwifi: mvm: add fw link id allocation
wifi: iwlwifi: mvm: adjust to MLO assign/unassign/switch_vif_chanctx()
wifi: iwlwifi: mvm: update iwl_mvm_tx_reclaim() for MLO
wifi: iwlwifi: mvm: refactor iwl_mvm_mac_sta_state_common()
wifi: iwlwifi: mvm: adjust some cleanup functions to MLO
wifi: iwlwifi: mvm: adjust iwl_mvm_sec_key_remove_ap to MLO
wifi: iwlwifi: mvm: adjust radar detection to MLO
wifi: iwlwifi: mvm: adjust rs init to MLO
wifi: iwlwifi: mvm: update mac config when assigning chanctx
wifi: iwlwifi: mvm: rework active links counting
wifi: iwlwifi: mvm: move max_agg_bufsize into host TLC lq_sta
wifi: iwlwifi: bump FW API to 75 for AX devices
Hans de Goede (1):
wifi: brcmfmac: Use ISO3166 country code and rev 0 as fallback on 4356
Jacob Keller (2):
wifi: ipw2x00: convert ipw_fw_error->elem to flexible array[]
wifi: qtnfmac: use struct_size and size_sub for payload length
Jaewan Kim (5):
mac80211_hwsim: add PMSR capability support
wifi: nl80211: make nl80211_send_chandef non-static
mac80211_hwsim: add PMSR request support via virtio
mac80211_hwsim: add PMSR abort support via virtio
mac80211_hwsim: add PMSR report support via virtio
Jiapeng Chong (1):
wifi: ath10k: Remove redundant assignment to changed_flags
Jisoo Jang (1):
wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()
Johannes Berg (28):
wifi: iwlwifi: mvm: avoid sta lookup in queue alloc
wifi: iwlwifi: mvm: rs: print BAD_RATE for invalid HT/VHT index
wifi: iwlwifi: fw: pnvm: fix uefi reduced TX power loading
wifi: iwlwifi: suppress printf warnings in tracing
wifi: iwlwifi: mvm: enable TX beacon protection
wifi: iwlwifi: mvm: add link to firmware earlier
wifi: iwlwifi: mvm: don't check dtim_period in new API
wifi: iwlwifi: mvm: implement link change ops
wifi: iwlwifi: mvm: make some HW flags conditional
wifi: iwlwifi: mvm: fix narrow RU check for MLO
wifi: iwlwifi: mvm: skip MEI update for MLO
wifi: iwlwifi: mvm: use STA link address
wifi: iwlwifi: mvm: rs-fw: don't crash on missing channel
wifi: iwlwifi: mvm: coex: start handling multiple links
wifi: iwlwifi: mvm: make a few warnings only trigger once
wifi: iwlwifi: mvm: rxmq: report link ID to mac80211
wifi: iwlwifi: mvm: skip inactive links
wifi: iwlwifi: mvm: remove only link-specific AP keys
wifi: iwlwifi: mvm: avoid sending MAC context for idle
wifi: iwlwifi: mvm: remove chanctx WARN_ON
wifi: iwlwifi: mvm: use the new lockdep-checking macros
wifi: iwlwifi: mvm: fix station link data leak
wifi: iwlwifi: mvm: clean up mac_id vs. link_id in MLD sta
wifi: iwlwifi: mvm: send full STA during HW restart
wifi: iwlwifi: mvm: free probe_resp_data later
wifi: iwlwifi: separate AP link management queues
wifi: iwlwifi: mvm: correctly use link in iwl_mvm_sta_del()
wifi: clean up erroneously introduced file
Julia Lawall (1):
wifi: iwlwifi: fix typos in comment
Kalle Valo (4):
wifi: ath12k: remove memset with byte count of 278528
wifi: move mac80211_hwsim and virt_wifi to virtual directory
wifi: move raycs, wl3501 and rndis_wlan to legacy directory
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
Kees Cook (1):
wifi: ath: Silence memcpy run-time false positive warning
Kieran Frewen (2):
wifi: mac80211: S1G capabilities information element in probe request
wifi: nl80211: support advertising S1G capabilities
Krishnanand Prabhu (2):
wifi: iwlwifi: mvm: add support for PTP HW clock (PHC)
wifi: iwlwifi: mvm: add support for timing measurement
Lukas Bulwahn (1):
MAINTAINERS: adjust file entries after wifi driver movement
Manikanta Pubbisetty (1):
wifi: nl80211: Update the documentation of NL80211_SCAN_FLAG_COLOCATED_6GHZ
Martin Kaiser (2):
wifi: rtl8xxxu: mark Edimax EW-7811Un V2 as tested
wifi: rtl8xxxu: use module_usb_driver
Miri Korenblit (32):
wifi: iwlwifi: mvm: Refactor STA_HE_CTXT_CMD sending flow
wifi: iwlwifi: mvm: Refactor MAC_CONTEXT_CMD sending flow
wifi: iwlwifi: mvm: add support for the new MAC CTXT command
wifi: iwlwifi: mvm: add support for the new LINK command
wifi: iwlwifi: mvm: add support for the new STA related commands
wifi: iwlwifi: mvm: Add an add_interface() callback for mld mode
wifi: iwlwifi: mvm: Add a remove_interface() callback for mld mode
wifi: iwlwifi: mvm: refactor __iwl_mvm_assign_vif_chanctx()
wifi: iwlwifi: mvm: add an assign_vif_chanctx() callback for MLD mode
wifi: iwlwifi: mvm: refactor __iwl_mvm_unassign_vif_chanctx()
wifi: iwlwifi: mvm: add an unassign_vif_chanctx() callback for MLD mode
wifi: iwlwifi: mvm: add start_ap() and join_ibss() callbacks for MLD mode
wifi: iwlwifi: mvm: add stop_ap() and leave_ibss() callbacks for MLD mode
wifi: iwlwifi: mvm: Don't send MAC CTXT cmd after deauthorization
wifi: iwlwifi: mvm: refactor iwl_mvm_cfg_he_sta()
wifi: iwlwifi: mvm: refactor iwl_mvm_sta
wifi: iwlwifi: mvm: refactor iwl_mvm_sta_send_to_fw()
wifi: iwlwifi: mvm: remove not needed initializations
wifi: iwlwifi: mvm: refactor iwl_mvm_add_sta(), iwl_mvm_rm_sta()
wifi: iwlwifi: mvm: add an indication that the new MLD API is used
wifi: iwlwifi: mvm: add sta handling flows for MLD mode
wifi: iwlwifi: mvm: add some new MLD ops
wifi: iwlwifi: mvm: refactor iwl_mvm_roc()
wifi: iwlwifi: mvm: add cancel/remain_on_channel for MLD mode
wifi: iwlwifi: mvm: unite sta_modify_disable_tx flows
wifi: iwlwifi: mvm: add support for post_channel_switch in MLD mode
wifi: iwlwifi: mvm: add all missing ops to iwl_mvm_mld_ops
wifi: iwlwifi: mvm: fix "modify_mask" value in the link cmd.
wifi: iwlwifi: mvm: fix crash on queue removal for MLD API too
wifi: iwlwifi: mvm: modify link instead of removing it during csa
wifi: iwlwifi: mvm: always use the sta->addr as the peers addr
wifi: iwlwifi: mvm: align to the LINK cmd update in the FW
Mukesh Sisodiya (4):
wifi: iwlwifi: yoyo: Add new tlv for dump file name extension
wifi: iwlwifi: yoyo: Add driver defined dump file name
wifi: iwlwifi: Update configurations for Bnj and Bz devices
wifi: iwlwifi: Update configurations for Bnj device
Muna Sinada (4):
wifi: ath11k: modify accessor macros to match index size
wifi: ath11k: push MU-MIMO params from hostapd to hardware
wifi: ath11k: move HE MCS mapper to a separate function
wifi: ath11k: generate rx and tx mcs maps for supported HE mcs
Nathan Chancellor (2):
wifi: iwlwifi: Avoid disabling GCC specific flag with clang
wifi: iwlwifi: mvm: Use 64-bit division helper in iwl_mvm_get_crosstimestamp_fw()
Ping-Ke Shih (1):
wifi: rtw89: release RX standby timer of beamformee CSI to save power
Ramya Gnanasekar (2):
wifi: ath12k: Handle lock during peer_id find
wifi: ath12k: PCI ops for wakeup/release MHI
Shaul Triebitz (5):
wifi: iwlwifi: mvm: use the link sta address
wifi: iwlwifi: mvm: implement mac80211 callback change_sta_links
wifi: iwlwifi: mvm: translate management frame address
wifi: iwlwifi: mvm: use bcast/mcast link station id
wifi: iwlwifi: mvm: use the correct link queue
Solomon Tan (3):
wifi: iwlwifi: Remove prohibited spaces
wifi: iwlwifi: Add required space before open '('
wifi: iwlwifi: Replace space with tabs as code indent
Tamizh Chelvam Raja (1):
wifi: ath11k: Set ext passive scan flag to adjust passive scan start time
Tom Rix (2):
wifi: iwlwifi: mvm: remove setting of 'sta' parameter
mac80211: minstrel_ht: remove unused n_supported variable
Yang Li (3):
wifi: ath12k: dp_mon: Fix unsigned comparison with less than zero
wifi: ath12k: dp_mon: clean up some inconsistent indentings
wifi: ath10k: Remove the unused function shadow_dst_wr_ind_addr() and ath10k_ce_error_intr_enable()
Yang Yingliang (1):
wifi: ath11k: fix return value check in ath11k_ahb_probe()
MAINTAINERS | 8 +-
drivers/net/wireless/Kconfig | 75 +-
drivers/net/wireless/Makefile | 11 +-
drivers/net/wireless/ath/ath.h | 12 +-
drivers/net/wireless/ath/ath10k/ce.c | 52 -
drivers/net/wireless/ath/ath10k/mac.c | 1 -
drivers/net/wireless/ath/ath10k/snoc.c | 1 +
drivers/net/wireless/ath/ath11k/ahb.c | 10 +-
drivers/net/wireless/ath/ath11k/hw.c | 1 +
drivers/net/wireless/ath/ath11k/mac.c | 255 ++-
drivers/net/wireless/ath/ath11k/peer.c | 5 +-
drivers/net/wireless/ath/ath11k/reg.c | 59 +-
drivers/net/wireless/ath/ath11k/wmi.c | 602 +++++-
drivers/net/wireless/ath/ath11k/wmi.h | 366 +++-
drivers/net/wireless/ath/ath12k/ce.c | 2 +-
drivers/net/wireless/ath/ath12k/core.h | 2 +-
drivers/net/wireless/ath/ath12k/dp.c | 7 +-
drivers/net/wireless/ath/ath12k/dp.h | 6 +-
drivers/net/wireless/ath/ath12k/dp_mon.c | 19 +-
drivers/net/wireless/ath/ath12k/dp_rx.c | 11 +-
drivers/net/wireless/ath/ath12k/dp_tx.c | 2 +-
drivers/net/wireless/ath/ath12k/hal.c | 2 +-
drivers/net/wireless/ath/ath12k/hal.h | 12 +-
drivers/net/wireless/ath/ath12k/hal_desc.h | 10 +-
drivers/net/wireless/ath/ath12k/pci.c | 47 +-
drivers/net/wireless/ath/ath12k/pci.h | 6 +
drivers/net/wireless/ath/ath12k/rx_desc.h | 2 +-
drivers/net/wireless/ath/ath12k/wmi.c | 6 +-
drivers/net/wireless/ath/ath12k/wmi.h | 4 +-
drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
drivers/net/wireless/ath/ath5k/eeprom.c | 2 +-
drivers/net/wireless/ath/ath6kl/bmi.c | 2 +-
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 4 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 19 +
drivers/net/wireless/ath/key.c | 2 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 6 +
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 7 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.h | 3 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 64 +-
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 18 +
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 184 +-
drivers/net/wireless/intel/iwlwifi/fw/api/debug.h | 96 +
.../net/wireless/intel/iwlwifi/fw/api/mac-cfg.h | 426 +++-
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 10 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 32 +-
drivers/net/wireless/intel/iwlwifi/fw/dump.c | 58 +-
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 17 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 3 +
drivers/net/wireless/intel/iwlwifi/fw/img.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/pnvm.c | 20 +-
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 4 +
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 5 +
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c | 3 +
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 4 +
drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/binding.c | 13 +-
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 104 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 39 +-
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 14 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 226 ++-
.../net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 6 +-
.../net/wireless/intel/iwlwifi/mvm/ftm-responder.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 37 +-
drivers/net/wireless/intel/iwlwifi/mvm/link.c | 294 +++
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 439 +++--
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2042 +++++++++++++-------
drivers/net/wireless/intel/iwlwifi/mvm/mld-key.c | 27 +-
drivers/net/wireless/intel/iwlwifi/mvm/mld-mac.c | 306 +++
.../net/wireless/intel/iwlwifi/mvm/mld-mac80211.c | 1074 ++++++++++
drivers/net/wireless/intel/iwlwifi/mvm/mld-sta.c | 1058 ++++++++++
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 518 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 48 +-
drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 45 +-
drivers/net/wireless/intel/iwlwifi/mvm/ptp.c | 326 ++++
drivers/net/wireless/intel/iwlwifi/mvm/quota.c | 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 174 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 66 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 16 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 30 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 36 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 33 +-
drivers/net/wireless/intel/iwlwifi/mvm/sf.c | 38 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 688 ++++---
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 132 +-
drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 8 +-
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/time-sync.c | 173 ++
drivers/net/wireless/intel/iwlwifi/mvm/time-sync.h | 30 +
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 80 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 91 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 29 +-
drivers/net/wireless/legacy/Kconfig | 55 +
drivers/net/wireless/legacy/Makefile | 6 +
drivers/net/wireless/{ => legacy}/ray_cs.c | 0
drivers/net/wireless/{ => legacy}/ray_cs.h | 0
drivers/net/wireless/{ => legacy}/rayctl.h | 0
drivers/net/wireless/{ => legacy}/rndis_wlan.c | 0
drivers/net/wireless/{ => legacy}/wl3501.h | 0
drivers/net/wireless/{ => legacy}/wl3501_cs.c | 0
drivers/net/wireless/quantenna/qtnfmac/commands.c | 7 +-
drivers/net/wireless/realtek/rtl8xxxu/Kconfig | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/Makefile | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 313 ++-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c | 5 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c | 7 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 2 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 6 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8710b.c | 1878 ++++++++++++++++++
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 5 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 5 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 297 ++-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 44 +
drivers/net/wireless/realtek/rtw88/usb.c | 2 +-
drivers/net/wireless/realtek/rtw89/coex.c | 859 +++++++-
drivers/net/wireless/realtek/rtw89/coex.h | 5 +
drivers/net/wireless/realtek/rtw89/core.h | 239 ++-
drivers/net/wireless/realtek/rtw89/fw.c | 142 ++
drivers/net/wireless/realtek/rtw89/fw.h | 138 ++
drivers/net/wireless/realtek/rtw89/mac.c | 35 +-
drivers/net/wireless/realtek/rtw89/reg.h | 2 +
drivers/net/wireless/virtual/Kconfig | 20 +
drivers/net/wireless/virtual/Makefile | 3 +
.../net/wireless/{ => virtual}/mac80211_hwsim.c | 869 ++++++++-
.../net/wireless/{ => virtual}/mac80211_hwsim.h | 58 +
drivers/net/wireless/{ => virtual}/virt_wifi.c | 0
include/net/cfg80211.h | 39 +-
include/net/mac80211.h | 77 +
include/uapi/linux/nl80211.h | 24 +-
net/mac80211/cfg.c | 70 +-
net/mac80211/driver-ops.h | 17 +
net/mac80211/ieee80211_i.h | 53 +-
net/mac80211/iface.c | 11 +
net/mac80211/mesh.c | 98 +-
net/mac80211/mesh.h | 44 +
net/mac80211/mesh_hwmp.c | 37 +-
net/mac80211/mesh_pathtbl.c | 282 +++
net/mac80211/rc80211_minstrel_ht.c | 6 -
net/mac80211/rx.c | 131 +-
net/mac80211/sta_info.h | 9 +-
net/mac80211/trace.h | 25 +
net/mac80211/tx.c | 197 +-
net/mac80211/util.c | 23 +
net/wireless/nl80211.c | 93 +-
net/wireless/util.c | 36 +-
148 files changed, 14823 insertions(+), 2337 deletions(-)
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/link.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/mld-mac.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/mld-mac80211.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/mld-sta.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/time-sync.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/time-sync.h
create mode 100644 drivers/net/wireless/legacy/Kconfig
create mode 100644 drivers/net/wireless/legacy/Makefile
rename drivers/net/wireless/{ => legacy}/ray_cs.c (100%)
rename drivers/net/wireless/{ => legacy}/ray_cs.h (100%)
rename drivers/net/wireless/{ => legacy}/rayctl.h (100%)
rename drivers/net/wireless/{ => legacy}/rndis_wlan.c (100%)
rename drivers/net/wireless/{ => legacy}/wl3501.h (100%)
rename drivers/net/wireless/{ => legacy}/wl3501_cs.c (100%)
create mode 100644 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8710b.c
create mode 100644 drivers/net/wireless/virtual/Kconfig
create mode 100644 drivers/net/wireless/virtual/Makefile
rename drivers/net/wireless/{ => virtual}/mac80211_hwsim.c (87%)
rename drivers/net/wireless/{ => virtual}/mac80211_hwsim.h (80%)
rename drivers/net/wireless/{ => virtual}/virt_wifi.c (100%)
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: pull-request: wireless-next-2023-03-30 2023-03-30 20:56 pull-request: wireless-next-2023-03-30 Johannes Berg @ 2023-03-31 7:06 ` Jakub Kicinski 2023-04-03 22:45 ` Richard Cochran 2023-03-31 7:10 ` patchwork-bot+netdevbpf 1 sibling, 1 reply; 14+ messages in thread From: Jakub Kicinski @ 2023-03-31 7:06 UTC (permalink / raw) To: Johannes Berg; +Cc: netdev, linux-wireless, Richard Cochran On Thu, 30 Mar 2023 22:56:11 +0200 Johannes Berg wrote: > * hardware timestamping support for some devices/firwmares Was Richard CCed on those patches? Would have been good to see his acks there. Adding him here in case he wants to take a look 'post factum'. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-03-31 7:06 ` Jakub Kicinski @ 2023-04-03 22:45 ` Richard Cochran 2023-04-13 3:33 ` Richard Cochran 0 siblings, 1 reply; 14+ messages in thread From: Richard Cochran @ 2023-04-03 22:45 UTC (permalink / raw) To: Jakub Kicinski; +Cc: Johannes Berg, netdev, linux-wireless On Fri, Mar 31, 2023 at 12:06:48AM -0700, Jakub Kicinski wrote: > On Thu, 30 Mar 2023 22:56:11 +0200 Johannes Berg wrote: > > * hardware timestamping support for some devices/firwmares > > Was Richard CCed on those patches? > Would have been good to see his acks there. > > Adding him here in case he wants to take a look 'post factum'. Timestamping on wifi is something I've spent a fair amount of time thinking about. I'll take a look but not this week as I am on vacation until April 10. Thanks, Richard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-03 22:45 ` Richard Cochran @ 2023-04-13 3:33 ` Richard Cochran 2023-04-18 13:35 ` Greenman, Gregory 0 siblings, 1 reply; 14+ messages in thread From: Richard Cochran @ 2023-04-13 3:33 UTC (permalink / raw) To: Jakub Kicinski Cc: Johannes Berg, netdev, linux-wireless, avraham.stern, gregory.greenman On Tue, Apr 04, 2023 at 12:45:46AM +0200, Richard Cochran wrote: > On Fri, Mar 31, 2023 at 12:06:48AM -0700, Jakub Kicinski wrote: > > On Thu, 30 Mar 2023 22:56:11 +0200 Johannes Berg wrote: > > > * hardware timestamping support for some devices/firwmares > > > > Was Richard CCed on those patches? > > Would have been good to see his acks there. > > > > Adding him here in case he wants to take a look 'post factum'. > > Timestamping on wifi is something I've spent a fair amount of time > thinking about. I'll take a look but not this week as I am on > vacation until April 10. This so-called "hardware timestamping support" appears to be a big nothing burger. I took a quick look at the PR, and AFAICT this is only internal code for iwlwifi/mvm, and the code is dead code, meaning not reachable by user space for any practical purpose. Like in drivers/net/wireless/intel/iwlwifi/mvm/ops.c ... RX_HANDLER_GRP(LEGACY_GROUP, WNM_80211V_TIMING_MEASUREMENT_NOTIFICATION, iwl_mvm_time_sync_msmt_event, RX_HANDLER_SYNC, struct iwl_time_msmt_notify), RX_HANDLER_GRP(LEGACY_GROUP, WNM_80211V_TIMING_MEASUREMENT_CONFIRM_NOTIFICATION, iwl_mvm_time_sync_msmt_confirm_event, RX_HANDLER_SYNC, struct iwl_time_msmt_cfm_notify), These aren't useful, or are they? I am aware of FTM etc, but I see no attempt to do anything with it in this code. Thanks, Richard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-13 3:33 ` Richard Cochran @ 2023-04-18 13:35 ` Greenman, Gregory 2023-04-20 3:43 ` Richard Cochran 0 siblings, 1 reply; 14+ messages in thread From: Greenman, Gregory @ 2023-04-18 13:35 UTC (permalink / raw) To: richardcochran, kuba; +Cc: linux-wireless, johannes, netdev, Stern, Avraham On Wed, 2023-04-12 at 20:33 -0700, Richard Cochran wrote: > On Tue, Apr 04, 2023 at 12:45:46AM +0200, Richard Cochran wrote: > > On Fri, Mar 31, 2023 at 12:06:48AM -0700, Jakub Kicinski wrote: > > > On Thu, 30 Mar 2023 22:56:11 +0200 Johannes Berg wrote: > > > > * hardware timestamping support for some devices/firwmares > > > > > > Was Richard CCed on those patches? > > > Would have been good to see his acks there. > > > > > > Adding him here in case he wants to take a look 'post factum'. > > > > Timestamping on wifi is something I've spent a fair amount of time > > thinking about. I'll take a look but not this week as I am on > > vacation until April 10. > > This so-called "hardware timestamping support" appears to be a big > nothing burger. > > I took a quick look at the PR, and AFAICT this is only internal code > for iwlwifi/mvm, and the code is dead code, meaning not reachable by > user space for any practical purpose. > > Like in drivers/net/wireless/intel/iwlwifi/mvm/ops.c ... > > RX_HANDLER_GRP(LEGACY_GROUP, > WNM_80211V_TIMING_MEASUREMENT_NOTIFICATION, > iwl_mvm_time_sync_msmt_event, RX_HANDLER_SYNC, > struct iwl_time_msmt_notify), > RX_HANDLER_GRP(LEGACY_GROUP, > WNM_80211V_TIMING_MEASUREMENT_CONFIRM_NOTIFICATION, > iwl_mvm_time_sync_msmt_confirm_event, RX_HANDLER_SYNC, > struct iwl_time_msmt_cfm_notify), > > These aren't useful, or are they? > > I am aware of FTM etc, but I see no attempt to do anything with it in > this code. > > Thanks, > Richard Just a few clarifications. These two notifications are internal to iwlwifi, sent by the firmware to the driver. Then, the timestamps are added to the rx/tx status via mac80211 api. Actually, we already have a functional implementation of ptp4l over wifi using this driver support. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-18 13:35 ` Greenman, Gregory @ 2023-04-20 3:43 ` Richard Cochran 2023-04-23 13:33 ` Stern, Avraham 0 siblings, 1 reply; 14+ messages in thread From: Richard Cochran @ 2023-04-20 3:43 UTC (permalink / raw) To: Greenman, Gregory; +Cc: kuba, linux-wireless, johannes, netdev, Stern, Avraham On Tue, Apr 18, 2023 at 01:35:50PM +0000, Greenman, Gregory wrote: > Just a few clarifications. These two notifications are internal to iwlwifi, sent > by the firmware to the driver. Obviously. > Then, the timestamps are added to the rx/tx status > via mac80211 api. Where? I don't see that in the kernel anywhere. Your WiFi driver would need to implement get_ts_info, no? > Actually, we already have a functional implementation of ptp4l > over wifi using this driver support. Why are changes needed to user space at all? Thanks, Richard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-20 3:43 ` Richard Cochran @ 2023-04-23 13:33 ` Stern, Avraham 2023-04-24 22:04 ` Richard Cochran 0 siblings, 1 reply; 14+ messages in thread From: Stern, Avraham @ 2023-04-23 13:33 UTC (permalink / raw) To: Richard Cochran, Greenman, Gregory; +Cc: kuba, linux-wireless, johannes, netdev hi Richard, I will try to clarify. > > Then, the timestamps are added to the rx/tx status >> via mac80211 api. > Where? I don't see that in the kernel anywhere. > Your WiFi driver would need to implement get_ts_info, no? so, the rx/tx timestamp is put in the skb hwstamps field, and the ack (tx/rx) timestamp is put in the mac80211 rx/tx status. if you follow mac80211/cfg80211 patches sent earlier, you'll see that mac80211 uses these to fill cfg80211_rx_info and cfg80211_tx_status with the timestamps. eventually, these are sent to userspace in nl80211_send_mgmt() and nl80211_frame_tx_status() as part of the frame's meta data. since wifi uses management frames for time sync, the timestamping capability is also advertised using nl80211 capability (NL80211_ATTR_MAX_HW_TIMESTAMP_PEERS). implementing get_ts_info() doesn't seem right since it's usually queried over a data socket, and the wifi driver doesn't timestamp data frames (since these are not used for time sync over wifi). >> Actually, we already have a functional implementation of ptp4l >> over wifi using this driver support. > Why are changes needed to user space at all? As you mentioned, time sync over wifi leverages the existing FTM protocol, which is different from the protocols used over ethernet. In particular, FTM uses management frames unlike the ethernet protocols that use data frames. So obviously for ptp4l to support time sync over wifi, it will need to implement the FTM protocol (sending FTM frames via nl80211 socket) and use the kernel APIs added here to get tx/rx and acks timestamps. Then it can pass the collected data (t1, t2, path delay etc.) to the existing logic to calculate the time sync itself. Note that for time sync the FTM frames also need to contain a vendor specific IE with all the time sync information (which is dynamic since it contains timestamps data from each measurement), so using FTM offload is not a good option. I hope this clarifies thing a bit. Thanks, Avi ________________________________________ From: Richard Cochran <richardcochran@gmail.com> Sent: Thursday, April 20, 2023 6:43 AM To: Greenman, Gregory Cc: kuba@kernel.org; linux-wireless@vger.kernel.org; johannes@sipsolutions.net; netdev@vger.kernel.org; Stern, Avraham Subject: Re: pull-request: wireless-next-2023-03-30 On Tue, Apr 18, 2023 at 01:35:50PM +0000, Greenman, Gregory wrote: > Just a few clarifications. These two notifications are internal to iwlwifi, sent > by the firmware to the driver. Obviously. > Then, the timestamps are added to the rx/tx status > via mac80211 api. Where? I don't see that in the kernel anywhere. Your WiFi driver would need to implement get_ts_info, no? > Actually, we already have a functional implementation of ptp4l > over wifi using this driver support. Why are changes needed to user space at all? Thanks, Richard --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-23 13:33 ` Stern, Avraham @ 2023-04-24 22:04 ` Richard Cochran 2023-04-25 1:29 ` Richard Cochran 0 siblings, 1 reply; 14+ messages in thread From: Richard Cochran @ 2023-04-24 22:04 UTC (permalink / raw) To: Stern, Avraham; +Cc: Greenman, Gregory, kuba, linux-wireless, johannes, netdev On Sun, Apr 23, 2023 at 01:33:19PM +0000, Stern, Avraham wrote: > hi Richard, > > I will try to clarify. > > > > > Then, the timestamps are added to the rx/tx status > >> via mac80211 api. > > > Where? I don't see that in the kernel anywhere. > > > Your WiFi driver would need to implement get_ts_info, no? > > so, the rx/tx timestamp is put in the skb hwstamps field, and the ack (tx/rx) timestamp is put in the mac80211 rx/tx status. > if you follow mac80211/cfg80211 patches sent earlier, you'll see that mac80211 uses these to fill cfg80211_rx_info and cfg80211_tx_status with > the timestamps. Um, no, I haven't seen those. > eventually, these are sent to userspace in nl80211_send_mgmt() and nl80211_frame_tx_status() as part of the frame's meta data. > > since wifi uses management frames for time sync, the timestamping capability is also advertised using nl80211 capability (NL80211_ATTR_MAX_HW_TIMESTAMP_PEERS). > implementing get_ts_info() doesn't seem right since it's usually queried over a data socket, and the wifi driver doesn't timestamp data frames (since these are not used > for time sync over wifi). Okay, so you are creatively making some kind of back door for wifi. Whatever. > >> Actually, we already have a functional implementation of ptp4l > >> over wifi using this driver support. > > > Why are changes needed to user space at all? > > As you mentioned, time sync over wifi leverages the existing FTM protocol, which is different from the protocols used over ethernet. > In particular, FTM uses management frames unlike the ethernet protocols that use data frames. > So obviously for ptp4l to support time sync over wifi, it will need to implement the FTM protocol (sending FTM frames via nl80211 socket) and use the kernel APIs added here ptp4l isn't doing to implement anything without my ok. Thanks, Richard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-24 22:04 ` Richard Cochran @ 2023-04-25 1:29 ` Richard Cochran 2023-04-25 7:03 ` Stern, Avraham 0 siblings, 1 reply; 14+ messages in thread From: Richard Cochran @ 2023-04-25 1:29 UTC (permalink / raw) To: Stern, Avraham; +Cc: Greenman, Gregory, kuba, linux-wireless, johannes, netdev On Mon, Apr 24, 2023 at 03:04:07PM -0700, Richard Cochran wrote: > On Sun, Apr 23, 2023 at 01:33:19PM +0000, Stern, Avraham wrote: > > So obviously for ptp4l to support time sync over wifi, it will > > need to implement the FTM protocol (sending FTM frames via nl80211 > > socket) and use the kernel APIs added here "obviously" ? In the past, I made quite some thougts about how to best implement PTP over Wifi. I may have even written something about it. In any case, "implement the FTM protocol (sending FTM frames via nl80211 socket)" was definitely NOT one of the approaches. Wouldn't it have great to start a discussion before plowing ahead and hacking something into the kernel? Oh well. Thanks, Richard ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: pull-request: wireless-next-2023-03-30 2023-04-25 1:29 ` Richard Cochran @ 2023-04-25 7:03 ` Stern, Avraham 2023-04-26 2:43 ` Richard Cochran 0 siblings, 1 reply; 14+ messages in thread From: Stern, Avraham @ 2023-04-25 7:03 UTC (permalink / raw) To: Richard Cochran; +Cc: Greenman, Gregory, kuba, linux-wireless, johannes, netdev > On Mon, Apr 24, 2023 at 03:04:07PM -0700, Richard Cochran wrote: > > On Sun, Apr 23, 2023 at 01:33:19PM +0000, Stern, Avraham wrote: > > So obviously for ptp4l to support time sync over wifi, it will need > > to implement the FTM protocol (sending FTM frames via nl80211 > > socket) and use the kernel APIs added here > "obviously" ? > In the past, I made quite some thougts about how to best implement PTP over Wifi. I may have even written something about it. Sorry, of course nothing goes into ptp4l without your approval. I was not aware about what you previously wrote on this subject. > In any case, "implement the FTM protocol (sending FTM frames via > nl80211 socket)" was definitely NOT one of the approaches. My understanding was that 1588-2019 and 8021AS-2020 mandate the usage of TM/FTM for PTP over wifi. Since FTM offload (as it is today) is not reporting the raw timestamps (only the calculated range) and also doesn't support adding the needed vendor IEs, it didn't seem to fit. Can you please explain what I am missing? > Wouldn't it have great to start a discussion before plowing ahead and hacking something into the kernel? > Oh well. Having the timestamps of the frames seemed like a basic capability that userspace will need to implement ptp over wifi, regardless of the selected approach. Apparently you had other ways in mind, so I would love to have that discussion and hear about it. Thanks, Avi. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-25 7:03 ` Stern, Avraham @ 2023-04-26 2:43 ` Richard Cochran 2023-04-26 14:04 ` Richard Cochran 2023-05-07 16:32 ` Stern, Avraham 0 siblings, 2 replies; 14+ messages in thread From: Richard Cochran @ 2023-04-26 2:43 UTC (permalink / raw) To: Stern, Avraham; +Cc: Greenman, Gregory, kuba, linux-wireless, johannes, netdev On Tue, Apr 25, 2023 at 07:03:50AM +0000, Stern, Avraham wrote: > Having the timestamps of the frames seemed like a basic capability that userspace will need to implement ptp over wifi, regardless of the selected approach. Having time stamps on unicast PTP frames would be a great solution. But I'm guessing that you aren't talking about that? > Apparently you had other ways in mind, so I would love to have that discussion and hear about it. Let's back up a bit. Since you would like to implement PTP over Wifi in Linux, may I suggest that the first step is to write up and publish your design idea so that everyone gets on the same page? Your design might touch upon a number of points... - Background - Difficulty of multicast protocols (like PTP) over WiFi. - What do the networking standards say? - IEEE Std 802.11-2016 - Timing Measurement (TM) - Fine Timing Measurement (FTM) - IEEE 1588 - Media-Dependent, Media-Independent MDMI - Special Ports - 802.1AS - Fine Timing Measurement Burst - Which of the above can be used for a practical solution? - What are the advantages/disadvantages of TM versus FTM? - What alternatives might we pursue? - unicast PTP without FTM - AP as transparent clock - Existing Linux interfaces for time synchronization - What can be used as is? - What new interaces or extensions are needed, and why? - Vendor support - How will we encourage broad acceptance/coverage? IMO, the simplest way that will unlock many use cases is to provide time stamps for single unicast frames, like in ieee80211_rx_status.device_timestamp and expose an adjustable PHC using timecounter/cyclecounter over the free running usec clock. Then you could synchronize client/AP over unicast IPv4 PTP (for example) with no user space changes needed, AND it would work on all radios, even those that don't implement FTM. Thanks, Richard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-04-26 2:43 ` Richard Cochran @ 2023-04-26 14:04 ` Richard Cochran 2023-05-07 16:32 ` Stern, Avraham 1 sibling, 0 replies; 14+ messages in thread From: Richard Cochran @ 2023-04-26 14:04 UTC (permalink / raw) To: Stern, Avraham; +Cc: Greenman, Gregory, kuba, linux-wireless, johannes, netdev On Tue, Apr 25, 2023 at 07:43:40PM -0700, Richard Cochran wrote: > Your design might touch upon a number of points... I forgot the most important point, IMO: How will you handle time distribution across a wireless network? Consider the following simple case. GPS Radio ------> Station-A ~~~~~~ AP ~~~~~~ Station-B 1PPS WiFi WiFi Here Station-A should become the PTP server, and Station-B should become a PTP client. In 1588, this is accomplished by forming a spanning tree over the wired network, based on time quality fields advertised. AFAICT, the standards provide almost no hint how this is supposed to work over WiFi. I'd like to know your plans for solving this aspect. Just exposing FTM to user space doesn't help all. It gets even better. Replace that "AP" with "mesh network" and image Station-B moves around... What happens next? Thanks, Richard ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: pull-request: wireless-next-2023-03-30 2023-04-26 2:43 ` Richard Cochran 2023-04-26 14:04 ` Richard Cochran @ 2023-05-07 16:32 ` Stern, Avraham 1 sibling, 0 replies; 14+ messages in thread From: Stern, Avraham @ 2023-05-07 16:32 UTC (permalink / raw) To: Richard Cochran; +Cc: Greenman, Gregory, kuba, linux-wireless, johannes, netdev Hi Richard, I will try to explain my point of view on the topic. I tried to highlight the areas where wifi may be different from ethernet. The below is only my perspective, in order to get everyone on the same page. Please comment/correct me wherever you find fit as your perspective is definitely broader than mine. The PTP protocol consists of 2 primary parts: a. best master selection algorithm using "general PTP messages" (messages that are not timestamped) b. time sync, using "event PTP messages" (messages that are timestamped) A. Master selection algorithm ---------------------------------------- Regarding the master selection, PTP requires that announce messages are delivered to all PTP ports within a ptp communication path (which may include switches, bridges etc.). For that purpose, the 1588-2019 standard defines that "Announce messages are either sent in multicast or the Announce information is replicated to all PTP Ports in the PTP Communication Path using unicast PTP messages." (section 6.2). It seems that multicast frames are used to allow the announce messages to propagate through transparent clocks or components of the network that does not support PTP, but has not effect when the receiving PTP port is a boundary clock or an ordinary clock since the standard specifies that "All PTP messages except PTP management messages are terminated at a Boundary Clock" (and ordinary clocks only have 1 port). In wifi networks, the usage of multicast frames is limited since only the AP can send multicast to all associated stations. A station that wants to send a multicast frame sends it as a unicast frame to the AP and the AP then re-sends it as multicast to all other stations. However, the 1588-2019 standard specifies that "Special Ports shall be used to transfer time over a network where the time transfer is not based on the use of PTP timing messages" (which is the case for wifi networks. I will elaborate more on that in the time sync section) and that "Special Ports shall be used only on Ordinary Clocks or Boundary Clocks" (section 11.5.1), so on wifi networks there will be only ordinary and boundary clocks, which means using unicast instead of multicast should work just the same. Since the stations must be associated to the AP (otherwise they cannot exchange data frames at all, so can't send/receive the announce messages to begin with), the unicast addresses are known both at the station and the AP side. So to summarize, using the unicast option for announce messages should work on wifi networks without any changes required. Let's examine some basic topologies: 1. The basic wifi network consists of an AP and several stations: Station A <--------- AP --------> station B In the common case, the AP will be master and stations A and B will follow. 2. In a Case like: GPS Radio ------> Station-A ~~~~~~ AP ~~~~~~ Station-B 1PPS WiFi WiFi The AP will act as a boundary clock, with the port connected to station A as a slave, and the port connected to station B as master. In addition, the AP can also bridge Ethernet and wifi networks, acting as the boundary clock, e.g. as a slave on the ethernet port and master on the wifi port. B. Time synchronization -------------------------------- PTP defines two mechanisms for time synchronization which are used over ethernet: The delay request-response mechanism and The peer-to-peer delay mechanism. Both use a similar mechanism to measure the path (or link) delay: 1. transmit a data frame from peer A to peer B, save the transmission time (t1) and reception time (t2). 2. transmit a data frame from peer B to peer A, save the transmission time (t3) and reception time (t4). 3. send (t1, t4) or (t2, t3) to the other peer. Using these mechanisms as is over a wifi link is subject to the following drawbacks: (i) The 1588-2019 standard outlines that these mechanisms "assume that the master-to-slave and slave-to-master propagation times are equal. Any asymmetry in propagation time introduces an error in the computed value of the clock offset. The computed mean propagation time differs from the actual propagation times due to the asymmetry." (section 6.6.3). However, in wifi networks the station may be moving, which makes the propagation delay change over time due to the changing distance. Because of wifi power save mechanisms, the time between two data frames may be relatively large (e.g. an AP with a typical beacon interval of 100 TUs and DTIM of 3, the station may be in power save for more than 300TUs, so the time between the sync message and the delay request message may get close to even 500ms). So when using data frames the propagation delay is likely to be asymmetric, which will lead to time sync error. (ii) over wifi, a frame may be retransmitted (if not acked by the receiving station). This may lead to a situation where station A takes the timestamp t1 on the first transmission while station B takes timestamp t2 on one of the retransmissions (or vice versa). This will introduce a significant error since t1 and t2 are not referring to the same event. The 802.11 standard defines mechanisms for measuring the path delay, called Timing Measurement (TM) and Fine Timing Measurement (FTM). These mechanisms use a similar principle for calculating the path delay as the PTP mechanisms, but the timestamps are recorded on a management frame and the corresponding ack. This eliminates issue (i) , since the ack must be transmitted 16us after the frame is received (802.11 definitions). This make the path delay symmetric for any practical use-case. Using the ack for measuring the path delay also implies better usage of the network: while in the delay request-response mechanism, 4 frames are potentially needed for 1 measurement, in FTM 3 frames yield 2 measurement results (which can be averaged to get better accuracy, for example). In addition, the 802.11 standard defines the retransmissions behavior for these specific frame types to eliminate issue (ii). In order to use the pre-defined 802.11 mechanisms to measure the path delay over wifi, the 1588-2019 defined a new port type - the special port. (as stated in 11.5.2.2.2: "This interface is new to this edition and is introduced to facilitate the use within the PTP protocol of media that implement their own methodology for measuring path delay and transferring time, for example, IEEE Std 802.11"). A special port has a media-dependent and media-independent parts. The media-independent part is responsible for managing the master slave states and calculating the time synchronization using the inputs from the media dependent layer. The media-dependent layer measures mean path delay and sends and receives time synchronization information (passed to the media-independent part). The 1588-2019 defines the interface between the two parts, called MDMI interface. The operation of the media-dependent part for 802.11 is further defined in the 802.1AS-2020 standard, which defines also the state-machines for using TM or FTM to measure the path delay, the measurement parameters etc. To summarize, the standards (1588 and 802.1AS) mandate the usage of special ports and TM/FTM for time sync over wifi, for the former mentioned reasons (and probably more). The 1588-2019 also defines the usage of a special port for boundary clock and ordinary clock only (but not transparent clock). This is a results of using a medium specific method to measure the path delay, which is defined point to point, which is not suitable for a transparent clock. This makes the "AP as transparent clock" option not supported by the standard (the AP can be a boundary clock in the station -> AP -> station topology). (theoretically, the AP could be used as transparent clock if unicast data frames where used for timestamping, but it would be subject to the problems mentioned). There are also implementation considerations to favor the usage of TM/FTM over timestamping data frames: Recording an accurate Rx timestamp on a wifi packet is difficult because the received signal may have interference, reflections etc. Multipath detection algorithms are usually used to calculate a more accurate timestamps. There algorithms are relatively heavy for network cards. Having to calculate them for each data packet will introduce an unnecessary overhead. Of course, this can be minimized by calculating the Rx timestamp only on data packets that are used for time sync, but network cards usually don't inspect data packets for their content, so they may not be able to easily tell which data packets should be timestamped. On the other hand, many network cards already support FTM (for ranging) so they already have the ability to timestamp FTM frames. After deciding to follow the standards, the next question is which protocol should be preferred, TM or FTM? As implied by its name, FTM has better accuracy. While TM has units of 10ns, FTM has units of picoseconds. And as formerly mentioned, many wifi vendors already support FTM for ranging (which TM is of course not suitable for because of the low accuracy). So it seems FTM should be preferred if possible. (in fact, TM is probably only left for backward compatibility, but I don't know anyone who already uses it for time sync?) Anyway, adding support for both is also an option, since the building blocks are the same and the TM protocol is fairly simple. Kernel interfaces ------------------------ The kernel currently have 2 interfaces for the PTP time sync. The first one is the PHC interface for devices to expose clock operations. This interface is related only to the media-independent part of the port, and thus can be used as-is for wifi interfaces too. The second interface is the SO_TIMESTAMPING socket options, for timestamping data frames sent/received over a socket. This kernel API is not suitable for wifi which will use TM/FTM, since TM/FTM uses 802.11 management frames for time sync, not data frames. 802.11 management frames are not sent over a regular socket but using NL80211 APIs. In addition, for TM/FTM the timestamp of the ack is also needed, which is not supported by the SO_TIMESTAMPING socket options. Thus another interface is needed for TM/FTM timestamping. The kernel already has NL80211 APIs for triggering FTM measurements. However, these APIs are tailored for measuring the range from the AP, and the result reports only the distance from the AP, but not the timestamps collected for the FTM frames. As such, it is not useful as is for time sync because for time sync the timestamps are needed for the media-independent part to calculate the sync. In addition, as specified in 802.1AS-2020, for time sync the FTM frames need to include a vendor IE with all the PTP data (sync or followup messages). The current APIs do not allow adding IEs to the frames used in the measurement. Extending these APIs to support time sync also seems wrong since the measurement API triggers a burst (i.e. many FTM frames, each one produces a measurement results, and the driver reports one accumulated result according to it's own logic - e.g. average) while for time sync each FTM frame should have a different PTP data, so this will make the API complicated and will require massive changes in drivers to support. Another option is to add to NL80211 the capability to timestamp TM/FTM frames. This is equivalent to the SO_TIMESTAMPING socket options in a sense - telling the driver to timestamp the required frames only and report the timestamps to userspace. This is the interface we introduced in our change. This API change requires small effort from drivers/NICs - timestamp TM/FTM frames only, per request. Since many hw vendors already support FTM which means they have the ability to timestamp these frames, supporting the new API comes down to reporting these timestamps to the driver. It is likely that any vendor that supports FTM will be able to support the new API with minimal effort. So the basic idea was to provide userspace similar APIs to what's used over ethernet - the PHC clock and a way to get timestamps for the desired frames (data over ethernet, TM/FTM over wifi). From that point on, the userspace implementation, which already has the media-independent part, will just need to add the wifi media dependent part (i.e. the TM/FTM state machine define in 802.1AS) and pass the reported timestamps to the media-independent part. Then time-sync will be supported by all vendors that implement the timestamping and the PHC clock APIs. (but that is of course just a suggestion and will require more in-depth design. Just added it here to describe how I imagined the big picture). >> IMO, the simplest way that will unlock many use cases is to provide time stamps for single unicast frames, like in ieee80211_rx_status.device_timestamp and expose an adjustable PHC using timecounter/cyclecounter over the free running usec clock. Then you could synchronize client/AP over unicast IPv4 PTP >> (for example) with no user space changes needed, AND it would work on all radios, even those that don't implement FTM. I Agree, this would work without any userspace changes, but it is not with accordance to the standards (which have their considerations , which I tried to review some of above). And it still requires devices to timestamp data frames. The suggested API also doesn't require devices to implement FTM, only to timestamp FTM frames. I hope this makes things a little bit more clear. Please let me know what you think. Thanks, Avi. -----Original Message----- From: Richard Cochran <richardcochran@gmail.com> Sent: Wednesday, April 26, 2023 05:44 To: Stern, Avraham <avraham.stern@intel.com> Cc: Greenman, Gregory <gregory.greenman@intel.com>; kuba@kernel.org; linux-wireless@vger.kernel.org; johannes@sipsolutions.net; netdev@vger.kernel.org Subject: Re: pull-request: wireless-next-2023-03-30 On Tue, Apr 25, 2023 at 07:03:50AM +0000, Stern, Avraham wrote: > Having the timestamps of the frames seemed like a basic capability that userspace will need to implement ptp over wifi, regardless of the selected approach. Having time stamps on unicast PTP frames would be a great solution. But I'm guessing that you aren't talking about that? > Apparently you had other ways in mind, so I would love to have that discussion and hear about it. Let's back up a bit. Since you would like to implement PTP over Wifi in Linux, may I suggest that the first step is to write up and publish your design idea so that everyone gets on the same page? Your design might touch upon a number of points... - Background - Difficulty of multicast protocols (like PTP) over WiFi. - What do the networking standards say? - IEEE Std 802.11-2016 - Timing Measurement (TM) - Fine Timing Measurement (FTM) - IEEE 1588 - Media-Dependent, Media-Independent MDMI - Special Ports - 802.1AS - Fine Timing Measurement Burst - Which of the above can be used for a practical solution? - What are the advantages/disadvantages of TM versus FTM? - What alternatives might we pursue? - unicast PTP without FTM - AP as transparent clock - Existing Linux interfaces for time synchronization - What can be used as is? - What new interaces or extensions are needed, and why? - Vendor support - How will we encourage broad acceptance/coverage? IMO, the simplest way that will unlock many use cases is to provide time stamps for single unicast frames, like in ieee80211_rx_status.device_timestamp and expose an adjustable PHC using timecounter/cyclecounter over the free running usec clock. Then you could synchronize client/AP over unicast IPv4 PTP (for example) with no user space changes needed, AND it would work on all radios, even those that don't implement FTM. Thanks, Richard --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pull-request: wireless-next-2023-03-30 2023-03-30 20:56 pull-request: wireless-next-2023-03-30 Johannes Berg 2023-03-31 7:06 ` Jakub Kicinski @ 2023-03-31 7:10 ` patchwork-bot+netdevbpf 1 sibling, 0 replies; 14+ messages in thread From: patchwork-bot+netdevbpf @ 2023-03-31 7:10 UTC (permalink / raw) To: Johannes Berg; +Cc: netdev, linux-wireless Hello: This pull request was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Thu, 30 Mar 2023 22:56:11 +0200 you wrote: > Hi, > > Here's new content for -next, this time with a bunch > of the promised iwlwifi work, but also lots of changes > in other drivers and some new stack features. > > I also mention it in the tag, but Kalle moved all the > plain C files out of drivers/net/wireless/ into dirs, > just FYI. > > [...] Here is the summary with links: - pull-request: wireless-next-2023-03-30 https://git.kernel.org/netdev/net-next/c/ce7928f7cf98 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-05-07 16:32 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-30 20:56 pull-request: wireless-next-2023-03-30 Johannes Berg 2023-03-31 7:06 ` Jakub Kicinski 2023-04-03 22:45 ` Richard Cochran 2023-04-13 3:33 ` Richard Cochran 2023-04-18 13:35 ` Greenman, Gregory 2023-04-20 3:43 ` Richard Cochran 2023-04-23 13:33 ` Stern, Avraham 2023-04-24 22:04 ` Richard Cochran 2023-04-25 1:29 ` Richard Cochran 2023-04-25 7:03 ` Stern, Avraham 2023-04-26 2:43 ` Richard Cochran 2023-04-26 14:04 ` Richard Cochran 2023-05-07 16:32 ` Stern, Avraham 2023-03-31 7:10 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).