| Message ID | 20230330205612.921134-1-johannes@sipsolutions.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | ce7928f7cf988e3f20ec3cca050838b266e9ef14 |
| Headers | show |
| Series | pull-request: wireless-next-2023-03-30 | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Pull request for net-next |
| netdev/build_32bit | success | Errors and warnings before: 210 this patch: 207 |
| netdev/build_clang | success | Errors and warnings before: 86 this patch: 81 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/verify_fixes | success | Fixes tag looks correct |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 212 this patch: 209 |
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'.
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!
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
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
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.
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
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
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
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
> 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.
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
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
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.
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%)