[RFC,0/7] add a KHz component to wireless channels

Message

Thomas Pedersen April 1, 2020, 6:21 a.m. UTC

Hello,

This patchset prepares for adding 802.11ah (S1G) support.

S1G channels, at least in the US, may be centered on a sub-MHz
frequency. The current channel structures and nl80211 APIs expect
frequencies in units of MHz. To extend the existing functionality and
APIs while reducing churn and breakage, we add a KHz offset where
needed. This also has the advantage that the KHz offset can be ignored
at will (legacy drivers).

Some cfg80211 and nl80211 internals have been converted to handle units
of KHz, which is not unprecedented (net/wireless/reg.c), and the
collateral damage is localized.

One thing which is still unclear is backward compatibility in nl80211.
If a frequency offset is supplied to an older kernel, it'll just
silently fail to do the right thing. Likewise, these patches will accept
a frequency offset to eg.  NL80211_CMD_JOIN_MESH, but not handle it in
mac80211. For this case is it sufficient to return an error?

The hostap hwsim tests are still passing on par with HEAD. Before these
become PATCH we'd like to add some tests exercising the new nl80211
attributes, but it seems difficult without pulling in the full S1G
patchset. Maybe we'll hack up hwsim + regulatory to use the S1G band for
regular wifi tests. Suggestions here are welcome.

Thanks for looking.

Thomas Pedersen (7):
  ieee80211: share 802.11 unit conversion helpers
  cfg80211: express channels with a KHz component
  mac80211: handle channel frequency offset
  mac80211: add freq_offset to RX status
  cfg80211: report frequency in KHz for management RX
  nl80211: add KHz frequency offset for most wifi commands
  nl80211: accept scan frequencies in KHz

 drivers/net/wireless/ath/ath6kl/wmi.c         |  5 +-
 drivers/net/wireless/ath/wil6210/wmi.c        |  3 +-
 .../broadcom/brcm80211/brcmfmac/p2p.c         |  6 +-
 drivers/net/wireless/marvell/mwifiex/util.c   |  3 +-
 drivers/staging/wilc1000/cfg80211.c           |  2 +-
 include/linux/ieee80211.h                     | 11 +++
 include/net/cfg80211.h                        | 70 ++++++++++++-
 include/net/mac80211.h                        | 10 +-
 include/net/regulatory.h                      |  7 --
 include/uapi/linux/nl80211.h                  | 51 +++++++---
 net/mac80211/chan.c                           |  1 +
 net/mac80211/main.c                           |  8 +-
 net/mac80211/mlme.c                           | 22 +++--
 net/mac80211/rx.c                             |  7 +-
 net/mac80211/scan.c                           |  4 +-
 net/mac80211/trace.h                          | 41 ++++++--
 net/wireless/chan.c                           | 68 +++++++------
 net/wireless/nl80211.c                        | 97 ++++++++++++++-----
 net/wireless/reg.c                            | 40 ++++----
 net/wireless/scan.c                           |  4 +-
 net/wireless/trace.h                          | 21 +++-
 net/wireless/util.c                           | 72 ++++++++++++--
 22 files changed, 406 insertions(+), 147 deletions(-)

Comments

Johannes Berg April 1, 2020, 7:15 a.m. UTC | #1

On Tue, 2020-03-31 at 23:21 -0700, Thomas Pedersen wrote:

> Some cfg80211 and nl80211 internals have been converted to handle units
> of KHz, which is not unprecedented (net/wireless/reg.c), and the
> collateral damage is localized.

:)

> One thing which is still unclear is backward compatibility in nl80211.
> If a frequency offset is supplied to an older kernel, it'll just
> silently fail to do the right thing.

But will it? It mostly requires to have a struct ieee80211_channel
registered with the wiphy for a given frequency, and won't find that?

But speaking of which - I was expecting to see a new *band* here for
S1G, so that you can actually register the channels properly in the
wiphy struct? Or is that just not part of this patchset yet?

johannes

Thomas Pedersen April 1, 2020, 6:26 p.m. UTC | #2

On 4/1/20 12:15 AM, Johannes Berg wrote:
> On Tue, 2020-03-31 at 23:21 -0700, Thomas Pedersen wrote:
> 
>> Some cfg80211 and nl80211 internals have been converted to handle units
>> of KHz, which is not unprecedented (net/wireless/reg.c), and the
>> collateral damage is localized.
> 
> :)
> 
>> One thing which is still unclear is backward compatibility in nl80211.
>> If a frequency offset is supplied to an older kernel, it'll just
>> silently fail to do the right thing.
> 
> But will it? It mostly requires to have a struct ieee80211_channel
> registered with the wiphy for a given frequency, and won't find that?

I was worried the wrong ("rounded down") channel would be found, but I
think the point is mostly moot since that channel wouldn't exist either.

> But speaking of which - I was expecting to see a new *band* here for
> S1G, so that you can actually register the channels properly in the
> wiphy struct? Or is that just not part of this patchset yet?

Yeah just trying to focus on the frequency offset stuff and keep S1G out
of it for now. Do you think it would be helpful to cap it with the new
S1G band definition?