<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/mac80211/chan.c, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2024-04-19T08:02:07Z</updated>
<entry>
<title>wifi: mac80211: fix idle calculation with multi-link</title>
<updated>2024-04-19T08:02:07Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-04-18T08:52:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=89884459a0b9e6ecd62a1ddfdb7708b34ee33649'/>
<id>urn:sha1:89884459a0b9e6ecd62a1ddfdb7708b34ee33649</id>
<content type='text'>
The vif's idle state doesn't automatically go to true when
any link removes the channel context, it's only idle when
_all_ links no longer have a channel context. Fix that.

Reviewed-by: Miriam Rachel Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240418105220.90df97557702.I05d2228ce85c203b9f2d6da8538cc16dce46752a@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: add ieee80211_vif_link_active() helper</title>
<updated>2024-03-04T13:32:53Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-02-28T08:48:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=68f6c6afbcebdc3acdc6084abfe453f4cba6b9dc'/>
<id>urn:sha1:68f6c6afbcebdc3acdc6084abfe453f4cba6b9dc</id>
<content type='text'>
We sometimes need to check if a link is active, and this
is complicated by the fact that active_links has no bits
set when the vif isn't (acting as) an MLD. Add a small
new helper ieee80211_vif_link_active() to make that a bit
easier, and use it in a few places.

Reviewed-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Reviewed-by: Miriam Rachel Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240228094901.688760aff5f7.I06892a503f5ecb9563fbd678d35d08daf7a044b0@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211/mac80211: move puncturing into chandef</title>
<updated>2024-02-08T14:00:39Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-01-29T18:34:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b82730bf57b54803ab94abbfd8c4422a7081886d'/>
<id>urn:sha1:b82730bf57b54803ab94abbfd8c4422a7081886d</id>
<content type='text'>
Aloka originally suggested that puncturing should be part of
the chandef, so that it's treated correctly. At the time, I
disagreed and it ended up not part of the chandef, but I've
now realized that this was wrong. Even for clients, the RX,
and perhaps more importantly, CCA configuration needs to take
puncturing into account.

Move puncturing into the chandef, and adjust all the code
accordingly. Also add a few tests for puncturing in chandef
compatibility checking.

Link: https://lore.kernel.org/linux-wireless/20220214223051.3610-1-quic_alokad@quicinc.com/
Suggested-by: Aloka Dixit &lt;quic_alokad@quicinc.com&gt;
Link: https://msgid.link/20240129194108.307183a5d2e5.I4d7fe2f126b2366c1312010e2900dfb2abffa0f6@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: support wider bandwidth OFDMA config</title>
<updated>2024-02-08T12:07:37Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-01-29T18:34:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=761748f001800d925c2ee8b04407e7aee12c3ffb'/>
<id>urn:sha1:761748f001800d925c2ee8b04407e7aee12c3ffb</id>
<content type='text'>
EHT requires that stations are able to participate in
wider bandwidth OFDMA, i.e. parse downlink OFDMA and
uplink OFDMA triggers when they're not capable of (or
not connected at) the (wider) bandwidth that the AP
is using. This requires hardware configuration, since
the entity responsible for parsing (possibly hardware)
needs to know the AP bandwidth.

To support this, change the channel request to have
the AP's bandwidth for clients, and track that in the
channel context in mac80211. This means that the same
chandef might need to be split up into two different
contexts, if the APs are different. Interfaces other
than client are not participating in OFDMA the same
way, so they don't request any AP setting.

Note that this doesn't introduce any API to split a
channel context, so that there are cases where this
might lead to a disconnect, e.g. if there are two
client interfaces using the same channel context, e.g.
both 160 MHz connected to different 320 MHz APs, and
one of the APs switches to 160 MHz.

Note also there are possible cases where this can be
optimised, e.g. when using the upper or lower 160 Mhz,
but I haven't been able to really fully understand the
spec and/or hardware limitations.

If, for some reason, there are no hardware limits on
this because the OFDMA (downlink/trigger) parsing is
done in firmware and can take the transmitter into
account, then drivers can set the new flag
IEEE80211_VIF_IGNORE_OFDMA_WIDER_BW on interfaces to
not have them request any AP bandwidth in the channel
context and ignore this issue entirely. The bss_conf
still contains the AP configuration (if any, i.e. EHT)
in the chanreq.

Link: https://msgid.link/20240129194108.d3d5b35dd783.I939d04674f4ff06f39934b1591c8d36a30ce74c2@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: add and use a link iteration macro</title>
<updated>2024-02-08T12:07:37Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-01-29T18:34:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d1256c1546a0e03f103e2f0381103dc747ea7f81'/>
<id>urn:sha1:d1256c1546a0e03f103e2f0381103dc747ea7f81</id>
<content type='text'>
In the channel context code we have quite a few instances
of nested loops iterating the interfaces and then links.
Add a new for_each_sdata_link() macro and use it. Also,
since it's easier, convert all the loops and a few other
places away from RCU as we now hold the wiphy mutex
everywhere anyway.

This does cause a little bit more work (such as checking
interface types for each link of an interface rather than
not iterating links in some cases), but that's not a huge
issue and seems like an acceptable trade-off, readability
is important too.

Link: https://msgid.link/20240129194108.7240829bd96d.I5ccbb8dd019cbcb5326c85d76121359225d6541a@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: introduce 'channel request'</title>
<updated>2024-02-08T12:07:34Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-01-29T18:34:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6092077ad09ce880c61735c314060f0bd79ae4aa'/>
<id>urn:sha1:6092077ad09ce880c61735c314060f0bd79ae4aa</id>
<content type='text'>
For channel contexts, mac80211 currently uses the cfg80211
chandef struct (control channel, center freq(s), width) to
define towards drivers and internally how these behave. In
fact, there are _two_ such structs used, where the min_def
can reduce bandwidth according to the stations connected.

Unfortunately,  with EHT this is longer be sufficient,  at
least not for all hardware.  EHT requires that non-AP STAs
that are connected to an AP with a lower bandwidth than it
(the AP) advertises (e.g. 160 MHz STA connected to 320 MHz
AP) still be able to receive downlink OFDMA and respond to
trigger frames for uplink OFDMA  that specify the position
and bandwidth  for the non-AP STA  relative to the channel
the AP is using.  Therefore, they need to be aware of this,
and at least for some hardware (e.g. Intel) this awareness
is in the hardware. As a result, use of the "same" channel
may need to be split over  two channel contexts where they
differ by the AP being used.

As a first step,  introduce a concept of a channel request
('chanreq') for each interface,  to control the context it
requests.   This step does nothing but reorganise the code,
so that later the AP's chandef can be added to the request
in order to handle the EHT case described above.

Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: chan: chandef is non-NULL for reserved</title>
<updated>2024-02-08T11:58:38Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-01-29T18:34:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9bf7079bc2271321fac467cae981c44e495b76b9'/>
<id>urn:sha1:9bf7079bc2271321fac467cae981c44e495b76b9</id>
<content type='text'>
The last caller of this with a NULL argument was related to
the non-chanctx code, so we can now remove this odd logic.

Reviewed-by: Miriam Rachel Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240129194108.bad8ec1e76c8.I12287452f42c54baf75821e75491cf6d021af20a@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: simplify non-chanctx drivers</title>
<updated>2024-02-08T11:58:32Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-01-29T18:34:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0a44dfc070749514b804ccac0b1fd38718f7daa1'/>
<id>urn:sha1:0a44dfc070749514b804ccac0b1fd38718f7daa1</id>
<content type='text'>
There are still surprisingly many non-chanctx drivers, but in
mac80211 that code is a bit awkward. Simplify this by having
those drivers assign 'emulated' ops, so that the mac80211 code
can be more unified between non-chanctx/chanctx drivers. This
cuts the number of places caring about it by about 15, which
are scattered across - now they're fewer and no longer in the
channel context handling.

Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: clean up connection process</title>
<updated>2024-02-08T11:58:26Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2024-01-29T18:34:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=310c8387c63830bc375827242e0f9fa689f82e21'/>
<id>urn:sha1:310c8387c63830bc375827242e0f9fa689f82e21</id>
<content type='text'>
Rewrite the station-side connection handling. The connection
flags (IEEE80211_DISABLE_*) are rather confusing, and they're
not always maintained well. Additionally, for wider-bandwidth
OFDMA support we need to know the precise bandwidth of the AP,
which is currently somewhat difficult.

Rewrite this to have a 'mode' (S1G/legacy/HT/...) and a limit
on the bandwidth. This is not entirely clean because some of
those modes aren't completely sequenced (as this assumes in
some places), e.g. VHT doesn't exist on 2.4 GHz, but HE does.
However, it still simplifies things and gives us a good idea
what we're operating as, so we can parse elements accordingly
etc.

This leaves a FIXME for puncturing, this is addressed in a
later patch.

Reviewed-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Reviewed-by: Miriam Rachel Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20240129194108.9451722c0110.I3e61f4cfe9da89008e1854160093c76a1e69dc2a@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: Replace ENOTSUPP with EOPNOTSUPP</title>
<updated>2023-12-12T09:37:01Z</updated>
<author>
<name>Andrei Otcheretianski</name>
</author>
<published>2023-12-11T07:05:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0528e0fdba9e6b1e9502344f5217b699075667a7'/>
<id>urn:sha1:0528e0fdba9e6b1e9502344f5217b699075667a7</id>
<content type='text'>
ENOTSUP isn't a standard error code. EOPNOTSUPP should be used instead.

Signed-off-by: Andrei Otcheretianski &lt;andrei.otcheretianski@intel.com&gt;
Reviewed-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://msgid.link/20231211085121.3841b71c867d.Idf2ad01d9dfe8d6d6c352bf02deb06e49701ad1d@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
