2019-06-04 10:11:33 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-08-28 17:01:53 -04:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2010-02-15 12:53:10 +02:00
|
|
|
|
2014-09-03 15:24:57 +03:00
|
|
|
|
2017-04-26 10:58:47 +03:00
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-23 20:12:59 -05:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:52 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
2024-10-01 15:35:57 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-03 13:52:18 -07:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2009-07-29 20:08:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2009-07-29 20:08:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-26 11:15:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2022-01-26 11:15:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-30 11:46:54 -05:00
|
|
|
|
|
|
|
|
|
2008-04-30 18:51:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-13 12:25:28 +01:00
|
|
|
|
2008-04-30 18:51:21 +02:00
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2013-02-13 12:25:28 +01:00
|
|
|
|
2008-04-30 18:51:21 +02:00
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
2010-11-16 11:49:58 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-10 16:49:38 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-10-20 21:20:27 -04:00
|
|
|
|
2008-07-10 11:22:31 +02:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-02-10 16:49:38 +01:00
|
|
|
|
2013-04-07 09:53:30 +03:00
|
|
|
|
2010-01-14 13:09:14 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-07-10 11:22:31 +02:00
|
|
|
|
2008-02-10 16:49:38 +01:00
|
|
|
|
|
|
|
|
|
2008-07-10 11:22:31 +02:00
|
|
|
|
2013-04-07 09:53:30 +03:00
|
|
|
|
2010-01-12 10:42:31 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
|
|
|
|
|
2012-11-09 11:39:59 +01:00
|
|
|
|
2012-09-11 14:34:12 +02:00
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
2024-10-07 15:00:47 +03:00
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
|
|
|
|
|
2024-01-29 19:34:49 +01:00
|
|
|
|
|
|
|
|
|
2026-04-28 11:25:37 +02:00
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
|
|
|
|
|
2012-11-09 11:39:59 +01:00
|
|
|
|
2012-09-11 14:34:12 +02:00
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2024-10-07 15:00:47 +03:00
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
2024-01-29 19:34:49 +01:00
|
|
|
|
2026-04-28 11:25:37 +02:00
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: introduce 'channel request'
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 <johannes.berg@intel.com>
2024-01-29 19:34:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
|
|
|
|
|
2026-04-28 11:25:37 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: introduce 'channel request'
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 <johannes.berg@intel.com>
2024-01-29 19:34:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
2026-04-28 11:25:37 +02:00
|
|
|
|
wifi: mac80211: introduce 'channel request'
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 <johannes.berg@intel.com>
2024-01-29 19:34:40 +01:00
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 11:39:59 +01:00
|
|
|
|
2013-11-11 20:14:01 +02:00
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
|
|
|
|
|
2024-07-09 10:38:34 +02:00
|
|
|
|
2012-09-11 14:34:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-30 19:17:28 +01:00
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 11:39:59 +01:00
|
|
|
|
2013-11-11 20:14:01 +02:00
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
2024-07-09 10:38:34 +02:00
|
|
|
|
2012-09-11 14:34:12 +02:00
|
|
|
|
|
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
|
|
|
|
|
2020-05-07 13:59:07 -05:00
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
|
|
|
|
|
2014-05-23 14:33:12 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-03 18:04:15 +03:00
|
|
|
|
2014-05-23 14:33:12 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-03 18:04:15 +03:00
|
|
|
|
2014-05-23 14:33:12 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-24 10:55:56 +02:00
|
|
|
|
|
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-07 20:07:01 +03:00
|
|
|
|
2008-03-28 16:33:32 -07:00
|
|
|
|
2008-09-11 00:01:57 +02:00
|
|
|
|
2009-04-23 16:10:04 +02:00
|
|
|
|
2009-04-23 16:13:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
2010-04-28 17:40:43 +02:00
|
|
|
|
2010-06-09 13:43:26 +03:00
|
|
|
|
2010-07-19 16:39:04 +02:00
|
|
|
|
|
|
|
|
|
2010-08-05 17:02:38 +02:00
|
|
|
|
2013-04-10 13:19:13 +02:00
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
2012-07-27 12:33:22 +03:00
|
|
|
|
2012-10-24 10:59:25 +02:00
|
|
|
|
2012-10-29 20:08:01 +01:00
|
|
|
|
2016-03-17 15:41:39 +02:00
|
|
|
|
2013-05-16 17:34:17 +03:00
|
|
|
|
|
|
|
|
|
2013-02-07 21:37:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-03 10:33:19 +01:00
|
|
|
|
2015-12-08 16:04:31 +02:00
|
|
|
|
2017-04-26 10:58:47 +03:00
|
|
|
|
|
|
|
|
|
2018-03-22 12:18:03 -07:00
|
|
|
|
2019-10-25 10:36:47 +13:00
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
2019-05-28 13:49:47 +02:00
|
|
|
|
2019-07-30 18:37:01 +02:00
|
|
|
|
2019-12-17 15:19:19 +01:00
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
2020-09-11 00:33:01 +00:00
|
|
|
|
|
|
|
|
|
2023-09-20 21:25:22 +03:00
|
|
|
|
2024-03-18 18:53:21 +02:00
|
|
|
|
2024-05-06 21:37:57 +02:00
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
2026-04-28 11:25:38 +02:00
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-07 20:07:01 +03:00
|
|
|
|
2011-09-18 00:16:45 +02:00
|
|
|
|
2008-09-11 00:01:57 +02:00
|
|
|
|
2009-04-23 16:10:04 +02:00
|
|
|
|
2009-04-23 16:13:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
2010-04-28 17:40:43 +02:00
|
|
|
|
2010-06-09 13:43:26 +03:00
|
|
|
|
2010-07-19 16:39:04 +02:00
|
|
|
|
2010-08-05 17:02:38 +02:00
|
|
|
|
2011-09-04 11:11:32 +03:00
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
2012-07-27 12:33:22 +03:00
|
|
|
|
2012-10-24 10:59:25 +02:00
|
|
|
|
2012-10-29 20:08:01 +01:00
|
|
|
|
2013-05-16 17:34:17 +03:00
|
|
|
|
2013-02-07 21:37:29 +01:00
|
|
|
|
2014-11-03 10:33:19 +01:00
|
|
|
|
2015-12-08 16:04:31 +02:00
|
|
|
|
2017-04-26 10:58:47 +03:00
|
|
|
|
2018-03-22 12:18:03 -07:00
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
2019-05-28 13:49:47 +02:00
|
|
|
|
2019-07-30 18:37:01 +02:00
|
|
|
|
2019-12-17 15:19:19 +01:00
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
2024-06-27 10:42:56 +02:00
|
|
|
|
2023-09-20 21:25:22 +03:00
|
|
|
|
2024-01-02 21:35:34 +02:00
|
|
|
|
2024-05-06 21:37:57 +02:00
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
2026-04-28 11:25:38 +02:00
|
|
|
|
2010-05-05 09:44:02 +02:00
|
|
|
|
|
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
2010-06-09 13:43:26 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-08 08:46:22 -07:00
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:35 +02:00
|
|
|
|
2015-04-20 22:53:37 +03:00
|
|
|
|
2015-04-20 22:53:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-08 08:46:22 -07:00
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:35 +02:00
|
|
|
|
2015-04-20 22:53:37 +03:00
|
|
|
|
2015-04-20 22:53:38 +03:00
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-08 08:46:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
2015-04-13 18:27:35 +02:00
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:36 +02:00
|
|
|
|
2015-03-16 23:23:37 +02:00
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:36 +02:00
|
|
|
|
2015-03-16 23:23:37 +02:00
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-13 18:27:35 +02:00
|
|
|
|
2015-03-16 23:23:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 22:53:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 22:53:38 +03:00
|
|
|
|
2015-04-20 22:53:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
2015-04-13 18:27:35 +02:00
|
|
|
|
2023-12-20 15:57:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 22:53:37 +03:00
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:35 +02:00
|
|
|
|
2015-04-20 22:53:37 +03:00
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-08 16:04:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
2018-12-06 12:58:30 -08:00
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-06 21:37:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-28 11:25:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:25 +02:00
|
|
|
|
2024-02-06 16:54:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
2022-06-24 14:42:12 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-15 11:03:04 +02:00
|
|
|
|
|
|
|
|
|
2019-05-28 13:49:48 +02:00
|
|
|
|
|
|
|
|
|
2020-03-26 15:09:33 +02:00
|
|
|
|
2021-06-18 13:41:35 +03:00
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
2015-06-02 20:15:49 +02:00
|
|
|
|
|
|
|
|
|
2010-01-26 14:19:52 +01:00
|
|
|
|
2012-12-12 10:12:24 +02:00
|
|
|
|
2013-05-16 17:34:17 +03:00
|
|
|
|
2012-05-22 22:13:05 +02:00
|
|
|
|
2013-02-05 17:48:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:00 +02:00
|
|
|
|
2012-05-22 22:13:05 +02:00
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:00 +02:00
|
|
|
|
2013-02-05 17:48:40 +01:00
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
|
|
|
|
|
2008-03-28 16:33:34 -07:00
|
|
|
|
2008-07-18 13:52:59 +08:00
|
|
|
|
2008-09-11 00:01:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-19 14:23:57 +03:00
|
|
|
|
2010-11-22 20:58:24 +01:00
|
|
|
|
2009-04-23 16:13:26 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: introduce 'channel request'
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 <johannes.berg@intel.com>
2024-01-29 19:34:40 +01:00
|
|
|
|
2012-11-09 11:39:59 +01:00
|
|
|
|
2015-12-08 16:04:31 +02:00
|
|
|
|
2012-03-15 19:45:16 +01:00
|
|
|
|
2015-08-18 16:52:07 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
2015-10-22 17:35:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-10 04:50:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
2010-07-19 16:39:04 +02:00
|
|
|
|
2011-09-04 11:11:32 +03:00
|
|
|
|
2019-12-17 10:30:57 -08:00
|
|
|
|
2015-01-14 12:55:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 15:47:56 +01:00
|
|
|
|
2016-03-17 15:41:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-26 10:58:47 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-16 18:22:56 +02:00
|
|
|
|
2025-04-08 11:45:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-16 18:22:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-20 11:31:08 -07:00
|
|
|
|
|
|
|
|
|
2019-07-30 18:37:01 +02:00
|
|
|
|
2019-12-17 15:19:19 +01:00
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
2020-09-11 00:33:01 +00:00
|
|
|
|
|
|
|
|
|
2020-10-03 15:04:18 -07:00
|
|
|
|
|
|
|
|
|
2021-09-24 06:00:47 -04:00
|
|
|
|
2024-05-06 21:37:56 +02:00
|
|
|
|
2021-09-24 06:00:52 -04:00
|
|
|
|
2022-02-14 17:30:02 +01:00
|
|
|
|
2025-02-05 11:39:13 +02:00
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
2023-08-29 12:18:56 +02:00
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 13:26:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-29 12:18:56 +02:00
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 13:26:44 +02:00
|
|
|
|
2023-02-18 01:49:25 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-05 14:54:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-05 14:54:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-18 01:48:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-15 11:13:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-05 20:58:36 +05:30
|
|
|
|
2024-10-07 15:00:48 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-07-14 13:43:17 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-17 17:42:03 +10:00
|
|
|
|
|
|
|
|
|
2026-04-28 11:25:38 +02:00
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:25 +02:00
|
|
|
|
2024-02-06 16:54:06 +02:00
|
|
|
|
2023-03-01 12:09:25 +02:00
|
|
|
|
2009-04-23 16:13:26 +02:00
|
|
|
|
2022-06-24 14:42:12 +02:00
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-15 11:03:04 +02:00
|
|
|
|
2019-05-28 13:49:48 +02:00
|
|
|
|
2020-03-26 15:09:33 +02:00
|
|
|
|
2021-06-18 13:41:35 +03:00
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-07 20:07:01 +03:00
|
|
|
|
2009-04-23 16:13:26 +02:00
|
|
|
|
2008-07-18 13:52:59 +08:00
|
|
|
|
2008-03-28 16:33:34 -07:00
|
|
|
|
|
|
|
|
|
2012-05-22 22:13:05 +02:00
|
|
|
|
|
|
|
|
|
2013-02-05 17:48:40 +01:00
|
|
|
|
2009-01-21 15:13:48 +01:00
|
|
|
|
2013-05-19 14:23:57 +03:00
|
|
|
|
2016-04-12 15:56:15 +02:00
|
|
|
|
2009-05-08 20:47:39 +02:00
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
|
|
|
|
|
2017-02-10 04:50:22 +01:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: introduce 'channel request'
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 <johannes.berg@intel.com>
2024-01-29 19:34:40 +01:00
|
|
|
|
2015-12-08 16:04:31 +02:00
|
|
|
|
2010-07-19 16:39:04 +02:00
|
|
|
|
2011-09-04 11:11:32 +03:00
|
|
|
|
2012-10-24 10:59:25 +02:00
|
|
|
|
2015-01-14 12:55:08 +01:00
|
|
|
|
2013-03-21 15:47:56 +01:00
|
|
|
|
2016-03-17 15:41:39 +02:00
|
|
|
|
2017-04-26 10:58:47 +03:00
|
|
|
|
|
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
|
|
|
|
|
2019-01-16 18:22:56 +02:00
|
|
|
|
|
|
|
|
|
2025-04-08 11:45:00 -07:00
|
|
|
|
2019-01-16 18:22:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-24 15:41:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-30 18:37:01 +02:00
|
|
|
|
2019-12-17 15:19:19 +01:00
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
2020-09-11 00:33:01 +00:00
|
|
|
|
2020-10-03 15:04:18 -07:00
|
|
|
|
2021-09-24 06:00:47 -04:00
|
|
|
|
2024-05-06 21:37:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-24 06:00:52 -04:00
|
|
|
|
2022-02-14 17:30:02 +01:00
|
|
|
|
2025-02-05 11:39:13 +02:00
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 13:26:44 +02:00
|
|
|
|
2023-01-30 16:12:27 -08:00
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 13:26:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-05 14:54:45 -07:00
|
|
|
|
2023-02-18 01:49:25 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-05 14:54:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-05 14:54:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-18 01:48:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-15 11:13:18 -07:00
|
|
|
|
2025-05-05 20:58:36 +05:30
|
|
|
|
|
|
|
|
|
2024-10-07 15:00:48 +03:00
|
|
|
|
|
|
|
|
|
2026-07-14 13:43:17 +03:00
|
|
|
|
|
|
|
|
|
2025-07-17 17:42:03 +10:00
|
|
|
|
|
|
|
|
|
2026-04-28 11:25:38 +02:00
|
|
|
|
|
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-04 18:09:26 -08:00
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
2008-03-04 18:09:26 -08:00
|
|
|
|
2008-07-03 13:52:18 -07:00
|
|
|
|
2008-03-04 18:09:26 -08:00
|
|
|
|
2009-11-19 01:08:30 +01:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2009-08-07 16:28:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-01 14:16:03 +03:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-11 11:21:07 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 21:58:37 +02:00
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
|
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-07 16:42:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-17 01:47:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-29 15:02:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-15 12:53:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-15 17:39:37 -04:00
|
|
|
|
2010-04-19 19:57:35 +02:00
|
|
|
|
|
|
|
|
|
2011-01-06 22:36:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-03 18:35:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-25 14:53:31 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:35 +02:00
|
|
|
|
|
|
|
|
|
2011-09-29 20:34:04 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-10 21:26:11 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-21 21:36:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-04 18:09:26 -08:00
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-11 11:21:07 -06:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2009-06-07 21:58:37 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
2009-08-07 16:42:15 +02:00
|
|
|
|
2010-01-17 01:47:59 +01:00
|
|
|
|
2013-01-29 15:02:27 +01:00
|
|
|
|
2010-02-15 12:53:10 +02:00
|
|
|
|
2010-04-15 17:39:37 -04:00
|
|
|
|
2010-04-19 19:57:35 +02:00
|
|
|
|
2010-12-18 17:20:47 +01:00
|
|
|
|
2011-02-03 18:35:19 +02:00
|
|
|
|
2011-09-25 14:53:31 +05:30
|
|
|
|
2011-09-29 16:04:33 +02:00
|
|
|
|
2011-09-29 20:34:04 +05:30
|
|
|
|
2011-10-07 14:01:25 +02:00
|
|
|
|
2014-12-10 21:26:11 +05:30
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2010-06-07 11:12:27 +02:00
|
|
|
|
|
|
|
|
|
2020-09-21 19:28:12 -07:00
|
|
|
|
|
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-10 21:26:10 +05:30
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2019-04-11 13:47:26 -07:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:49 +04:00
|
|
|
|
|
|
|
|
|
2020-11-04 10:18:19 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
2024-07-29 15:48:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-18 21:36:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-10 21:26:10 +05:30
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2019-04-11 13:47:26 -07:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2020-07-23 14:01:49 +04:00
|
|
|
|
2020-11-04 10:18:19 +04:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
2024-07-29 15:48:16 +08:00
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
|
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2022-02-02 10:49:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-21 21:36:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
2010-09-21 21:36:18 +02:00
|
|
|
|
2011-09-29 16:04:33 +02:00
|
|
|
|
2010-09-21 21:36:18 +02:00
|
|
|
|
2009-01-22 09:00:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
2009-01-22 09:00:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-22 09:00:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-04 18:09:26 -08:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-02 19:46:16 +02:00
|
|
|
|
2008-10-05 18:04:24 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-05 18:04:24 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2008-10-05 18:04:24 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2008-10-23 08:51:20 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-07 16:23:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
|
|
|
|
|
2009-08-07 16:23:43 +02:00
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2009-08-07 16:23:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
|
|
|
|
|
2009-08-07 16:23:43 +02:00
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2009-08-07 16:23:43 +02:00
|
|
|
|
|
|
|
|
|
2008-10-05 18:04:24 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
2010-07-21 10:59:58 +00:00
|
|
|
|
2008-10-05 18:04:24 +02:00
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
2023-02-13 15:40:24 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 17:09:29 +02:00
|
|
|
|
|
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 17:09:29 +02:00
|
|
|
|
2012-11-09 18:38:32 +01:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
2008-04-17 19:41:02 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2023-08-28 15:09:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-07-24 11:54:28 +00:00
|
|
|
|
2019-10-23 11:59:00 +02:00
|
|
|
|
2019-02-01 11:53:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:55 +02:00
|
|
|
|
|
|
|
|
|
2022-02-02 10:49:47 +02:00
|
|
|
|
2026-07-09 17:12:27 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-01 11:53:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-03 13:52:18 -07:00
|
|
|
|
2008-04-17 19:41:02 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-15 12:25:50 +01:00
|
|
|
|
2023-08-28 15:09:24 +02:00
|
|
|
|
|
|
|
|
|
2020-01-15 12:25:50 +01:00
|
|
|
|
2026-07-24 11:54:28 +00:00
|
|
|
|
2020-01-15 12:25:50 +01:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-16 13:38:43 +02:00
|
|
|
|
|
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
2023-09-20 21:25:26 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-12 22:52:47 +02:00
|
|
|
|
2017-06-22 12:20:30 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
2017-06-22 12:20:30 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2015-06-01 23:14:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2014-03-13 14:30:47 +02:00
|
|
|
|
2012-07-02 19:46:16 +02:00
|
|
|
|
2009-11-15 23:07:30 +01:00
|
|
|
|
2012-03-28 11:04:23 +02:00
|
|
|
|
mac80211: make ieee80211_tx_info padding explicit
While looking at a bug, I got rather confused by the layout of the
'status' field in ieee80211_tx_info. Apparently, the intention is that
status_driver_data[] is used for driver specific data, and fills up the
size of the union to 40 bytes, just like the other ones.
This is indeed what actually happens, but only because of the
combination of two mistakes:
- "void *status_driver_data[18 / sizeof(void *)];" is intended
to be 18 bytes long but is actually two bytes shorter because of
rounding-down in the division, to a multiple of the pointer
size (4 bytes or 8 bytes).
- The other fields combined are intended to be 22 bytes long, but
are actually 24 bytes because of padding in front of the
unaligned tx_time member, and in front of the pointer array.
The two mistakes cancel out. so the size ends up fine, but it seems
more helpful to make this explicit, by having a multiple of 8 bytes
in the size calculation and explicitly describing the padding.
Fixes: ea5907db2a9cc ("mac80211: fix struct ieee80211_tx_info size")
Fixes: 02219b3abca59 ("mac80211: add WMM admission control support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230623152443.2296825-2-arnd@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-06-23 17:24:00 +02:00
|
|
|
|
2014-10-07 10:38:50 +03:00
|
|
|
|
2022-02-02 10:49:47 +02:00
|
|
|
|
2026-07-09 17:12:27 +05:30
|
|
|
|
mac80211: make ieee80211_tx_info padding explicit
While looking at a bug, I got rather confused by the layout of the
'status' field in ieee80211_tx_info. Apparently, the intention is that
status_driver_data[] is used for driver specific data, and fills up the
size of the union to 40 bytes, just like the other ones.
This is indeed what actually happens, but only because of the
combination of two mistakes:
- "void *status_driver_data[18 / sizeof(void *)];" is intended
to be 18 bytes long but is actually two bytes shorter because of
rounding-down in the division, to a multiple of the pointer
size (4 bytes or 8 bytes).
- The other fields combined are intended to be 22 bytes long, but
are actually 24 bytes because of padding in front of the
unaligned tx_time member, and in front of the pointer array.
The two mistakes cancel out. so the size ends up fine, but it seems
more helpful to make this explicit, by having a multiple of 8 bytes
in the size calculation and explicitly describing the padding.
Fixes: ea5907db2a9cc ("mac80211: fix struct ieee80211_tx_info size")
Fixes: 02219b3abca59 ("mac80211: add WMM admission control support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230623152443.2296825-2-arnd@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-06-23 17:24:00 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2019-11-18 22:06:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-09 19:39:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-26 17:11:35 +02:00
|
|
|
|
2019-10-25 10:36:47 +13:00
|
|
|
|
2017-04-26 17:11:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-09 19:39:57 +02:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:37:00 +02:00
|
|
|
|
2022-01-26 11:15:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-26 17:11:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-09 19:39:57 +02:00
|
|
|
|
2022-01-26 11:15:31 +02:00
|
|
|
|
2022-05-09 19:39:57 +02:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:37:00 +02:00
|
|
|
|
2017-04-26 17:11:35 +02:00
|
|
|
|
|
|
|
|
|
2014-02-05 15:21:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 16:15:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-05 15:21:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-12 15:56:15 +02:00
|
|
|
|
|
|
|
|
|
2014-02-05 15:21:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2009-06-17 13:13:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-04 23:01:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-18 12:38:39 -08:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-21 16:58:40 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
2015-06-12 14:39:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-18 16:09:29 +00:00
|
|
|
|
|
|
|
|
|
2007-09-17 01:29:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-20 13:41:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-13 10:46:27 -08:00
|
|
|
|
2011-02-23 15:06:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-13 10:46:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-25 15:46:34 +02:00
|
|
|
|
|
|
|
|
|
2023-12-20 13:41:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-01 18:00:07 +01:00
|
|
|
|
|
|
|
|
|
2012-07-05 11:34:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-24 11:49:45 +02:00
|
|
|
|
|
|
|
|
|
2015-12-11 14:39:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-23 15:34:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-03 15:59:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-21 16:58:40 +02:00
|
|
|
|
|
|
|
|
|
2018-02-19 14:48:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
2019-02-01 11:53:32 +01:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-01 11:53:32 +01:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:20 +03:00
|
|
|
|
2018-09-05 08:06:06 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
|
|
|
|
|
2025-10-27 14:22:14 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
2012-07-05 11:34:31 +02:00
|
|
|
|
|
|
|
|
|
2023-12-20 13:41:39 +02:00
|
|
|
|
2012-07-05 11:34:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-20 13:41:40 +02:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-09 10:25:46 +02:00
|
|
|
|
2023-12-20 13:41:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:35 +02:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-19 14:48:39 +02:00
|
|
|
|
|
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:20 +03:00
|
|
|
|
2018-09-05 08:06:06 +03:00
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
2025-10-27 14:22:14 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
2014-02-05 16:37:11 +02:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
2014-02-05 16:37:11 +02:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-01 11:53:32 +01:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-05 16:37:11 +02:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
|
|
|
|
|
2017-04-26 12:14:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-05 16:37:11 +02:00
|
|
|
|
|
|
|
|
|
2017-04-26 12:14:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
2023-01-09 13:07:21 +02:00
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
2026-06-02 16:22:24 +10:00
|
|
|
|
2017-04-26 12:14:59 +02:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-17 13:13:00 +02:00
|
|
|
|
2008-05-08 19:15:40 +02:00
|
|
|
|
2008-02-18 11:20:51 +09:00
|
|
|
|
|
|
|
|
|
2016-02-23 23:05:06 +02:00
|
|
|
|
|
|
|
|
|
2022-01-26 11:15:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-22 22:13:05 +02:00
|
|
|
|
|
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2015-12-08 16:04:35 +02:00
|
|
|
|
|
|
|
|
|
2020-04-01 18:18:05 -07:00
|
|
|
|
2008-05-08 19:15:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-22 16:29:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2008-12-12 14:38:33 +02:00
|
|
|
|
2012-11-09 15:07:02 +01:00
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2017-04-26 12:14:59 +02:00
|
|
|
|
|
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 08:52:01 +01:00
|
|
|
|
2023-01-09 13:07:21 +02:00
|
|
|
|
|
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-24 12:38:25 +02:00
|
|
|
|
2012-07-05 11:34:31 +02:00
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:06 +03:00
|
|
|
|
2022-08-17 16:12:12 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2022-01-26 11:15:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-22 22:13:05 +02:00
|
|
|
|
2012-07-05 11:34:31 +02:00
|
|
|
|
2017-04-26 11:13:00 +02:00
|
|
|
|
2020-04-01 18:18:05 -07:00
|
|
|
|
2017-04-26 12:14:59 +02:00
|
|
|
|
2023-01-09 13:07:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: add __packed to union members of struct ieee80211_rx_status
The arm-linux-gnueabi-gcc compiler, align the field followed by union
members, causing size of struct ieee80211_rx_status over skb->cb
(48 bytes). By investigation, the union member starts at offset 32,
and the offset of next field rate_idx is 36 instead of expected 33, and
the total size is (unexpected) 52.
When compiling rtw88 driver, it throws:
In file included from /work/linux-src/linux-stable/include/linux/string.h:386,
from /work/linux-src/linux-stable/include/linux/bitmap.h:13,
from /work/linux-src/linux-stable/include/linux/cpumask.h:11,
from /work/linux-src/linux-stable/include/linux/smp.h:13,
from /work/linux-src/linux-stable/include/linux/lockdep.h:14,
from /work/linux-src/linux-stable/include/linux/mutex.h:17,
from /work/linux-src/linux-stable/include/linux/kernfs.h:11,
from /work/linux-src/linux-stable/include/linux/sysfs.h:16,
from /work/linux-src/linux-stable/include/linux/kobject.h:20,
from /work/linux-src/linux-stable/include/linux/dmi.h:6,
from pci.c:5:
In function 'fortify_memcpy_chk',
inlined from 'rtw_pci_rx_napi.constprop' at pci.c:1095:4:
/work/linux-src/linux-stable/include/linux/fortify-string.h:569:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
569 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After this patch, the size of struct ieee80211_rx_status is 48.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260411072509.1556635-1-pkshih@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-11 15:25:09 +08:00
|
|
|
|
2023-01-09 13:07:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: add __packed to union members of struct ieee80211_rx_status
The arm-linux-gnueabi-gcc compiler, align the field followed by union
members, causing size of struct ieee80211_rx_status over skb->cb
(48 bytes). By investigation, the union member starts at offset 32,
and the offset of next field rate_idx is 36 instead of expected 33, and
the total size is (unexpected) 52.
When compiling rtw88 driver, it throws:
In file included from /work/linux-src/linux-stable/include/linux/string.h:386,
from /work/linux-src/linux-stable/include/linux/bitmap.h:13,
from /work/linux-src/linux-stable/include/linux/cpumask.h:11,
from /work/linux-src/linux-stable/include/linux/smp.h:13,
from /work/linux-src/linux-stable/include/linux/lockdep.h:14,
from /work/linux-src/linux-stable/include/linux/mutex.h:17,
from /work/linux-src/linux-stable/include/linux/kernfs.h:11,
from /work/linux-src/linux-stable/include/linux/sysfs.h:16,
from /work/linux-src/linux-stable/include/linux/kobject.h:20,
from /work/linux-src/linux-stable/include/linux/dmi.h:6,
from pci.c:5:
In function 'fortify_memcpy_chk',
inlined from 'rtw_pci_rx_napi.constprop' at pci.c:1095:4:
/work/linux-src/linux-stable/include/linux/fortify-string.h:569:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
569 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After this patch, the size of struct ieee80211_rx_status is 48.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260411072509.1556635-1-pkshih@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-11 15:25:09 +08:00
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: add __packed to union members of struct ieee80211_rx_status
The arm-linux-gnueabi-gcc compiler, align the field followed by union
members, causing size of struct ieee80211_rx_status over skb->cb
(48 bytes). By investigation, the union member starts at offset 32,
and the offset of next field rate_idx is 36 instead of expected 33, and
the total size is (unexpected) 52.
When compiling rtw88 driver, it throws:
In file included from /work/linux-src/linux-stable/include/linux/string.h:386,
from /work/linux-src/linux-stable/include/linux/bitmap.h:13,
from /work/linux-src/linux-stable/include/linux/cpumask.h:11,
from /work/linux-src/linux-stable/include/linux/smp.h:13,
from /work/linux-src/linux-stable/include/linux/lockdep.h:14,
from /work/linux-src/linux-stable/include/linux/mutex.h:17,
from /work/linux-src/linux-stable/include/linux/kernfs.h:11,
from /work/linux-src/linux-stable/include/linux/sysfs.h:16,
from /work/linux-src/linux-stable/include/linux/kobject.h:20,
from /work/linux-src/linux-stable/include/linux/dmi.h:6,
from pci.c:5:
In function 'fortify_memcpy_chk',
inlined from 'rtw_pci_rx_napi.constprop' at pci.c:1095:4:
/work/linux-src/linux-stable/include/linux/fortify-string.h:569:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
569 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After this patch, the size of struct ieee80211_rx_status is 48.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260411072509.1556635-1-pkshih@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-11 15:25:09 +08:00
|
|
|
|
|
|
|
|
|
2012-07-05 13:14:18 +02:00
|
|
|
|
2017-04-26 13:51:41 +02:00
|
|
|
|
2012-07-05 13:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-22 16:29:31 +02:00
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:06 +03:00
|
|
|
|
2022-08-17 16:12:12 +05:30
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: add __packed to union members of struct ieee80211_rx_status
The arm-linux-gnueabi-gcc compiler, align the field followed by union
members, causing size of struct ieee80211_rx_status over skb->cb
(48 bytes). By investigation, the union member starts at offset 32,
and the offset of next field rate_idx is 36 instead of expected 33, and
the total size is (unexpected) 52.
When compiling rtw88 driver, it throws:
In file included from /work/linux-src/linux-stable/include/linux/string.h:386,
from /work/linux-src/linux-stable/include/linux/bitmap.h:13,
from /work/linux-src/linux-stable/include/linux/cpumask.h:11,
from /work/linux-src/linux-stable/include/linux/smp.h:13,
from /work/linux-src/linux-stable/include/linux/lockdep.h:14,
from /work/linux-src/linux-stable/include/linux/mutex.h:17,
from /work/linux-src/linux-stable/include/linux/kernfs.h:11,
from /work/linux-src/linux-stable/include/linux/sysfs.h:16,
from /work/linux-src/linux-stable/include/linux/kobject.h:20,
from /work/linux-src/linux-stable/include/linux/dmi.h:6,
from pci.c:5:
In function 'fortify_memcpy_chk',
inlined from 'rtw_pci_rx_napi.constprop' at pci.c:1095:4:
/work/linux-src/linux-stable/include/linux/fortify-string.h:569:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
569 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After this patch, the size of struct ieee80211_rx_status is 48.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260411072509.1556635-1-pkshih@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-11 15:25:09 +08:00
|
|
|
|
|
|
|
|
|
2020-04-01 18:18:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-28 10:03:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-29 12:26:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-28 02:40:49 +02:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2009-10-28 10:03:35 +01:00
|
|
|
|
2008-10-14 16:58:37 +02:00
|
|
|
|
2009-04-29 12:26:17 +02:00
|
|
|
|
2010-07-28 02:40:49 +02:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-10-08 10:59:33 +02:00
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-28 10:03:35 +01:00
|
|
|
|
2009-04-22 12:40:07 +02:00
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
2009-01-07 10:13:27 +01:00
|
|
|
|
2008-10-14 19:17:54 +02:00
|
|
|
|
2009-04-29 12:26:17 +02:00
|
|
|
|
2009-12-01 13:37:02 +01:00
|
|
|
|
2012-09-11 14:34:12 +02:00
|
|
|
|
|
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
|
|
|
|
|
2009-12-01 13:37:02 +01:00
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
2009-10-28 10:03:35 +01:00
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
2009-04-22 12:40:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-29 12:26:17 +02:00
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
|
|
|
|
|
2009-12-01 13:37:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-14 13:09:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-01 13:37:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-22 18:44:37 +02:00
|
|
|
|
|
|
|
|
|
2008-07-18 13:53:00 +08:00
|
|
|
|
2010-01-26 14:19:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-22 18:44:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-24 10:59:25 +02:00
|
|
|
|
|
|
|
|
|
2009-04-22 18:44:37 +02:00
|
|
|
|
2013-03-25 16:26:57 +01:00
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
2009-04-22 18:44:37 +02:00
|
|
|
|
2008-10-14 19:17:54 +02:00
|
|
|
|
2013-07-05 11:53:28 +02:00
|
|
|
|
|
|
|
|
|
2008-10-14 19:17:54 +02:00
|
|
|
|
2013-07-05 11:53:28 +02:00
|
|
|
|
|
|
|
|
|
2009-12-01 13:37:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-11 14:34:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2010-06-09 09:51:52 +03:00
|
|
|
|
2007-11-26 16:14:30 +02:00
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
2010-01-26 14:19:52 +01:00
|
|
|
|
2008-10-09 12:18:51 +02:00
|
|
|
|
2008-10-14 19:17:54 +02:00
|
|
|
|
|
|
|
|
|
2013-03-25 16:26:57 +01:00
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
2009-12-01 13:37:02 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-08 09:48:35 +03:00
|
|
|
|
|
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
|
|
|
|
|
2013-03-25 18:29:27 +01:00
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
2019-02-06 13:17:09 +02:00
|
|
|
|
2024-02-28 09:55:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-08 09:48:35 +03:00
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
2013-03-25 18:29:27 +01:00
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
2024-02-28 09:55:43 +01:00
|
|
|
|
2019-02-06 13:17:09 +02:00
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 12:48:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-27 08:38:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-28 17:35:27 +03:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-24 19:27:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:58 +01:00
|
|
|
|
2014-11-11 12:48:42 +01:00
|
|
|
|
2015-10-27 08:38:40 +01:00
|
|
|
|
2023-09-28 17:35:27 +03:00
|
|
|
|
wifi: mac80211: support wider bandwidth OFDMA config
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 <johannes.berg@intel.com>
2024-01-29 19:34:42 +01:00
|
|
|
|
2024-12-24 19:27:30 +02:00
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-04 21:54:03 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
2026-06-04 21:54:03 +05:30
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
|
|
|
|
|
2026-01-29 14:15:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-24 15:02:16 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
2024-01-02 21:35:37 +02:00
|
|
|
|
2023-06-04 12:11:17 +03:00
|
|
|
|
2024-01-02 21:35:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-24 16:08:39 +02:00
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-24 15:02:16 +02:00
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
2023-05-04 16:45:10 +03:00
|
|
|
|
2023-06-04 12:11:17 +03:00
|
|
|
|
2024-01-02 21:35:37 +02:00
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-24 16:08:39 +02:00
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
|
|
|
|
|
2024-01-02 21:35:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:27 +01:00
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
2008-10-11 01:51:51 +02:00
|
|
|
|
|
|
|
|
|
2022-05-30 13:09:28 +02:00
|
|
|
|
|
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
2022-09-02 16:12:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-18 18:53:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-02 21:35:34 +02:00
|
|
|
|
2024-03-18 18:53:20 +02:00
|
|
|
|
|
|
|
|
|
2024-01-02 21:35:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-25 17:46:19 +01:00
|
|
|
|
2024-11-15 12:58:50 +01:00
|
|
|
|
|
|
|
|
|
2010-09-16 14:58:23 +02:00
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-10 13:37:59 +02:00
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
2013-03-08 14:46:14 +01:00
|
|
|
|
2013-07-05 11:53:28 +02:00
|
|
|
|
2013-03-08 14:46:14 +01:00
|
|
|
|
2015-08-15 22:39:50 +03:00
|
|
|
|
|
|
|
|
|
2020-04-21 17:48:15 +03:00
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
2026-03-26 12:14:31 +02:00
|
|
|
|
2020-09-18 13:21:16 +02:00
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
2008-10-11 01:51:51 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2024-01-02 21:35:34 +02:00
|
|
|
|
|
|
|
|
|
2016-10-15 13:28:19 +02:00
|
|
|
|
2024-11-15 12:58:50 +01:00
|
|
|
|
2010-09-16 14:58:23 +02:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2026-03-26 12:14:31 +02:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2013-03-08 14:46:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-17 12:43:01 +02:00
|
|
|
|
2020-04-21 17:48:15 +03:00
|
|
|
|
2015-08-15 22:39:50 +03:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2020-05-07 13:59:07 -05:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:11 +03:00
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 09:48:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-20 21:25:15 +03:00
|
|
|
|
2022-07-12 12:22:50 +03:00
|
|
|
|
2008-02-23 15:17:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
2008-02-23 15:17:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-13 13:37:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
2013-11-13 13:37:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-12 08:53:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 12:40:19 +03:00
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2015-03-12 08:53:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-29 12:18:56 +02:00
|
|
|
|
2022-09-02 16:12:52 +02:00
|
|
|
|
2023-08-29 12:18:56 +02:00
|
|
|
|
2022-09-02 16:12:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-29 12:18:56 +02:00
|
|
|
|
2022-09-02 16:12:52 +02:00
|
|
|
|
2022-09-27 11:39:23 +02:00
|
|
|
|
|
|
|
|
|
2023-08-29 12:18:56 +02:00
|
|
|
|
2022-09-27 11:39:23 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-06 08:39:02 -05:00
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-17 21:11:18 +02:00
|
|
|
|
|
|
|
|
|
2012-09-04 17:08:23 +02:00
|
|
|
|
2015-01-24 19:52:06 +02:00
|
|
|
|
|
|
|
|
|
2011-10-23 08:21:41 +02:00
|
|
|
|
2012-05-09 08:11:20 +03:00
|
|
|
|
2011-10-23 08:21:41 +02:00
|
|
|
|
2015-01-06 08:39:02 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-04 17:08:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-14 11:27:21 +02:00
|
|
|
|
2015-01-24 19:52:06 +02:00
|
|
|
|
2019-10-25 10:36:47 +13:00
|
|
|
|
2015-01-06 08:39:02 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-01 13:50:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-19 21:34:08 +01:00
|
|
|
|
2019-07-16 00:09:19 +02:00
|
|
|
|
2024-03-26 08:30:36 +08:00
|
|
|
|
|
|
|
|
|
2024-01-02 21:35:40 +02:00
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
2014-04-14 11:27:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-06 08:39:02 -05:00
|
|
|
|
2017-12-01 13:50:52 +02:00
|
|
|
|
2019-03-19 21:34:08 +01:00
|
|
|
|
2019-07-16 00:09:19 +02:00
|
|
|
|
2024-01-02 21:35:40 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
2016-02-14 13:56:35 +02:00
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2025-01-01 07:05:23 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2008-06-21 10:02:46 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-29 12:55:09 +01:00
|
|
|
|
|
|
|
|
|
2025-01-02 16:20:05 +02:00
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2015-06-01 15:36:51 +02:00
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
2008-10-05 18:02:48 +02:00
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2017-12-01 13:50:52 +02:00
|
|
|
|
2022-08-17 11:17:01 +02:00
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2020-05-07 13:59:07 -05:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2015-04-20 18:21:58 +02:00
|
|
|
|
|
|
|
|
|
2016-02-14 13:56:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 18:12:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 18:21:58 +02:00
|
|
|
|
2015-04-20 18:12:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 18:21:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-20 18:12:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:21 -04:00
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2007-09-18 17:29:21 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2012-01-20 13:55:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-07 11:47:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-14 17:30:00 +01:00
|
|
|
|
2013-02-07 11:47:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-14 17:30:00 +01:00
|
|
|
|
2013-02-07 11:47:44 +01:00
|
|
|
|
|
|
|
|
|
2025-01-01 07:05:21 +02:00
|
|
|
|
|
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-02 07:15:09 -04:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-29 16:19:09 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-06 19:02:04 +02:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-19 13:12:38 +02:00
|
|
|
|
2022-09-02 16:12:41 +02:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
2025-06-17 18:06:08 +10:00
|
|
|
|
2023-07-10 16:03:09 -07:00
|
|
|
|
2026-03-26 12:14:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:38 +02:00
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-06 19:02:04 +02:00
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2022-08-19 13:12:38 +02:00
|
|
|
|
2022-09-02 16:12:41 +02:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
2025-06-17 18:06:08 +10:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-03 13:59:58 +01:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-22 17:14:04 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 08:09:55 +01:00
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2011-09-11 09:46:55 +03:00
|
|
|
|
2016-10-18 23:12:12 +03:00
|
|
|
|
|
|
|
|
|
2011-09-11 09:46:55 +03:00
|
|
|
|
2013-05-02 07:15:09 -04:00
|
|
|
|
2014-05-01 10:17:27 +03:00
|
|
|
|
2014-10-22 12:32:48 +03:00
|
|
|
|
|
|
|
|
|
2015-10-07 10:40:04 +05:30
|
|
|
|
2022-07-13 12:05:27 +03:00
|
|
|
|
2015-12-13 15:41:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-27 10:43:18 +05:30
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-17 15:41:39 +02:00
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
2024-01-02 21:35:40 +02:00
|
|
|
|
2026-01-14 16:48:56 +05:30
|
|
|
|
2026-03-26 12:14:38 +02:00
|
|
|
|
2026-03-26 12:14:39 +02:00
|
|
|
|
2026-04-28 11:06:57 +02:00
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
2024-07-25 12:09:25 +03:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
2011-06-27 23:58:45 +03:00
|
|
|
|
2011-08-23 14:37:47 +03:00
|
|
|
|
|
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
2014-05-01 10:17:27 +03:00
|
|
|
|
2014-10-22 12:32:48 +03:00
|
|
|
|
2015-10-07 10:40:04 +05:30
|
|
|
|
2022-07-13 12:05:27 +03:00
|
|
|
|
2024-01-02 21:35:40 +02:00
|
|
|
|
2015-12-13 15:41:05 +02:00
|
|
|
|
2025-03-27 10:43:18 +05:30
|
|
|
|
2017-01-13 11:12:01 +01:00
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
|
|
|
|
|
2016-03-17 15:41:39 +02:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
2026-04-28 11:06:57 +02:00
|
|
|
|
2026-01-14 16:48:56 +05:30
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2022-06-15 09:20:45 +02:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2026-03-26 12:14:38 +02:00
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
2020-05-07 13:59:07 -05:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-27 11:39:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-20 21:25:16 +03:00
|
|
|
|
2022-07-12 12:22:50 +03:00
|
|
|
|
2007-09-30 13:52:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-19 11:32:30 +05:30
|
|
|
|
2007-09-30 13:52:37 +02:00
|
|
|
|
2008-11-30 00:48:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-09 16:28:06 +01:00
|
|
|
|
2008-11-30 00:48:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-23 21:33:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2015-05-20 15:04:53 +02:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-07 13:59:07 -05:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-17 18:18:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-14 11:43:20 -07:00
|
|
|
|
2007-09-18 17:29:15 -04:00
|
|
|
|
2008-05-08 19:15:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 17:53:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-24 09:55:27 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-18 23:35:27 +02:00
|
|
|
|
2009-01-07 18:28:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-08 13:32:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-22 21:57:35 +02:00
|
|
|
|
2010-02-09 14:50:28 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-19 07:14:53 +02:00
|
|
|
|
2013-07-05 11:53:28 +02:00
|
|
|
|
|
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
2012-12-12 10:12:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-05 19:39:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-31 22:29:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-30 09:32:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-02 17:44:55 +02:00
|
|
|
|
2012-04-03 14:35:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2024-10-09 10:25:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-22 12:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-22 18:44:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-19 17:19:44 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-19 17:19:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-05 17:48:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-01 17:15:51 +03:00
|
|
|
|
2013-10-14 10:05:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-01 17:15:51 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-27 14:33:47 +02:00
|
|
|
|
2014-07-29 15:39:14 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 20:32:00 +02:00
|
|
|
|
2014-02-05 15:21:13 +02:00
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2015-06-10 20:42:59 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-15 22:39:51 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 09:46:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-22 17:35:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:38 +02:00
|
|
|
|
|
|
|
|
|
2015-10-22 17:35:19 +02:00
|
|
|
|
2015-12-08 19:09:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-31 20:02:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-14 12:48:32 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 23:12:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-24 16:51:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-19 12:57:44 +13:00
|
|
|
|
|
|
|
|
|
2018-02-19 14:48:41 +02:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:17 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-16 22:32:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-16 23:03:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-29 21:50:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-30 07:05:16 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-25 11:42:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-11 09:05:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 09:55:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-05 11:39:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-05 14:43:04 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2007-09-18 17:29:15 -04:00
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-09 10:25:48 +02:00
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-10 20:42:59 +03:00
|
|
|
|
2015-08-15 22:39:51 +03:00
|
|
|
|
2015-09-09 09:46:32 +02:00
|
|
|
|
2015-10-22 17:35:19 +02:00
|
|
|
|
2015-12-08 19:09:05 +02:00
|
|
|
|
2016-03-31 20:02:11 +03:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
2016-09-14 12:48:32 +05:30
|
|
|
|
2016-10-18 23:12:11 +03:00
|
|
|
|
2017-10-24 16:51:10 +08:00
|
|
|
|
2018-03-19 12:57:44 +13:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
2018-08-31 11:31:17 +03:00
|
|
|
|
2018-09-05 08:06:09 +03:00
|
|
|
|
2019-01-16 22:32:12 +01:00
|
|
|
|
2019-01-16 23:03:25 +02:00
|
|
|
|
|
|
|
|
|
2019-06-29 21:50:14 +02:00
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
2021-03-30 07:05:16 +05:30
|
|
|
|
2022-03-25 11:42:41 +01:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
2023-12-11 09:05:23 +02:00
|
|
|
|
2024-02-28 09:55:45 +01:00
|
|
|
|
2025-02-05 11:39:16 +02:00
|
|
|
|
2026-03-05 14:43:04 +05:30
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:15 -04:00
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-14 13:54:53 +01:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-05-08 19:15:40 +02:00
|
|
|
|
2013-07-05 11:53:28 +02:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-07-18 13:53:00 +08:00
|
|
|
|
2013-07-05 11:53:28 +02:00
|
|
|
|
2008-07-18 13:53:00 +08:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-04-30 18:51:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-28 14:51:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
2008-10-05 18:04:24 +02:00
|
|
|
|
2010-10-02 11:31:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2010-07-29 16:14:13 -04:00
|
|
|
|
2011-01-12 15:26:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-18 13:52:23 +01:00
|
|
|
|
|
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
2012-05-10 09:09:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2012-05-10 09:09:10 +02:00
|
|
|
|
2012-05-10 16:18:26 +03:00
|
|
|
|
2012-11-22 23:00:18 +01:00
|
|
|
|
|
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2012-11-22 23:00:18 +01:00
|
|
|
|
2016-08-29 23:25:17 +03:00
|
|
|
|
2019-02-01 11:53:32 +01:00
|
|
|
|
2016-08-29 23:25:17 +03:00
|
|
|
|
2019-02-01 11:53:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-29 23:25:17 +03:00
|
|
|
|
2012-05-10 16:18:26 +03:00
|
|
|
|
2015-04-13 16:58:25 +02:00
|
|
|
|
|
|
|
|
|
2013-01-22 16:52:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-24 14:23:27 +02:00
|
|
|
|
2016-09-20 17:31:20 +03:00
|
|
|
|
|
|
|
|
|
2018-08-08 18:40:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2019-01-29 11:31:26 +01:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2019-09-06 10:48:57 +08:00
|
|
|
|
|
|
|
|
|
2022-05-09 19:39:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-14 11:10:25 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2007-10-28 14:51:05 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2013-12-14 13:54:53 +01:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
2012-06-26 14:37:16 +02:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2008-07-18 13:53:00 +08:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2010-10-02 11:31:55 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2012-05-10 09:09:10 +02:00
|
|
|
|
2012-11-22 23:00:18 +01:00
|
|
|
|
2016-08-29 23:25:17 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-10 16:18:26 +03:00
|
|
|
|
2013-01-22 16:52:23 +02:00
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:20 +03:00
|
|
|
|
2018-08-08 18:40:01 +08:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2019-09-06 10:48:57 +08:00
|
|
|
|
2022-05-09 19:39:57 +02:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-05 15:21:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-22 15:05:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2009-01-22 15:05:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-10-20 21:20:27 -04:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-24 00:33:26 -08:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
2012-04-06 16:35:53 -05:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
2025-09-08 14:13:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-05 18:04:24 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
|
|
|
|
|
2011-11-04 11:18:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-24 11:32:12 -07:00
|
|
|
|
2011-11-04 11:18:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-22 09:42:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
[PATCH] mac80211: revamp interface and filter configuration
Drivers are currently supposed to keep track of monitor
interfaces if they allow so-called "hard" monitor, and
they are also supposed to keep track of multicast etc.
This patch changes that, replaces the set_multicast_list()
callback with a new configure_filter() callback that takes
filter flags (FIF_*) instead of interface flags (IFF_*).
For a driver, this means it should open the filter as much
as necessary to get all frames requested by the filter flags.
Accordingly, the filter flags are named "positively", e.g.
FIF_ALLMULTI.
Multicast filtering is a bit special in that drivers that
have no multicast address filters need to allow multicast
frames through when either the FIF_ALLMULTI flag is set or
when the mc_count value is positive.
At the same time, drivers are no longer notified about
monitor interfaces at all, this means they now need to
implement the start() and stop() callbacks and the new
change_filter_flags() callback. Also, the start()/stop()
ordering changed, start() is now called *before* any
add_interface() as it really should be, and stop() after
any remove_interface().
The patch also changes the behaviour of setting the bssid
to multicast for scanning when IEEE80211_HW_NO_PROBE_FILTERING
is set; the IEEE80211_HW_NO_PROBE_FILTERING flag is removed
and the filter flag FIF_BCN_PRBRESP_PROMISC introduced.
This is a lot more efficient for hardware like b43 that
supports it and other hardware can still set the BSSID
to all-ones.
Driver modifications by Johannes Berg (b43 & iwlwifi), Michael Wu
(rtl8187, adm8211, and p54), Larry Finger (b43legacy), and
Ivo van Doorn (rt2x00).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-09-17 01:29:23 -04:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-29 12:55:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2015-01-22 18:44:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-20 15:06:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-30 22:57:33 -03:00
|
|
|
|
2008-03-20 15:06:42 +02:00
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2008-10-20 21:20:27 -04:00
|
|
|
|
2008-03-20 15:06:42 +02:00
|
|
|
|
2012-05-30 11:36:39 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 15:00:38 +02:00
|
|
|
|
|
|
|
|
|
2020-07-15 09:43:24 -07:00
|
|
|
|
2018-08-31 15:00:38 +02:00
|
|
|
|
2021-09-24 22:05:14 +02:00
|
|
|
|
|
|
|
|
|
2018-08-31 15:00:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-24 22:05:14 +02:00
|
|
|
|
|
|
|
|
|
2018-08-31 15:00:38 +02:00
|
|
|
|
|
|
|
|
|
[PATCH] mac80211: revamp interface and filter configuration
Drivers are currently supposed to keep track of monitor
interfaces if they allow so-called "hard" monitor, and
they are also supposed to keep track of multicast etc.
This patch changes that, replaces the set_multicast_list()
callback with a new configure_filter() callback that takes
filter flags (FIF_*) instead of interface flags (IFF_*).
For a driver, this means it should open the filter as much
as necessary to get all frames requested by the filter flags.
Accordingly, the filter flags are named "positively", e.g.
FIF_ALLMULTI.
Multicast filtering is a bit special in that drivers that
have no multicast address filters need to allow multicast
frames through when either the FIF_ALLMULTI flag is set or
when the mc_count value is positive.
At the same time, drivers are no longer notified about
monitor interfaces at all, this means they now need to
implement the start() and stop() callbacks and the new
change_filter_flags() callback. Also, the start()/stop()
ordering changed, start() is now called *before* any
add_interface() as it really should be, and stop() after
any remove_interface().
The patch also changes the behaviour of setting the bssid
to multicast for scanning when IEEE80211_HW_NO_PROBE_FILTERING
is set; the IEEE80211_HW_NO_PROBE_FILTERING flag is removed
and the filter flag FIF_BCN_PRBRESP_PROMISC introduced.
This is a lot more efficient for hardware like b43 that
supports it and other hardware can still set the BSSID
to all-ones.
Driver modifications by Johannes Berg (b43 & iwlwifi), Michael Wu
(rtl8187, adm8211, and p54), Larry Finger (b43legacy), and
Ivo van Doorn (rt2x00).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-09-17 01:29:23 -04:00
|
|
|
|
|
|
|
|
|
2009-01-07 18:28:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-07 18:28:20 +01:00
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-21 16:39:01 -04:00
|
|
|
|
|
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-07 18:28:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-16 17:04:25 +02:00
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2009-01-07 18:28:20 +01:00
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-21 16:39:01 -04:00
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 12:48:42 +01:00
|
|
|
|
2014-02-18 22:54:36 +09:00
|
|
|
|
2010-01-14 13:09:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-07 18:28:20 +01:00
|
|
|
|
|
|
|
|
|
2009-03-22 21:57:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-28 20:31:00 -08:00
|
|
|
|
2009-03-22 21:57:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
|
|
|
|
|
2009-04-16 17:04:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-21 15:57:23 +03:00
|
|
|
|
2009-04-16 17:04:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2009-04-16 17:04:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2009-04-16 17:04:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-22 21:57:35 +02:00
|
|
|
|
|
|
|
|
|
2009-12-01 13:37:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-17 16:16:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-12 20:12:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
2011-09-29 16:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-15 21:38:08 +01:00
|
|
|
|
2011-09-29 16:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-15 21:38:08 +01:00
|
|
|
|
2014-01-09 00:00:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:40 +02:00
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-22 14:40:58 +02:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2009-08-04 16:48:51 +04:00
|
|
|
|
2015-06-02 21:10:13 +02:00
|
|
|
|
2010-10-13 12:06:24 +02:00
|
|
|
|
|
|
|
|
|
2020-04-21 17:48:15 +03:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-04 16:48:51 +04:00
|
|
|
|
2010-10-13 12:06:24 +02:00
|
|
|
|
2020-04-21 17:48:15 +03:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2007-12-25 17:00:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-22 12:28:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-10 10:21:40 +02:00
|
|
|
|
2009-11-22 12:28:41 +01:00
|
|
|
|
|
|
|
|
|
2012-07-18 13:51:25 +02:00
|
|
|
|
|
|
|
|
|
2019-10-02 11:12:25 +02:00
|
|
|
|
2020-03-26 15:09:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-02 11:12:25 +02:00
|
|
|
|
2009-03-23 17:28:39 +01:00
|
|
|
|
2012-07-18 13:51:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-25 17:00:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
2012-07-18 13:51:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:39 +01:00
|
|
|
|
2007-12-25 17:00:31 +02:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2019-10-02 11:12:25 +02:00
|
|
|
|
2020-03-26 15:09:38 +02:00
|
|
|
|
2019-10-02 11:12:25 +02:00
|
|
|
|
2015-12-30 16:06:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
|
2015-12-30 16:06:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:33 +02:00
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:33 +02:00
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
|
|
|
|
|
2012-03-30 08:43:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-07 11:47:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-30 08:43:32 +02:00
|
|
|
|
2012-08-12 18:24:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-27 18:55:36 +01:00
|
|
|
|
|
|
|
|
|
2012-03-30 08:43:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-12 18:24:55 +02:00
|
|
|
|
2012-12-27 18:55:36 +01:00
|
|
|
|
2012-03-30 08:43:32 +02:00
|
|
|
|
|
|
|
|
|
2013-02-12 09:34:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-25 10:36:47 +13:00
|
|
|
|
2013-02-12 09:34:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-25 10:36:47 +13:00
|
|
|
|
2013-02-12 09:34:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-04 11:43:54 +02:00
|
|
|
|
2020-10-23 18:33:08 +02:00
|
|
|
|
2014-11-04 11:43:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-18 13:41:55 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-27 13:25:27 +02:00
|
|
|
|
|
|
|
|
|
2023-09-28 17:35:34 +03:00
|
|
|
|
2025-02-05 11:39:20 +02:00
|
|
|
|
2021-06-18 13:41:55 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-27 13:25:27 +02:00
|
|
|
|
2023-09-28 17:35:34 +03:00
|
|
|
|
2021-06-18 13:41:55 +03:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-17 00:57:13 +02:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-29 20:08:07 -04:00
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2011-05-04 15:37:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-02 00:02:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-04 15:37:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-09 10:31:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-10-20 21:20:27 -04:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2010-08-27 12:35:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-08 21:00:34 -05:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
|
|
|
|
|
2022-05-24 10:55:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
2009-08-17 16:16:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2015-08-15 22:39:50 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-14 11:43:20 -07:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
|
|
|
|
|
2008-12-29 12:55:09 +01:00
|
|
|
|
2009-01-08 21:00:34 -05:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-03-20 15:06:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-24 14:55:12 +02:00
|
|
|
|
2008-03-20 15:06:42 +02:00
|
|
|
|
2011-07-05 16:35:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-30 11:36:39 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2009-03-22 21:57:21 +02:00
|
|
|
|
|
|
|
|
|
2009-04-01 11:58:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-18 10:35:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2011-06-13 12:47:30 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-11 17:09:36 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-17 10:48:17 +01:00
|
|
|
|
2011-05-11 17:09:36 +03:00
|
|
|
|
2009-02-20 15:37:03 +01:00
|
|
|
|
|
|
|
|
|
2014-06-12 22:24:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-20 15:37:03 +01:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-20 15:37:03 +01:00
|
|
|
|
2009-01-08 21:00:34 -05:00
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2015-04-20 18:12:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2010-11-08 11:51:06 +02:00
|
|
|
|
2016-10-18 23:12:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-08 11:51:06 +02:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2010-02-03 13:59:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-04 22:39:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-03 13:59:58 +01:00
|
|
|
|
2023-09-28 17:35:25 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-20 08:46:02 +05:30
|
|
|
|
|
|
|
|
|
2016-09-14 10:03:00 +02:00
|
|
|
|
|
|
|
|
|
2012-11-20 08:46:02 +05:30
|
|
|
|
2022-09-06 14:26:52 +02:00
|
|
|
|
|
|
|
|
|
2023-06-21 09:16:26 +02:00
|
|
|
|
2022-09-06 14:26:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-03 13:59:58 +01:00
|
|
|
|
2011-01-31 22:29:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-30 00:48:41 +01:00
|
|
|
|
2020-03-12 22:44:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-20 13:55:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-04 22:39:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-20 13:55:21 +01:00
|
|
|
|
|
|
|
|
|
2024-10-07 15:00:54 +03:00
|
|
|
|
|
|
|
|
|
2012-03-30 08:43:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-19 00:10:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-30 08:43:32 +02:00
|
|
|
|
2014-11-17 11:35:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-28 11:14:20 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-09-08 11:05:09 +02:00
|
|
|
|
2009-01-08 21:00:34 -05:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2009-01-24 07:09:59 +01:00
|
|
|
|
2009-02-05 17:58:34 +01:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2009-01-24 07:09:59 +01:00
|
|
|
|
|
|
|
|
|
2013-07-05 11:53:28 +02:00
|
|
|
|
2009-02-05 17:58:34 +01:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2016-09-28 16:56:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-08 21:00:34 -05:00
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2007-11-26 16:14:34 +02:00
|
|
|
|
2010-05-21 11:28:33 -07:00
|
|
|
|
|
|
|
|
|
2009-06-02 13:01:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:47 +01:00
|
|
|
|
2009-07-01 21:26:51 +02:00
|
|
|
|
2009-12-21 22:50:48 +01:00
|
|
|
|
|
|
|
|
|
2014-09-04 23:57:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-21 22:50:48 +01:00
|
|
|
|
2013-07-31 18:06:22 +03:00
|
|
|
|
|
|
|
|
|
2011-05-20 09:05:54 -07:00
|
|
|
|
2009-12-23 13:15:32 +01:00
|
|
|
|
|
|
|
|
|
2013-02-13 12:11:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-27 11:30:29 +02:00
|
|
|
|
2013-02-13 12:11:00 +01:00
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
2023-03-31 16:59:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-29 16:14:13 -04:00
|
|
|
|
2010-11-24 14:34:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-04 13:02:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-05 14:28:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-04 13:02:32 +01:00
|
|
|
|
|
|
|
|
|
2011-03-07 16:19:18 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-06 11:41:10 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-27 16:56:51 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
2015-04-20 22:53:37 +03:00
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 22:54:36 +09:00
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:33 +02:00
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:39 +02:00
|
|
|
|
2013-02-15 21:38:08 +01:00
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
2011-09-29 16:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
2011-09-29 16:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:39 +02:00
|
|
|
|
2013-02-15 21:38:08 +01:00
|
|
|
|
2011-09-29 16:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:50:31 -07:00
|
|
|
|
|
|
|
|
|
2023-09-19 08:40:52 +02:00
|
|
|
|
|
|
|
|
|
2012-04-23 12:50:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-19 08:40:52 +02:00
|
|
|
|
|
|
|
|
|
2012-04-23 12:50:31 -07:00
|
|
|
|
2012-06-27 13:18:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-27 13:25:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 13:18:36 +02:00
|
|
|
|
|
|
|
|
|
2021-06-18 13:41:55 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 13:18:36 +02:00
|
|
|
|
2021-06-18 13:41:55 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-09 21:35:27 +03:00
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
2014-06-11 17:18:27 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
2015-10-30 23:16:15 +05:30
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
2015-10-30 23:16:15 +05:30
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-30 23:16:15 +05:30
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
|
|
|
|
|
2015-10-30 23:16:15 +05:30
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
|
|
|
|
|
2015-10-30 23:16:15 +05:30
|
|
|
|
2014-05-23 14:33:12 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-30 23:16:15 +05:30
|
|
|
|
2014-05-23 14:33:12 +03:00
|
|
|
|
2012-10-19 15:44:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 19:18:13 +01:00
|
|
|
|
2014-11-04 11:43:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-11 00:28:01 +01:00
|
|
|
|
2013-01-14 15:14:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: only set CSA beacon when at least one beacon must be transmitted
A beacon should never have a Channel Switch Announcement information
element with a count of 0, because a count of 1 means switch just
before the next beacon. So, if a count of 0 was valid in a beacon, it
would have been transmitted in the next channel already, which is
useless. A CSA count equal to zero is only meaningful in action
frames or probe_responses.
Fix the ieee80211_csa_is_complete() and ieee80211_update_csa()
functions accordingly.
With a CSA count of 0, we won't transmit any CSA beacons, because the
switch will happen before the next TBTT. To avoid extra work and
potential confusion in the drivers, complete the CSA immediately,
instead of waiting for the driver to call ieee80211_csa_finish().
To keep things simpler, we also switch immediately when the CSA count
is 1, while in theory we should delay the switch until just before the
next TBTT.
Additionally, move the ieee80211_csa_finish() function to cfg.c,
where it makes more sense.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-13 19:43:00 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
mac80211: only set CSA beacon when at least one beacon must be transmitted
A beacon should never have a Channel Switch Announcement information
element with a count of 0, because a count of 1 means switch just
before the next beacon. So, if a count of 0 was valid in a beacon, it
would have been transmitted in the next channel already, which is
useless. A CSA count equal to zero is only meaningful in action
frames or probe_responses.
Fix the ieee80211_csa_is_complete() and ieee80211_update_csa()
functions accordingly.
With a CSA count of 0, we won't transmit any CSA beacons, because the
switch will happen before the next TBTT. To avoid extra work and
potential confusion in the drivers, complete the CSA immediately,
instead of waiting for the driver to call ieee80211_csa_finish().
To keep things simpler, we also switch immediately when the CSA count
is 1, while in theory we should delay the switch until just before the
next TBTT.
Additionally, move the ieee80211_csa_finish() function to cfg.c,
where it makes more sense.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-13 19:43:00 +02:00
|
|
|
|
|
|
|
|
|
2014-10-08 09:48:37 +03:00
|
|
|
|
|
|
|
|
|
2017-02-27 14:28:47 -08:00
|
|
|
|
2014-10-08 09:48:37 +03:00
|
|
|
|
2014-10-08 09:48:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-06 13:17:10 +02:00
|
|
|
|
2024-02-28 09:55:44 +01:00
|
|
|
|
2019-02-06 13:17:10 +02:00
|
|
|
|
2019-02-06 13:17:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-19 18:48:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-19 21:53:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-26 00:32:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
2016-03-02 23:46:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:14 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:19 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:20 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
|
|
|
|
|
2018-10-16 11:24:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-20 13:21:27 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-18 13:21:16 +02:00
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2020-09-08 14:37:01 +02:00
|
|
|
|
|
|
|
|
|
2021-01-06 23:47:41 +01:00
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
|
|
|
|
|
2021-08-23 20:02:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-29 14:11:24 +01:00
|
|
|
|
2021-10-23 11:10:51 +02:00
|
|
|
|
|
|
|
|
|
2021-11-29 14:11:24 +01:00
|
|
|
|
2021-10-23 11:10:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-29 14:11:24 +01:00
|
|
|
|
2021-11-12 12:22:23 +01:00
|
|
|
|
|
|
|
|
|
2023-12-20 13:41:45 +02:00
|
|
|
|
|
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-01 10:42:40 +02:00
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
wifi: mac80211: avoid weird state in error path
If we get to the error path of ieee80211_prep_connection, for example
because of a FW issue, then ieee80211_vif_set_links is called
with 0.
But the call to drv_change_vif_links from ieee80211_vif_update_links
will probably fail as well, for the same reason.
In this case, the valid_links and active_links bitmaps will be reverted
to the value of the failing connection.
Then, in the next connection, due to the logic of
ieee80211_set_vif_links_bitmaps, valid_links will be set to the ID of
the new connection assoc link, but the active_links will remain with the
ID of the old connection's assoc link.
If those IDs are different, we get into a weird state of valid_links and
active_links being different. One of the consequences of this state is
to call drv_change_vif_links with new_links as 0, since the & operation
between the bitmaps will be 0.
Since a removal of a link should always succeed, ignore the return value
of drv_change_vif_links if it was called to only remove links, which is
the case for the ieee80211_prep_connection's error path.
That way, the bitmaps will not be reverted to have the value from the
failing connection and will have 0, so the next connection will have a
good state.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250609213231.ba2011fb435f.Id87ff6dab5e1cf757b54094ac2d714c656165059@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-09 21:35:13 +03:00
|
|
|
|
|
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-21 10:12:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-02 21:35:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-07 15:00:45 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-29 14:15:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2012-07-23 21:33:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] mac80211: revamp interface and filter configuration
Drivers are currently supposed to keep track of monitor
interfaces if they allow so-called "hard" monitor, and
they are also supposed to keep track of multicast etc.
This patch changes that, replaces the set_multicast_list()
callback with a new configure_filter() callback that takes
filter flags (FIF_*) instead of interface flags (IFF_*).
For a driver, this means it should open the filter as much
as necessary to get all frames requested by the filter flags.
Accordingly, the filter flags are named "positively", e.g.
FIF_ALLMULTI.
Multicast filtering is a bit special in that drivers that
have no multicast address filters need to allow multicast
frames through when either the FIF_ALLMULTI flag is set or
when the mc_count value is positive.
At the same time, drivers are no longer notified about
monitor interfaces at all, this means they now need to
implement the start() and stop() callbacks and the new
change_filter_flags() callback. Also, the start()/stop()
ordering changed, start() is now called *before* any
add_interface() as it really should be, and stop() after
any remove_interface().
The patch also changes the behaviour of setting the bssid
to multicast for scanning when IEEE80211_HW_NO_PROBE_FILTERING
is set; the IEEE80211_HW_NO_PROBE_FILTERING flag is removed
and the filter flag FIF_BCN_PRBRESP_PROMISC introduced.
This is a lot more efficient for hardware like b43 that
supports it and other hardware can still set the BSSID
to all-ones.
Driver modifications by Johannes Berg (b43 & iwlwifi), Michael Wu
(rtl8187, adm8211, and p54), Larry Finger (b43legacy), and
Ivo van Doorn (rt2x00).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-09-17 01:29:23 -04:00
|
|
|
|
2024-06-18 19:25:56 +03:00
|
|
|
|
2011-05-04 15:37:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-04 15:05:25 +02:00
|
|
|
|
2011-05-04 15:37:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2010-08-27 12:35:58 +02:00
|
|
|
|
|
|
|
|
|
2010-09-16 14:58:23 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
|
2007-12-28 14:32:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-24 10:55:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
|
|
|
|
|
2011-07-19 10:39:53 +02:00
|
|
|
|
2022-06-02 15:08:16 +03:00
|
|
|
|
2022-06-29 12:22:24 +03:00
|
|
|
|
2022-06-02 15:08:16 +03:00
|
|
|
|
2022-06-29 12:22:24 +03:00
|
|
|
|
2012-10-19 15:44:42 +02:00
|
|
|
|
2009-08-17 16:16:53 +02:00
|
|
|
|
2010-04-01 21:22:57 +00:00
|
|
|
|
[PATCH] mac80211: revamp interface and filter configuration
Drivers are currently supposed to keep track of monitor
interfaces if they allow so-called "hard" monitor, and
they are also supposed to keep track of multicast etc.
This patch changes that, replaces the set_multicast_list()
callback with a new configure_filter() callback that takes
filter flags (FIF_*) instead of interface flags (IFF_*).
For a driver, this means it should open the filter as much
as necessary to get all frames requested by the filter flags.
Accordingly, the filter flags are named "positively", e.g.
FIF_ALLMULTI.
Multicast filtering is a bit special in that drivers that
have no multicast address filters need to allow multicast
frames through when either the FIF_ALLMULTI flag is set or
when the mc_count value is positive.
At the same time, drivers are no longer notified about
monitor interfaces at all, this means they now need to
implement the start() and stop() callbacks and the new
change_filter_flags() callback. Also, the start()/stop()
ordering changed, start() is now called *before* any
add_interface() as it really should be, and stop() after
any remove_interface().
The patch also changes the behaviour of setting the bssid
to multicast for scanning when IEEE80211_HW_NO_PROBE_FILTERING
is set; the IEEE80211_HW_NO_PROBE_FILTERING flag is removed
and the filter flag FIF_BCN_PRBRESP_PROMISC introduced.
This is a lot more efficient for hardware like b43 that
supports it and other hardware can still set the BSSID
to all-ones.
Driver modifications by Johannes Berg (b43 & iwlwifi), Michael Wu
(rtl8187, adm8211, and p54), Larry Finger (b43legacy), and
Ivo van Doorn (rt2x00).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2007-09-17 01:29:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-17 16:16:53 +02:00
|
|
|
|
2015-08-15 22:39:50 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:21 -04:00
|
|
|
|
2008-12-29 12:55:09 +01:00
|
|
|
|
2007-08-28 17:01:55 -04:00
|
|
|
|
2008-03-20 15:06:42 +02:00
|
|
|
|
2010-01-21 11:40:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-05 16:35:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-30 11:36:39 +03:00
|
|
|
|
|
|
|
|
|
2010-04-27 11:59:34 +02:00
|
|
|
|
2014-02-05 15:21:13 +02:00
|
|
|
|
2011-06-13 12:47:30 +03:00
|
|
|
|
|
|
|
|
|
2011-05-11 17:09:36 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 16:15:23 +02:00
|
|
|
|
2014-02-17 10:48:17 +01:00
|
|
|
|
2011-05-11 17:09:36 +03:00
|
|
|
|
2014-06-12 22:24:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2015-04-20 18:12:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-03 13:59:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-20 08:46:02 +05:30
|
|
|
|
2023-09-28 17:35:25 +03:00
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-20 08:46:02 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-06 14:26:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-20 08:46:02 +05:30
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
2019-03-29 16:19:09 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-20 13:55:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-04 22:39:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-07 15:00:54 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-19 00:10:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-17 11:35:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-02 10:15:52 +02:00
|
|
|
|
2022-06-24 15:40:11 +02:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2011-09-21 14:06:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 16:56:28 -07:00
|
|
|
|
|
|
|
|
|
2011-09-21 14:06:11 +03:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2025-05-28 11:14:20 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-13 11:12:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-02 11:12:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-13 11:12:01 +01:00
|
|
|
|
|
|
|
|
|
2007-12-25 17:00:31 +02:00
|
|
|
|
2009-11-16 12:00:38 +01:00
|
|
|
|
2015-12-30 16:06:04 +02:00
|
|
|
|
2010-04-19 10:23:57 +02:00
|
|
|
|
|
|
|
|
|
2009-06-02 13:01:41 +02:00
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
|
|
|
|
|
|
2009-07-01 21:26:51 +02:00
|
|
|
|
2013-07-31 18:06:22 +03:00
|
|
|
|
|
|
|
|
|
2011-05-20 09:05:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-01 21:26:51 +02:00
|
|
|
|
2014-03-27 11:30:29 +02:00
|
|
|
|
|
|
|
|
|
2023-03-31 16:59:17 +02:00
|
|
|
|
|
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
2014-10-08 09:48:40 +03:00
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 17:20:47 +01:00
|
|
|
|
|
|
|
|
|
2012-11-19 17:05:09 +02:00
|
|
|
|
2010-12-18 17:20:47 +01:00
|
|
|
|
2013-02-12 09:34:13 +02:00
|
|
|
|
|
|
|
|
|
2019-07-23 21:00:01 +03:00
|
|
|
|
|
|
|
|
|
2011-03-07 16:19:18 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-06 11:41:10 +05:30
|
|
|
|
2011-04-27 16:56:51 +05:30
|
|
|
|
|
|
|
|
|
2015-03-16 23:23:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
2011-09-29 16:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:50:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-27 13:18:36 +02:00
|
|
|
|
|
|
|
|
|
2018-04-20 13:49:25 +03:00
|
|
|
|
2021-06-18 13:41:55 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
2014-06-11 17:18:27 +03:00
|
|
|
|
2023-09-28 17:35:35 +03:00
|
|
|
|
|
|
|
|
|
2014-06-11 17:18:27 +03:00
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-03 18:04:15 +03:00
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-03 18:04:15 +03:00
|
|
|
|
2012-06-26 14:37:17 +02:00
|
|
|
|
2014-05-23 14:33:12 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 19:18:13 +01:00
|
|
|
|
2014-11-04 11:43:54 +02:00
|
|
|
|
|
|
|
|
|
2013-01-14 15:14:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-08 09:48:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-19 18:48:41 +02:00
|
|
|
|
2014-10-08 09:48:38 +03:00
|
|
|
|
2023-08-28 13:04:10 +03:00
|
|
|
|
|
|
|
|
|
2019-02-06 13:17:10 +02:00
|
|
|
|
2024-02-28 09:55:44 +01:00
|
|
|
|
|
|
|
|
|
2019-02-06 13:17:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-08 09:48:38 +03:00
|
|
|
|
2013-08-19 18:48:41 +02:00
|
|
|
|
|
|
|
|
|
2016-08-04 15:43:04 +03:00
|
|
|
|
|
|
|
|
|
2014-10-26 00:32:53 +02:00
|
|
|
|
2024-11-25 14:02:17 +05:30
|
|
|
|
2014-11-09 18:50:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:20 +02:00
|
|
|
|
2014-11-09 18:50:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2017-12-19 10:11:54 +01:00
|
|
|
|
|
|
|
|
|
2016-03-02 23:46:14 +02:00
|
|
|
|
2016-09-20 17:31:14 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:19 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:20 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:39 +02:00
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-03 20:19:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-16 11:24:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-20 13:21:27 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:37:01 +02:00
|
|
|
|
|
|
|
|
|
2020-12-03 05:37:27 -05:00
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-23 20:02:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-29 14:11:24 +01:00
|
|
|
|
|
|
|
|
|
2021-11-12 12:22:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-20 13:41:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-31 23:20:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-21 10:12:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-02 21:35:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-07 15:00:45 +03:00
|
|
|
|
|
|
|
|
|
2026-01-29 14:15:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2014-10-22 12:23:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2014-10-22 12:23:01 -07:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2014-10-22 12:23:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-26 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2010-11-30 08:58:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-30 08:59:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2015-04-23 12:09:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2015-04-23 12:09:01 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2015-04-23 12:09:01 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-07 19:45:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2008-01-07 19:45:24 +01:00
|
|
|
|
2015-04-23 12:09:01 +02:00
|
|
|
|
2007-09-27 15:10:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-07 19:45:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2008-01-07 19:45:24 +01:00
|
|
|
|
2015-04-23 12:09:01 +02:00
|
|
|
|
2008-01-07 19:45:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-27 15:10:44 +02:00
|
|
|
|
2010-11-30 08:58:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-30 08:59:23 +01:00
|
|
|
|
2010-11-30 08:58:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-30 08:58:45 +01:00
|
|
|
|
2015-04-23 12:09:01 +02:00
|
|
|
|
2010-11-30 08:59:23 +01:00
|
|
|
|
2010-11-30 08:58:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-30 08:59:23 +01:00
|
|
|
|
2010-11-30 08:58:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-03 13:52:18 -07:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2009-04-14 10:09:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-26 13:06:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2020-07-26 13:06:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-04 20:51:09 +01:00
|
|
|
|
2015-06-11 16:02:32 +02:00
|
|
|
|
2010-07-29 16:14:13 -04:00
|
|
|
|
2015-06-11 16:02:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2015-06-11 16:02:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-31 20:02:02 +03:00
|
|
|
|
2015-06-11 16:02:32 +02:00
|
|
|
|
|
|
|
|
|
2010-07-29 16:14:13 -04:00
|
|
|
|
2016-03-31 20:02:02 +03:00
|
|
|
|
|
|
|
|
|
2010-07-29 16:14:13 -04:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-29 17:35:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
2009-10-13 20:33:13 +03:00
|
|
|
|
|
|
|
|
|
2013-05-03 10:01:03 +02:00
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2009-10-13 20:33:13 +03:00
|
|
|
|
2009-10-11 15:10:40 +02:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-11 16:02:32 +02:00
|
|
|
|
|
|
|
|
|
2016-03-31 20:02:02 +03:00
|
|
|
|
2015-06-11 16:02:32 +02:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
|
|
|
|
|
2009-10-13 20:33:13 +03:00
|
|
|
|
2013-05-03 10:01:03 +02:00
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-17 13:13:00 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2009-10-13 20:33:13 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-03 10:01:03 +02:00
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2009-10-13 20:33:13 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-31 22:29:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2011-01-31 22:29:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2011-01-31 22:29:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-03 16:58:00 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 23:12:10 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-03 16:58:00 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-04 23:46:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-10 13:20:34 +01:00
|
|
|
|
2009-12-04 23:46:54 +01:00
|
|
|
|
2011-04-17 17:45:00 +02:00
|
|
|
|
2011-09-29 16:04:26 +02:00
|
|
|
|
2011-05-22 17:22:45 -07:00
|
|
|
|
2011-09-29 16:04:26 +02:00
|
|
|
|
|
|
|
|
|
2011-04-17 17:45:00 +02:00
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:26 +02:00
|
|
|
|
|
|
|
|
|
2011-04-17 17:45:00 +02:00
|
|
|
|
2011-09-29 16:04:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-17 17:45:00 +02:00
|
|
|
|
2011-09-29 16:04:26 +02:00
|
|
|
|
|
|
|
|
|
2011-04-17 17:45:00 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-11 18:15:03 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
|
|
|
|
|
2010-11-30 16:49:23 +01:00
|
|
|
|
2013-05-03 10:01:03 +02:00
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
2017-04-26 17:11:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2017-04-26 17:11:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-19 20:08:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2014-11-19 20:08:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-26 17:11:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-19 20:08:13 +01:00
|
|
|
|
2010-11-30 16:49:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2010-11-30 16:49:23 +01:00
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2010-11-30 16:49:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2010-11-30 16:49:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
2008-07-03 13:52:18 -07:00
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
|
|
|
|
|
2023-10-12 14:42:28 +03:00
|
|
|
|
2010-11-30 16:49:23 +01:00
|
|
|
|
2008-02-25 16:27:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2011-04-18 14:22:28 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
|
|
|
|
|
2014-05-15 20:32:08 +03:00
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-11 12:14:27 +03:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-11 12:14:27 +03:00
|
|
|
|
|
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
|
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2023-06-11 12:14:27 +03:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
|
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-30 19:39:18 +05:30
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
mac80211: only set CSA beacon when at least one beacon must be transmitted
A beacon should never have a Channel Switch Announcement information
element with a count of 0, because a count of 1 means switch just
before the next beacon. So, if a count of 0 was valid in a beacon, it
would have been transmitted in the next channel already, which is
useless. A CSA count equal to zero is only meaningful in action
frames or probe_responses.
Fix the ieee80211_csa_is_complete() and ieee80211_update_csa()
functions accordingly.
With a CSA count of 0, we won't transmit any CSA beacons, because the
switch will happen before the next TBTT. To avoid extra work and
potential confusion in the drivers, complete the CSA immediately,
instead of waiting for the driver to call ieee80211_csa_finish().
To keep things simpler, we also switch immediately when the CSA count
is 1, while in theory we should delay the switch until just before the
next TBTT.
Additionally, move the ieee80211_csa_finish() function to cfg.c,
where it makes more sense.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-13 19:43:00 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
2024-01-30 19:39:18 +05:30
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2024-02-16 20:16:20 +05:30
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2024-02-16 20:16:20 +05:30
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-22 11:04:08 +05:30
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-22 11:04:08 +05:30
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
2022-09-02 16:12:47 +02:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-12 22:24:31 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
2012-11-29 13:00:10 +01:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
2014-06-12 22:24:31 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
2012-11-29 13:00:10 +01:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2012-06-09 10:31:09 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2016-04-12 15:56:15 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2011-07-07 18:58:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-20 15:06:41 +02:00
|
|
|
|
mac80211: fix TKIP races, make API easier to use
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.
Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.
To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.
Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.
Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 22:28:01 +02:00
|
|
|
|
2008-03-20 15:06:41 +02:00
|
|
|
|
mac80211: fix TKIP races, make API easier to use
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.
Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.
To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.
Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.
Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 22:28:01 +02:00
|
|
|
|
|
|
|
|
|
2008-03-20 15:06:41 +02:00
|
|
|
|
|
|
|
|
|
mac80211: fix TKIP races, make API easier to use
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.
Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.
To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.
Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.
Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 22:28:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-20 15:06:41 +02:00
|
|
|
|
2011-07-07 18:58:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: fix TKIP races, make API easier to use
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.
Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.
To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.
Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.
Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 22:28:01 +02:00
|
|
|
|
2011-07-13 19:50:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: fix TKIP races, make API easier to use
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.
Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.
To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.
Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.
Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 22:28:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-05 16:35:41 +02:00
|
|
|
|
2016-02-14 13:56:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-07 18:58:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-24 19:52:06 +02:00
|
|
|
|
2011-07-07 18:58:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-07 20:11:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-24 19:52:06 +02:00
|
|
|
|
2013-08-07 20:11:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-21 21:50:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 09:44:56 +01:00
|
|
|
|
2013-08-07 20:11:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2013-08-07 20:11:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-21 09:20:03 +03:00
|
|
|
|
2013-08-07 20:11:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-21 21:50:49 +03:00
|
|
|
|
2024-02-28 09:44:56 +01:00
|
|
|
|
2013-08-07 20:11:55 +02:00
|
|
|
|
2011-07-05 16:35:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-29 17:30:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-24 21:02:04 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
2008-07-24 21:02:04 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-26 13:30:26 +02:00
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
|
|
|
|
|
2016-07-05 15:23:12 +03:00
|
|
|
|
2007-09-18 17:29:20 -04:00
|
|
|
|
2016-07-05 15:23:12 +03:00
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
2011-05-11 17:09:36 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:15 +02:00
|
|
|
|
2020-09-22 12:19:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:15 +02:00
|
|
|
|
2020-09-22 12:19:56 -07:00
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-09 01:57:29 +01:00
|
|
|
|
2008-07-03 13:52:18 -07:00
|
|
|
|
2007-11-09 01:57:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-10 13:40:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
2007-11-09 01:57:29 +01:00
|
|
|
|
|
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
2008-05-10 13:40:49 +02:00
|
|
|
|
2007-11-09 01:57:29 +01:00
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-09 01:57:29 +01:00
|
|
|
|
2008-05-10 13:40:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
2008-05-10 13:40:49 +02:00
|
|
|
|
|
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
2008-05-10 13:40:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-06 20:23:30 +01:00
|
|
|
|
2008-05-10 13:40:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-08 14:34:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-21 22:07:20 +02:00
|
|
|
|
2021-01-22 16:19:43 +01:00
|
|
|
|
2013-08-21 22:07:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-05 13:28:29 -07:00
|
|
|
|
2013-08-21 22:07:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-08 14:34:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-21 22:07:20 +02:00
|
|
|
|
2014-10-22 12:30:59 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-05 17:40:23 -07:00
|
|
|
|
2026-01-08 14:34:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-05 17:40:23 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-08 14:34:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-05 17:40:23 -07:00
|
|
|
|
2009-07-29 20:08:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-18 01:50:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
2009-11-16 12:00:38 +01:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
2010-12-15 07:47:10 +05:30
|
|
|
|
2008-10-27 09:47:03 -07:00
|
|
|
|
|
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-15 07:47:10 +05:30
|
|
|
|
|
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-10 10:21:40 +02:00
|
|
|
|
|
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
2009-11-16 12:00:38 +01:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-16 12:00:38 +01:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
2008-10-27 09:47:03 -07:00
|
|
|
|
2010-05-27 14:41:07 +02:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-27 14:41:07 +02:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-10 10:21:40 +02:00
|
|
|
|
|
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
2009-11-16 12:00:38 +01:00
|
|
|
|
2008-01-28 14:07:15 +02:00
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
2008-09-11 00:02:02 +02:00
|
|
|
|
|
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
2010-09-23 09:44:36 -07:00
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
|
|
|
|
|
2010-09-23 09:44:36 -07:00
|
|
|
|
|
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
|
|
|
|
|
2010-09-23 09:44:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
2010-09-23 09:44:36 -07:00
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
2010-09-23 09:44:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-04 14:42:28 +01:00
|
|
|
|
2022-09-02 16:12:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 11:35:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-15 21:38:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:39 +02:00
|
|
|
|
2013-02-15 21:38:08 +01:00
|
|
|
|
2011-09-29 16:04:39 +02:00
|
|
|
|
2015-11-17 10:24:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:55 +02:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-07-24 11:54:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-05 16:35:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-11 09:05:21 +02:00
|
|
|
|
|
|
|
|
|
2011-07-05 16:35:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-11 09:05:21 +02:00
|
|
|
|
2011-07-13 19:50:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-05 16:35:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-17 10:24:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-11 17:57:42 +02:00
|
|
|
|
|
|
|
|
|
2019-10-25 10:36:47 +13:00
|
|
|
|
2012-09-11 17:57:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-13 17:42:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-11 17:57:42 +02:00
|
|
|
|
|
|
|
|
|
2025-02-12 08:22:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-11 17:57:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-11 08:50:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-11 08:50:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-22 21:57:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-23 13:15:45 +01:00
|
|
|
|
2009-03-22 21:57:35 +02:00
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
2010-03-19 07:14:53 +02:00
|
|
|
|
2009-03-22 21:57:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2010-03-19 07:14:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:57 +01:00
|
|
|
|
2010-03-19 07:14:53 +02:00
|
|
|
|
|
|
|
|
|
2013-01-29 13:13:50 +01:00
|
|
|
|
|
|
|
|
|
2010-03-19 07:14:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-06 14:54:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 12:30:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: Add interface for driver to temporarily disable dynamic ps
This mechanism introduced in this patch applies (at least) for hardware
designs using a single shared antenna for both WLAN and BT. In these designs,
the antenna must be toggled between WLAN and BT.
In those hardware, managing WLAN co-existence with Bluetooth requires WLAN
full power save whenever there is Bluetooth activity in order for WLAN to be
able to periodically relinquish the antenna to be used for BT. This is because
BT can only access the shared antenna when WLAN is idle or asleep.
Some hardware, for instance the wl1271, are able to indicate to the host
whenever there is BT traffic. In essence, the hardware will send an indication
to the host whenever there is, for example, SCO traffic or A2DP traffic, and
will send another indication when the traffic is over.
The hardware gets information of Bluetooth traffic via hardware co-existence
control lines - these lines are used to negotiate the shared antenna
ownership. The hardware will give the antenna to BT whenever WLAN is sleeping.
This patch adds the interface to mac80211 to facilitate temporarily disabling
of dynamic power save as per request of the WLAN driver. This interface will
immediately force WLAN to full powersave, hence allowing BT coexistence as
described above.
In these kind of shared antenna desings, when WLAN powersave is fully disabled,
Bluetooth will not work simultaneously with WLAN at all. This patch does not
address that problem. This interface will not change PSM state, so if PSM is
disabled it will remain so. Solving this problem requires knowledge about BT
state, and is best done in user-space.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-06-21 08:59:39 +03:00
|
|
|
|
2022-03-08 17:23:24 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-25 12:43:40 +01:00
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
|
|
|
|
|
2012-01-19 09:29:58 +01:00
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-25 12:43:40 +01:00
|
|
|
|
2010-03-23 09:02:34 +02:00
|
|
|
|
|
|
|
|
|
2014-11-26 12:42:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: handle ieee80211_radar_detected() for MLO
Currently DFS works under assumption there could be only one channel
context in the hardware. Hence, drivers just calls the function
ieee80211_radar_detected() passing the hardware structure. However, with
MLO, this obviously will not work since number of channel contexts will be
more than one and hence drivers would need to pass the channel information
as well on which the radar is detected.
Also, when radar is detected in one of the links, other link's CAC should
not be cancelled.
Hence, in order to support DFS with MLO, do the following changes -
* Add channel context conf pointer as an argument to the function
ieee80211_radar_detected(). During MLO, drivers would have to pass on
which channel context conf radar is detected. Otherwise, drivers could
just pass NULL.
* ieee80211_radar_detected() will iterate over all channel contexts
present and
* if channel context conf is passed, only mark that as radar
detected
* if NULL is passed, then mark all channel contexts as radar
detected
* Then as usual, schedule the radar detected work.
* In the worker, go over all the contexts again and for all such context
which is marked with radar detected, cancel the ongoing CAC by calling
ieee80211_dfs_cac_cancel() and then notify cfg80211 via
cfg80211_radar_event().
* To cancel the CAC, pass the channel context as well where radar is
detected to ieee80211_dfs_cac_cancel(). This ensures that CAC is
canceled only on the links using the provided context, leaving other
links unaffected.
This would also help in scenarios where there is split phy 5 GHz radio,
which is capable of DFS channels in both lower and upper band. In this
case, simultaneous radars can be detected.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://patch.msgid.link/20240906064426.2101315-9-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-09-06 12:14:26 +05:30
|
|
|
|
|
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
wifi: mac80211: handle ieee80211_radar_detected() for MLO
Currently DFS works under assumption there could be only one channel
context in the hardware. Hence, drivers just calls the function
ieee80211_radar_detected() passing the hardware structure. However, with
MLO, this obviously will not work since number of channel contexts will be
more than one and hence drivers would need to pass the channel information
as well on which the radar is detected.
Also, when radar is detected in one of the links, other link's CAC should
not be cancelled.
Hence, in order to support DFS with MLO, do the following changes -
* Add channel context conf pointer as an argument to the function
ieee80211_radar_detected(). During MLO, drivers would have to pass on
which channel context conf radar is detected. Otherwise, drivers could
just pass NULL.
* ieee80211_radar_detected() will iterate over all channel contexts
present and
* if channel context conf is passed, only mark that as radar
detected
* if NULL is passed, then mark all channel contexts as radar
detected
* Then as usual, schedule the radar detected work.
* In the worker, go over all the contexts again and for all such context
which is marked with radar detected, cancel the ongoing CAC by calling
ieee80211_dfs_cac_cancel() and then notify cfg80211 via
cfg80211_radar_event().
* To cancel the CAC, pass the channel context as well where radar is
detected to ieee80211_dfs_cac_cancel(). This ensures that CAC is
canceled only on the links using the provided context, leaving other
links unaffected.
This would also help in scenarios where there is split phy 5 GHz radio,
which is capable of DFS channels in both lower and upper band. In this
case, simultaneous radars can be detected.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://patch.msgid.link/20240906064426.2101315-9-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-09-06 12:14:26 +05:30
|
|
|
|
|
|
|
|
|
2013-02-08 18:16:20 +01:00
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-28 13:04:10 +03:00
|
|
|
|
|
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-28 13:04:10 +03:00
|
|
|
|
|
|
|
|
|
2010-05-11 16:20:57 +02:00
|
|
|
|
2021-11-29 15:32:38 +02:00
|
|
|
|
|
|
|
|
|
2022-06-28 10:46:06 +01:00
|
|
|
|
2021-11-29 15:32:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-19 17:35:40 +02:00
|
|
|
|
2021-11-29 15:32:38 +02:00
|
|
|
|
2010-08-05 17:05:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-30 23:45:04 +02:00
|
|
|
|
2010-08-18 15:01:23 +02:00
|
|
|
|
2010-08-05 17:05:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-30 23:45:04 +02:00
|
|
|
|
2010-08-05 17:05:55 +02:00
|
|
|
|
|
|
|
|
|
2010-12-18 17:20:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-22 16:10:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-28 16:19:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-18 09:40:04 +08:00
|
|
|
|
2016-01-28 16:19:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-20 15:53:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-18 15:33:56 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-30 16:34:46 +02:00
|
|
|
|
2017-08-18 15:33:56 +03:00
|
|
|
|
2017-05-30 16:34:46 +02:00
|
|
|
|
2014-07-16 12:12:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-30 16:34:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-16 12:12:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-30 16:34:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-16 12:12:15 +02:00
|
|
|
|
2017-07-11 10:07:25 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-07 21:31:13 +01:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-07 21:31:13 +01:00
|
|
|
|
2013-04-16 13:38:42 +02:00
|
|
|
|
2010-11-11 15:07:23 +01:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-06 13:09:08 +02:00
|
|
|
|
2013-04-16 13:38:42 +02:00
|
|
|
|
2010-11-11 15:07:23 +01:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:17 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:17 +03:00
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2018-08-31 11:31:17 +03:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2020-04-23 11:13:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-08 16:55:50 +02:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2009-02-12 11:38:37 +05:30
|
|
|
|
2013-07-08 16:55:50 +02:00
|
|
|
|
2012-03-28 10:58:37 +02:00
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-26 17:11:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-19 21:53:20 +02:00
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-12 15:56:15 +02:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-04 18:07:43 +01:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2011-11-04 18:07:43 +01:00
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-16 10:15:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-20 23:29:34 +01:00
|
|
|
|
|
|
|
|
|
2008-09-18 18:14:18 +02:00
|
|
|
|
2008-12-23 15:58:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 16:26:57 +01:00
|
|
|
|
2008-12-23 15:58:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 16:26:57 +01:00
|
|
|
|
|
|
|
|
|
2008-12-23 15:58:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 16:26:57 +01:00
|
|
|
|
|
|
|
|
|
2008-12-23 15:58:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 16:26:57 +01:00
|
|
|
|
2008-12-23 15:58:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-02 15:31:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-23 15:58:36 -08:00
|
|
|
|
|
|
|
|
|
2010-09-16 14:58:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: add helpers to access sband iftype data
There's quite a bit of code accessing sband iftype data
(HE, HE 6 GHz, EHT) and we always need to remember to use
the ieee80211_vif_type_p2p() helper. Add new helpers to
directly get it from the sband/vif rather than having to
call ieee80211_vif_type_p2p().
Convert most code with the following spatch:
@@
expression vif, sband;
@@
-ieee80211_get_he_iftype_cap(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_he_iftype_cap_vif(sband, vif)
@@
expression vif, sband;
@@
-ieee80211_get_eht_iftype_cap(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_eht_iftype_cap_vif(sband, vif)
@@
expression vif, sband;
@@
-ieee80211_get_he_6ghz_capa(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_he_6ghz_capa_vif(sband, vif)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230604120651.db099f49e764.Ie892966c49e22c7b7ee1073bc684f142debfdc84@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-06-04 12:11:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-05 15:39:58 +01:00
|
|
|
|
wifi: mac80211: add helpers to access sband iftype data
There's quite a bit of code accessing sband iftype data
(HE, HE 6 GHz, EHT) and we always need to remember to use
the ieee80211_vif_type_p2p() helper. Add new helpers to
directly get it from the sband/vif rather than having to
call ieee80211_vif_type_p2p().
Convert most code with the following spatch:
@@
expression vif, sband;
@@
-ieee80211_get_he_iftype_cap(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_he_iftype_cap_vif(sband, vif)
@@
expression vif, sband;
@@
-ieee80211_get_eht_iftype_cap(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_eht_iftype_cap_vif(sband, vif)
@@
expression vif, sband;
@@
-ieee80211_get_he_6ghz_capa(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_he_6ghz_capa_vif(sband, vif)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230604120651.db099f49e764.Ie892966c49e22c7b7ee1073bc684f142debfdc84@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-06-04 12:11:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-30 16:21:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-16 12:48:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-30 23:22:19 +02:00
|
|
|
|
2016-02-16 12:48:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-30 23:22:19 +02:00
|
|
|
|
2016-02-16 12:48:17 +02:00
|
|
|
|
|
|
|
|
|
2011-07-08 08:46:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-28 14:12:51 +03:00
|
|
|
|
2012-04-20 11:57:00 -07:00
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
2012-04-20 11:57:00 -07:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: add support towards MLO handling of station statistics
Currently, in supporting API's to fill sinfo structure from sta
structure, is mapped to fill the fields from sta->deflink. However,
for multi-link (ML) station, sinfo structure should be filled from
corresponding link_id.
Therefore, add link_id as an additional argument in supporting API's
for filling sinfo structure correctly. Link_id is set to -1 for non-ML
station and corresponding link_id for ML stations. In supporting API's
for filling sinfo structure, check for link_id, if link_id < 0, fill
the sinfo structure from sta->deflink, otherwise fill from
sta->link[link_id].
Current, changes are done at the deflink level i.e, pass -1 as link_id.
Actual link_id will be added in subsequent patches to support
station statistics for MLO.
Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com>
Link: https://patch.msgid.link/20250528054420.3050133-2-quic_sarishar@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-28 11:14:11 +05:30
|
|
|
|
2012-04-20 11:57:00 -07:00
|
|
|
|
2013-01-12 13:54:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 11:57:00 -07:00
|
|
|
|
wifi: mac80211: add support towards MLO handling of station statistics
Currently, in supporting API's to fill sinfo structure from sta
structure, is mapped to fill the fields from sta->deflink. However,
for multi-link (ML) station, sinfo structure should be filled from
corresponding link_id.
Therefore, add link_id as an additional argument in supporting API's
for filling sinfo structure correctly. Link_id is set to -1 for non-ML
station and corresponding link_id for ML stations. In supporting API's
for filling sinfo structure, check for link_id, if link_id < 0, fill
the sinfo structure from sta->deflink, otherwise fill from
sta->link[link_id].
Current, changes are done at the deflink level i.e, pass -1 as link_id.
Actual link_id will be added in subsequent patches to support
station statistics for MLO.
Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com>
Link: https://patch.msgid.link/20250528054420.3050133-2-quic_sarishar@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-28 11:14:11 +05:30
|
|
|
|
2012-04-13 12:02:57 -07:00
|
|
|
|
2026-03-26 12:14:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-22 12:34:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-14 18:01:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-14 06:54:55 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
2013-10-14 18:01:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
2020-10-23 18:33:08 +02:00
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
|
|
|
|
|
2026-09-08 14:28:12 +02:00
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
|
|
|
|
|
2026-09-08 14:28:12 +02:00
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
2013-12-16 21:49:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-11 17:18:25 +03:00
|
|
|
|
2020-10-23 18:33:08 +02:00
|
|
|
|
2014-06-11 17:18:25 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-22 15:22:49 +03:00
|
|
|
|
2014-11-19 13:47:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
2018-12-15 11:03:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-15 09:43:24 -07:00
|
|
|
|
2018-12-15 11:03:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-17 22:01:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-27 15:26:12 +01:00
|
|
|
|
2019-06-17 22:01:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2019-06-17 22:01:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-22 15:20:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-18 12:00:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-22 15:20:16 +01:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-18 12:00:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-22 15:20:16 +01:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-01 12:16:32 -07:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-25 10:36:47 +13:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-27 15:26:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:20 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-20 17:31:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-26 12:14:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-05-04 10:20:41 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-05-04 10:20:47 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-18 22:06:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2019-11-18 22:06:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2019-11-18 22:06:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-20 01:12:41 +05:30
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-20 01:12:41 +05:30
|
|
|
|
|
|
|
|
|
2020-09-11 00:33:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-20 01:12:42 +05:30
|
|
|
|
2020-09-11 00:33:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-20 01:12:42 +05:30
|
|
|
|
|
|
|
|
|
2021-05-19 14:20:17 +02:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
2023-01-19 14:57:11 +01:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
2024-04-22 11:04:08 +05:30
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:57:11 +01:00
|
|
|
|
2024-04-22 11:04:08 +05:30
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
2021-05-19 14:20:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2021-05-19 14:20:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-11 09:05:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-11 09:05:21 +02:00
|
|
|
|
2022-09-02 16:12:56 +02:00
|
|
|
|
|
|
|
|
|
2024-11-01 16:21:43 +08:00
|
|
|
|
2022-09-02 16:12:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-29 13:27:18 -07:00
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-18 18:53:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-07 15:00:58 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-01 07:05:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-29 19:34:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-08 14:13:06 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO
Per IEEE Std 802.11be-2024, 12.5.2.3.3, if the MPDU is an
individually addressed Data frame between an AP MLD and a
non-AP MLD associated with the AP MLD, then A1/A2/A3
will be MLD MAC addresses. Otherwise, Al/A2/A3 will be
over-the-air link MAC addresses.
Currently, during AAD and Nonce computation for software based
encryption/decryption cases, mac80211 directly uses the addresses it
receives in the skb frame header. However, after the first
authentication, management frame addresses for non-AP MLD stations
are translated to MLD addresses from over the air link addresses in
software. This means that the skb header could contain translated MLD
addresses, which when used as is, can lead to incorrect AAD/Nonce
computation.
In the following manner, ensure that the right set of addresses are used:
In the receive path, stash the pre-translated link addresses in
ieee80211_rx_data and use them for the AAD/Nonce computations
when required.
In the transmit path, offload the encryption for a CCMP/GCMP key
to the hwsim driver that can then ensure that encryption and hence
the AAD/Nonce computations are performed on the frame containing the
right set of addresses, i.e, MLD addresses if unicast data frame and
link addresses otherwise.
To do so, register the set key handler in hwsim driver so mac80211 is
aware that it is the driver that would take care of encrypting the
frame. Offload encryption for a CCMP/GCMP key, while keeping the
encryption for WEP/TKIP and MMIE generation for a AES_CMAC or a
AES_GMAC key still at the SW crypto in mac layer
Co-developed-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260226042959.3766157-1-sai.magam@oss.qualcomm.com
[only store and apply link_addrs for unicast non-data
rather storing always and applying for !unicast_data]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-02-26 09:59:59 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 11:45:53 -07:00
|
|
|
|
