2019-06-04 10:11:33 +02:00
// SPDX-License-Identifier: GPL-2.0-only
2008-09-09 14:49:03 +02:00
/*
* spectrum management
*
* Copyright 2003 , Jouni Malinen < jkmaline @ cc . hut . fi >
* Copyright 2002 - 2005 , Instant802 Networks , Inc .
* Copyright 2005 - 2006 , Devicescape Software , Inc .
* Copyright 2006 - 2007 Jiri Benc < jbenc @ suse . cz >
* Copyright 2007 , Michael Wu < flamingice @ sourmilk . net >
* Copyright 2007 - 2008 , Intel Corporation
* Copyright 2008 , Johannes Berg < johannes @ sipsolutions . net >
2023-09-20 21:25:12 +03:00
* Copyright ( C ) 2018 , 2020 , 2022 - 2023 Intel Corporation
2008-09-09 14:49:03 +02:00
*/
# include <linux/ieee80211.h>
2009-04-20 14:31:42 +02:00
# include <net/cfg80211.h>
2008-09-09 14:49:03 +02:00
# include <net/mac80211.h>
# include "ieee80211_i.h"
# include "sta_info.h"
# include "wme.h"
2013-08-28 13:41:29 +02:00
int ieee80211_parse_ch_switch_ie ( struct ieee80211_sub_if_data * sdata ,
2014-10-28 13:33:04 +02:00
struct ieee802_11_elems * elems ,
2016-04-12 15:56:15 +02:00
enum nl80211_band current_band ,
2020-05-28 21:34:35 +02:00
u32 vht_cap_info ,
2024-01-29 19:34:36 +01:00
struct ieee80211_conn_settings * conn ,
u8 * bssid ,
2013-10-14 19:08:29 -07:00
struct ieee80211_csa_ie * csa_ie )
2013-08-28 13:41:29 +02:00
{
2018-02-19 14:48:42 +02:00
enum nl80211_band new_band = current_band ;
2013-08-28 13:41:29 +02:00
int new_freq ;
u8 new_chan_no ;
struct ieee80211_channel * new_chan ;
struct cfg80211_chan_def new_vht_chandef = { } ;
const struct ieee80211_sec_chan_offs_ie * sec_chan_offs ;
const struct ieee80211_wide_bw_chansw_ie * wide_bw_chansw_ie ;
2023-09-20 21:25:12 +03:00
const struct ieee80211_bandwidth_indication * bwi ;
2013-08-28 13:41:29 +02:00
int secondary_channel_offset = - 1 ;
2017-05-19 13:22:38 +02:00
memset ( csa_ie , 0 , sizeof ( * csa_ie ) ) ;
2013-08-28 13:41:29 +02:00
sec_chan_offs = elems - > sec_chan_offs ;
wide_bw_chansw_ie = elems - > wide_bw_chansw_ie ;
2023-09-20 21:25:12 +03:00
bwi = elems - > bandwidth_indication ;
2013-08-28 13:41:29 +02:00
2024-01-29 19:34:36 +01:00
if ( conn - > mode < IEEE80211_CONN_MODE_HT | |
conn - > bw_limit < IEEE80211_CONN_BW_LIMIT_40 ) {
2013-08-28 13:41:29 +02:00
sec_chan_offs = NULL ;
wide_bw_chansw_ie = NULL ;
}
2024-01-29 19:34:36 +01:00
if ( conn - > mode < IEEE80211_CONN_MODE_VHT )
2013-08-28 13:41:29 +02:00
wide_bw_chansw_ie = NULL ;
if ( elems - > ext_chansw_ie ) {
if ( ! ieee80211_operating_class_to_band (
elems - > ext_chansw_ie - > new_operating_class ,
& new_band ) ) {
sdata_info ( sdata ,
2018-02-19 14:48:42 +02:00
" cannot understand ECSA IE operating class, %d, ignoring \n " ,
2013-08-28 13:41:29 +02:00
elems - > ext_chansw_ie - > new_operating_class ) ;
}
new_chan_no = elems - > ext_chansw_ie - > new_ch_num ;
2013-10-14 19:08:29 -07:00
csa_ie - > count = elems - > ext_chansw_ie - > count ;
csa_ie - > mode = elems - > ext_chansw_ie - > mode ;
2013-08-28 13:41:29 +02:00
} else if ( elems - > ch_switch_ie ) {
new_chan_no = elems - > ch_switch_ie - > new_ch_num ;
2013-10-14 19:08:29 -07:00
csa_ie - > count = elems - > ch_switch_ie - > count ;
csa_ie - > mode = elems - > ch_switch_ie - > mode ;
2013-08-28 13:41:29 +02:00
} else {
/* nothing here we understand */
return 1 ;
}
2013-10-17 15:55:18 -07:00
/* Mesh Channel Switch Parameters Element */
if ( elems - > mesh_chansw_params_ie ) {
csa_ie - > ttl = elems - > mesh_chansw_params_ie - > mesh_ttl ;
csa_ie - > mode = elems - > mesh_chansw_params_ie - > mesh_flags ;
2013-11-08 15:09:43 +08:00
csa_ie - > pre_value = le16_to_cpu (
elems - > mesh_chansw_params_ie - > mesh_pre_value ) ;
2017-05-16 11:23:10 +02:00
if ( elems - > mesh_chansw_params_ie - > mesh_flags &
WLAN_EID_CHAN_SWITCH_PARAM_REASON )
csa_ie - > reason_code = le16_to_cpu (
elems - > mesh_chansw_params_ie - > mesh_reason ) ;
2013-10-17 15:55:18 -07:00
}
2013-08-28 13:41:29 +02:00
new_freq = ieee80211_channel_to_frequency ( new_chan_no , new_band ) ;
new_chan = ieee80211_get_channel ( sdata - > local - > hw . wiphy , new_freq ) ;
if ( ! new_chan | | new_chan - > flags & IEEE80211_CHAN_DISABLED ) {
sdata_info ( sdata ,
" BSS %pM switches to unsupported channel (%d MHz), disconnecting \n " ,
bssid , new_freq ) ;
return - EINVAL ;
}
2014-10-28 13:33:04 +02:00
if ( sec_chan_offs ) {
2013-08-28 13:41:29 +02:00
secondary_channel_offset = sec_chan_offs - > sec_chan_offs ;
2024-01-29 19:34:36 +01:00
} else if ( conn - > mode > = IEEE80211_CONN_MODE_HT ) {
2014-10-28 13:33:04 +02:00
/* If the secondary channel offset IE is not present,
* we can ' t know what ' s the post - CSA offset , so the
* best we can do is use 20 MHz .
*/
2013-08-28 13:41:29 +02:00
secondary_channel_offset = IEEE80211_HT_PARAM_CHA_SEC_NONE ;
}
switch ( secondary_channel_offset ) {
default :
/* secondary_channel_offset was present but is invalid */
case IEEE80211_HT_PARAM_CHA_SEC_NONE :
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
cfg80211_chandef_create ( & csa_ie - > chanreq . oper , new_chan ,
2013-08-28 13:41:29 +02:00
NL80211_CHAN_HT20 ) ;
break ;
case IEEE80211_HT_PARAM_CHA_SEC_ABOVE :
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
cfg80211_chandef_create ( & csa_ie - > chanreq . oper , new_chan ,
2013-08-28 13:41:29 +02:00
NL80211_CHAN_HT40PLUS ) ;
break ;
case IEEE80211_HT_PARAM_CHA_SEC_BELOW :
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
cfg80211_chandef_create ( & csa_ie - > chanreq . oper , new_chan ,
2013-08-28 13:41:29 +02:00
NL80211_CHAN_HT40MINUS ) ;
break ;
case - 1 :
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
cfg80211_chandef_create ( & csa_ie - > chanreq . oper , new_chan ,
2013-08-28 13:41:29 +02:00
NL80211_CHAN_NO_HT ) ;
/* keep width for 5/10 MHz channels */
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
switch ( sdata - > vif . bss_conf . chanreq . oper . width ) {
2013-08-28 13:41:29 +02:00
case NL80211_CHAN_WIDTH_5 :
case NL80211_CHAN_WIDTH_10 :
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
csa_ie - > chanreq . oper . width =
sdata - > vif . bss_conf . chanreq . oper . width ;
2013-08-28 13:41:29 +02:00
break ;
default :
break ;
}
break ;
}
2023-09-20 21:25:12 +03:00
if ( bwi ) {
/* start with the CSA one */
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
new_vht_chandef = csa_ie - > chanreq . oper ;
2023-09-20 21:25:12 +03:00
/* and update the width accordingly */
2024-01-29 19:34:37 +01:00
ieee80211_chandef_eht_oper ( & bwi - > info , & new_vht_chandef ) ;
2023-09-20 21:25:12 +03:00
} else if ( wide_bw_chansw_ie ) {
2020-12-22 08:47:14 +02:00
u8 new_seg1 = wide_bw_chansw_ie - > new_center_freq_seg1 ;
2016-07-05 15:23:14 +03:00
struct ieee80211_vht_operation vht_oper = {
. chan_width =
wide_bw_chansw_ie - > new_channel_width ,
2017-02-15 15:02:06 +01:00
. center_freq_seg0_idx =
2013-08-28 13:41:29 +02:00
wide_bw_chansw_ie - > new_center_freq_seg0 ,
2020-12-22 08:47:14 +02:00
. center_freq_seg1_idx = new_seg1 ,
2016-07-05 15:23:14 +03:00
/* .basic_mcs_set doesn't matter */
} ;
2020-12-22 08:47:14 +02:00
struct ieee80211_ht_operation ht_oper = {
. operation_mode =
cpu_to_le16 ( new_seg1 < <
IEEE80211_HT_OP_MODE_CCFS2_SHIFT ) ,
} ;
2013-08-28 13:41:29 +02:00
2016-07-05 15:23:14 +03:00
/* default, for the case of IEEE80211_VHT_CHANWIDTH_USE_HT,
* to the previously parsed chandef
*/
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
new_vht_chandef = csa_ie - > chanreq . oper ;
2016-07-05 15:23:14 +03:00
/* ignore if parsing fails */
2018-08-31 11:31:18 +03:00
if ( ! ieee80211_chandef_vht_oper ( & sdata - > local - > hw ,
2020-05-28 21:34:35 +02:00
vht_cap_info ,
2018-08-31 11:31:18 +03:00
& vht_oper , & ht_oper ,
& new_vht_chandef ) )
2013-08-28 13:41:29 +02:00
new_vht_chandef . chan = NULL ;
2016-07-05 15:23:14 +03:00
2024-01-29 19:34:36 +01:00
if ( conn - > bw_limit < IEEE80211_CONN_BW_LIMIT_160 & &
( new_vht_chandef . width = = NL80211_CHAN_WIDTH_80P80 | |
new_vht_chandef . width = = NL80211_CHAN_WIDTH_160 ) )
ieee80211_chandef_downgrade ( & new_vht_chandef , NULL ) ;
2013-08-28 13:41:29 +02:00
}
/* if VHT data is there validate & use it */
if ( new_vht_chandef . chan ) {
if ( ! cfg80211_chandef_compatible ( & new_vht_chandef ,
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
& csa_ie - > chanreq . oper ) ) {
2013-08-28 13:41:29 +02:00
sdata_info ( sdata ,
" BSS %pM: CSA has inconsistent channel data, disconnecting \n " ,
bssid ) ;
return - EINVAL ;
}
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
csa_ie - > chanreq . oper = new_vht_chandef ;
2013-08-28 13:41:29 +02:00
}
2019-02-06 13:17:09 +02:00
if ( elems - > max_channel_switch_time )
csa_ie - > max_switch_time =
( elems - > max_channel_switch_time [ 0 ] < < 0 ) |
( elems - > max_channel_switch_time [ 1 ] < < 8 ) |
( elems - > max_channel_switch_time [ 2 ] < < 16 ) ;
2013-08-28 13:41:29 +02:00
return 0 ;
}
2008-09-09 14:49:03 +02:00
static void ieee80211_send_refuse_measurement_request ( struct ieee80211_sub_if_data * sdata ,
struct ieee80211_msrment_ie * request_ie ,
const u8 * da , const u8 * bssid ,
u8 dialog_token )
{
struct ieee80211_local * local = sdata - > local ;
struct sk_buff * skb ;
struct ieee80211_mgmt * msr_report ;
skb = dev_alloc_skb ( sizeof ( * msr_report ) + local - > hw . extra_tx_headroom +
sizeof ( struct ieee80211_msrment_ie ) ) ;
2011-08-29 14:17:31 -07:00
if ( ! skb )
2008-09-09 14:49:03 +02:00
return ;
skb_reserve ( skb , local - > hw . extra_tx_headroom ) ;
networking: convert many more places to skb_put_zero()
There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.
The following spatch found many more and also removes the
now unnecessary casts:
@@
identifier p, p2;
expression len;
expression skb;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_zero(skb, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_zero(skb, len);
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, len);
|
-memset(p, 0, len);
)
@@
type t, t2;
identifier p, p2;
expression skb;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, sizeof(*p));
|
-memset(p, 0, sizeof(*p));
)
@@
expression skb, len;
@@
-memset(skb_put(skb, len), 0, len);
+skb_put_zero(skb, len);
Apply it to the tree (with one manual fixup to keep the
comment in vxlan.c, which spatch removed.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:19 +02:00
msr_report = skb_put_zero ( skb , 24 ) ;
2008-09-09 14:49:03 +02:00
memcpy ( msr_report - > da , da , ETH_ALEN ) ;
2009-11-25 17:46:19 +01:00
memcpy ( msr_report - > sa , sdata - > vif . addr , ETH_ALEN ) ;
2008-09-09 14:49:03 +02:00
memcpy ( msr_report - > bssid , bssid , ETH_ALEN ) ;
msr_report - > frame_control = cpu_to_le16 ( IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION ) ;
skb_put ( skb , 1 + sizeof ( msr_report - > u . action . u . measurement ) ) ;
msr_report - > u . action . category = WLAN_CATEGORY_SPECTRUM_MGMT ;
msr_report - > u . action . u . measurement . action_code =
WLAN_ACTION_SPCT_MSR_RPRT ;
msr_report - > u . action . u . measurement . dialog_token = dialog_token ;
msr_report - > u . action . u . measurement . element_id = WLAN_EID_MEASURE_REPORT ;
msr_report - > u . action . u . measurement . length =
sizeof ( struct ieee80211_msrment_ie ) ;
memset ( & msr_report - > u . action . u . measurement . msr_elem , 0 ,
sizeof ( struct ieee80211_msrment_ie ) ) ;
msr_report - > u . action . u . measurement . msr_elem . token = request_ie - > token ;
msr_report - > u . action . u . measurement . msr_elem . mode | =
IEEE80211_SPCT_MSR_RPRT_MODE_REFUSED ;
msr_report - > u . action . u . measurement . msr_elem . type = request_ie - > type ;
2009-11-18 18:42:05 +01:00
ieee80211_tx_skb ( sdata , skb ) ;
2008-09-09 14:49:03 +02:00
}
void ieee80211_process_measurement_req ( struct ieee80211_sub_if_data * sdata ,
struct ieee80211_mgmt * mgmt ,
size_t len )
{
/*
* Ignoring measurement request is spec violation .
* Mandatory measurements must be reported optional
* measurements might be refused or reported incapable
* For now just refuse
* TODO : Answer basic measurement as unmeasured
*/
ieee80211_send_refuse_measurement_request ( sdata ,
& mgmt - > u . action . u . measurement . msr_elem ,
mgmt - > sa , mgmt - > bssid ,
mgmt - > u . action . u . measurement . dialog_token ) ;
}