From: Rafał Miłecki Date: Thu, 2 Feb 2017 08:39:31 +0000 (+0100) Subject: mac80211: rename brcmfmac patches to use higher prefix X-Git-Tag: v17.01.0-rc2~18 X-Git-Url: http://git.lede-project.org./?a=commitdiff_plain;h=e8f42223bef01e08a04f7a1e5c1deeb0d3bf1d01;p=openwrt%2Fstaging%2Fxback.git mac80211: rename brcmfmac patches to use higher prefix There are more patches to backport that should go before these. Signed-off-by: Rafał Miłecki --- diff --git a/package/kernel/mac80211/patches/353-0001-brcmfmac-avoid-writing-channel-out-of-allocated-arra.patch b/package/kernel/mac80211/patches/353-0001-brcmfmac-avoid-writing-channel-out-of-allocated-arra.patch deleted file mode 100644 index 710979a738..0000000000 --- a/package/kernel/mac80211/patches/353-0001-brcmfmac-avoid-writing-channel-out-of-allocated-arra.patch +++ /dev/null @@ -1,101 +0,0 @@ -From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= -Date: Wed, 4 Jan 2017 12:09:41 +0100 -Subject: [PATCH] brcmfmac: avoid writing channel out of allocated array -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -Our code was assigning number of channels to the index variable by -default. If firmware reported channel we didn't predict this would -result in using that initial index value and writing out of array. This -never happened so far (we got a complete list of supported channels) but -it means possible memory corruption so we should handle it anyway. - -This patch simply detects unexpected channel and ignores it. - -As we don't try to create new entry now, it's also safe to drop hw_value -and center_freq assignment. For known channels we have these set anyway. - -I decided to fix this issue by assigning NULL or a target channel to the -channel variable. This was one of possible ways, I prefefred this one as -it also avoids using channel[index] over and over. - -Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy bands") -Signed-off-by: Rafał Miłecki -Acked-by: Arend van Spriel -Signed-off-by: Kalle Valo ---- - ---- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c -+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c -@@ -5913,7 +5913,6 @@ static int brcmf_construct_chaninfo(stru - u32 i, j; - u32 total; - u32 chaninfo; -- u32 index; - - pbuf = kzalloc(BRCMF_DCMD_MEDLEN, GFP_KERNEL); - -@@ -5961,33 +5960,36 @@ static int brcmf_construct_chaninfo(stru - ch.bw == BRCMU_CHAN_BW_80) - continue; - -- channel = band->channels; -- index = band->n_channels; -+ channel = NULL; - for (j = 0; j < band->n_channels; j++) { -- if (channel[j].hw_value == ch.control_ch_num) { -- index = j; -+ if (band->channels[j].hw_value == ch.control_ch_num) { -+ channel = &band->channels[j]; - break; - } - } -- channel[index].center_freq = -- ieee80211_channel_to_frequency(ch.control_ch_num, -- band->band); -- channel[index].hw_value = ch.control_ch_num; -+ if (!channel) { -+ /* It seems firmware supports some channel we never -+ * considered. Something new in IEEE standard? -+ */ -+ brcmf_err("Ignoring unexpected firmware channel %d\n", -+ ch.control_ch_num); -+ continue; -+ } - - /* assuming the chanspecs order is HT20, - * HT40 upper, HT40 lower, and VHT80. - */ - if (ch.bw == BRCMU_CHAN_BW_80) { -- channel[index].flags &= ~IEEE80211_CHAN_NO_80MHZ; -+ channel->flags &= ~IEEE80211_CHAN_NO_80MHZ; - } else if (ch.bw == BRCMU_CHAN_BW_40) { -- brcmf_update_bw40_channel_flag(&channel[index], &ch); -+ brcmf_update_bw40_channel_flag(channel, &ch); - } else { - /* enable the channel and disable other bandwidths - * for now as mentioned order assure they are enabled - * for subsequent chanspecs. - */ -- channel[index].flags = IEEE80211_CHAN_NO_HT40 | -- IEEE80211_CHAN_NO_80MHZ; -+ channel->flags = IEEE80211_CHAN_NO_HT40 | -+ IEEE80211_CHAN_NO_80MHZ; - ch.bw = BRCMU_CHAN_BW_20; - cfg->d11inf.encchspec(&ch); - chaninfo = ch.chspec; -@@ -5995,11 +5997,11 @@ static int brcmf_construct_chaninfo(stru - &chaninfo); - if (!err) { - if (chaninfo & WL_CHAN_RADAR) -- channel[index].flags |= -+ channel->flags |= - (IEEE80211_CHAN_RADAR | - IEEE80211_CHAN_NO_IR); - if (chaninfo & WL_CHAN_PASSIVE) -- channel[index].flags |= -+ channel->flags |= - IEEE80211_CHAN_NO_IR; - } - } diff --git a/package/kernel/mac80211/patches/353-0002-brcmfmac-don-t-preset-all-channels-as-disabled.patch b/package/kernel/mac80211/patches/353-0002-brcmfmac-don-t-preset-all-channels-as-disabled.patch deleted file mode 100644 index dbe45642f3..0000000000 --- a/package/kernel/mac80211/patches/353-0002-brcmfmac-don-t-preset-all-channels-as-disabled.patch +++ /dev/null @@ -1,35 +0,0 @@ -From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= -Date: Sat, 7 Jan 2017 21:36:04 +0100 -Subject: [PATCH] brcmfmac: don't preset all channels as disabled -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -During init we take care of regulatory stuff by disabling all -unavailable channels (see brcmf_construct_chaninfo) so this predisabling -them is not really required (and this patch won't change any behavior). -It will on the other hand allow more detailed runtime control over -channels which is the main reason for this change. - -Signed-off-by: Rafał Miłecki -Signed-off-by: Kalle Valo ---- - ---- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c -+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c -@@ -147,7 +147,6 @@ static struct ieee80211_rate __wl_rates[ - .band = NL80211_BAND_2GHZ, \ - .center_freq = (_freq), \ - .hw_value = (_channel), \ -- .flags = IEEE80211_CHAN_DISABLED, \ - .max_antenna_gain = 0, \ - .max_power = 30, \ - } -@@ -156,7 +155,6 @@ static struct ieee80211_rate __wl_rates[ - .band = NL80211_BAND_5GHZ, \ - .center_freq = 5000 + (5 * (_channel)), \ - .hw_value = (_channel), \ -- .flags = IEEE80211_CHAN_DISABLED, \ - .max_antenna_gain = 0, \ - .max_power = 30, \ - } diff --git a/package/kernel/mac80211/patches/353-0003-brcmfmac-setup-wiphy-bands-after-registering-it-firs.patch b/package/kernel/mac80211/patches/353-0003-brcmfmac-setup-wiphy-bands-after-registering-it-firs.patch deleted file mode 100644 index d7aa7e9558..0000000000 --- a/package/kernel/mac80211/patches/353-0003-brcmfmac-setup-wiphy-bands-after-registering-it-firs.patch +++ /dev/null @@ -1,50 +0,0 @@ -From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= -Date: Sat, 7 Jan 2017 21:36:05 +0100 -Subject: [PATCH] brcmfmac: setup wiphy bands after registering it first -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -During bands setup we disable all channels that firmware doesn't support -in the current regulatory setup. If we do this before wiphy_register -it will result in copying set flags (including IEEE80211_CHAN_DISABLED) -to the orig_flags which is supposed to be persistent. We don't want this -as regulatory change may result in enabling some channels. We shouldn't -mess with orig_flags then (by changing them or ignoring them) so it's -better to just take care of their proper values. - -This patch cleanups code a bit (by taking orig_flags more seriously) and -allows further improvements like disabling really unavailable channels. -We will need that e.g. if some frequencies should be disabled for good -due to hardware setup (design). - -Signed-off-by: Rafał Miłecki -Acked-by: Arend van Spriel -Signed-off-by: Kalle Valo ---- - ---- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c -+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c -@@ -6564,8 +6564,7 @@ static int brcmf_setup_wiphy(struct wiph - wiphy->bands[NL80211_BAND_5GHZ] = band; - } - } -- err = brcmf_setup_wiphybands(wiphy); -- return err; -+ return 0; - } - - static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg) -@@ -6930,6 +6929,12 @@ struct brcmf_cfg80211_info *brcmf_cfg802 - goto priv_out; - } - -+ err = brcmf_setup_wiphybands(wiphy); -+ if (err) { -+ brcmf_err("Setting wiphy bands failed (%d)\n", err); -+ goto wiphy_unreg_out; -+ } -+ - /* If cfg80211 didn't disable 40MHz HT CAP in wiphy_register(), - * setup 40MHz in 2GHz band and enable OBSS scanning. - */ diff --git a/package/kernel/mac80211/patches/360-0001-brcmfmac-avoid-writing-channel-out-of-allocated-arra.patch b/package/kernel/mac80211/patches/360-0001-brcmfmac-avoid-writing-channel-out-of-allocated-arra.patch new file mode 100644 index 0000000000..710979a738 --- /dev/null +++ b/package/kernel/mac80211/patches/360-0001-brcmfmac-avoid-writing-channel-out-of-allocated-arra.patch @@ -0,0 +1,101 @@ +From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= +Date: Wed, 4 Jan 2017 12:09:41 +0100 +Subject: [PATCH] brcmfmac: avoid writing channel out of allocated array +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Our code was assigning number of channels to the index variable by +default. If firmware reported channel we didn't predict this would +result in using that initial index value and writing out of array. This +never happened so far (we got a complete list of supported channels) but +it means possible memory corruption so we should handle it anyway. + +This patch simply detects unexpected channel and ignores it. + +As we don't try to create new entry now, it's also safe to drop hw_value +and center_freq assignment. For known channels we have these set anyway. + +I decided to fix this issue by assigning NULL or a target channel to the +channel variable. This was one of possible ways, I prefefred this one as +it also avoids using channel[index] over and over. + +Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy bands") +Signed-off-by: Rafał Miłecki +Acked-by: Arend van Spriel +Signed-off-by: Kalle Valo +--- + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +@@ -5913,7 +5913,6 @@ static int brcmf_construct_chaninfo(stru + u32 i, j; + u32 total; + u32 chaninfo; +- u32 index; + + pbuf = kzalloc(BRCMF_DCMD_MEDLEN, GFP_KERNEL); + +@@ -5961,33 +5960,36 @@ static int brcmf_construct_chaninfo(stru + ch.bw == BRCMU_CHAN_BW_80) + continue; + +- channel = band->channels; +- index = band->n_channels; ++ channel = NULL; + for (j = 0; j < band->n_channels; j++) { +- if (channel[j].hw_value == ch.control_ch_num) { +- index = j; ++ if (band->channels[j].hw_value == ch.control_ch_num) { ++ channel = &band->channels[j]; + break; + } + } +- channel[index].center_freq = +- ieee80211_channel_to_frequency(ch.control_ch_num, +- band->band); +- channel[index].hw_value = ch.control_ch_num; ++ if (!channel) { ++ /* It seems firmware supports some channel we never ++ * considered. Something new in IEEE standard? ++ */ ++ brcmf_err("Ignoring unexpected firmware channel %d\n", ++ ch.control_ch_num); ++ continue; ++ } + + /* assuming the chanspecs order is HT20, + * HT40 upper, HT40 lower, and VHT80. + */ + if (ch.bw == BRCMU_CHAN_BW_80) { +- channel[index].flags &= ~IEEE80211_CHAN_NO_80MHZ; ++ channel->flags &= ~IEEE80211_CHAN_NO_80MHZ; + } else if (ch.bw == BRCMU_CHAN_BW_40) { +- brcmf_update_bw40_channel_flag(&channel[index], &ch); ++ brcmf_update_bw40_channel_flag(channel, &ch); + } else { + /* enable the channel and disable other bandwidths + * for now as mentioned order assure they are enabled + * for subsequent chanspecs. + */ +- channel[index].flags = IEEE80211_CHAN_NO_HT40 | +- IEEE80211_CHAN_NO_80MHZ; ++ channel->flags = IEEE80211_CHAN_NO_HT40 | ++ IEEE80211_CHAN_NO_80MHZ; + ch.bw = BRCMU_CHAN_BW_20; + cfg->d11inf.encchspec(&ch); + chaninfo = ch.chspec; +@@ -5995,11 +5997,11 @@ static int brcmf_construct_chaninfo(stru + &chaninfo); + if (!err) { + if (chaninfo & WL_CHAN_RADAR) +- channel[index].flags |= ++ channel->flags |= + (IEEE80211_CHAN_RADAR | + IEEE80211_CHAN_NO_IR); + if (chaninfo & WL_CHAN_PASSIVE) +- channel[index].flags |= ++ channel->flags |= + IEEE80211_CHAN_NO_IR; + } + } diff --git a/package/kernel/mac80211/patches/360-0002-brcmfmac-don-t-preset-all-channels-as-disabled.patch b/package/kernel/mac80211/patches/360-0002-brcmfmac-don-t-preset-all-channels-as-disabled.patch new file mode 100644 index 0000000000..dbe45642f3 --- /dev/null +++ b/package/kernel/mac80211/patches/360-0002-brcmfmac-don-t-preset-all-channels-as-disabled.patch @@ -0,0 +1,35 @@ +From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= +Date: Sat, 7 Jan 2017 21:36:04 +0100 +Subject: [PATCH] brcmfmac: don't preset all channels as disabled +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +During init we take care of regulatory stuff by disabling all +unavailable channels (see brcmf_construct_chaninfo) so this predisabling +them is not really required (and this patch won't change any behavior). +It will on the other hand allow more detailed runtime control over +channels which is the main reason for this change. + +Signed-off-by: Rafał Miłecki +Signed-off-by: Kalle Valo +--- + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +@@ -147,7 +147,6 @@ static struct ieee80211_rate __wl_rates[ + .band = NL80211_BAND_2GHZ, \ + .center_freq = (_freq), \ + .hw_value = (_channel), \ +- .flags = IEEE80211_CHAN_DISABLED, \ + .max_antenna_gain = 0, \ + .max_power = 30, \ + } +@@ -156,7 +155,6 @@ static struct ieee80211_rate __wl_rates[ + .band = NL80211_BAND_5GHZ, \ + .center_freq = 5000 + (5 * (_channel)), \ + .hw_value = (_channel), \ +- .flags = IEEE80211_CHAN_DISABLED, \ + .max_antenna_gain = 0, \ + .max_power = 30, \ + } diff --git a/package/kernel/mac80211/patches/360-0003-brcmfmac-setup-wiphy-bands-after-registering-it-firs.patch b/package/kernel/mac80211/patches/360-0003-brcmfmac-setup-wiphy-bands-after-registering-it-firs.patch new file mode 100644 index 0000000000..d7aa7e9558 --- /dev/null +++ b/package/kernel/mac80211/patches/360-0003-brcmfmac-setup-wiphy-bands-after-registering-it-firs.patch @@ -0,0 +1,50 @@ +From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= +Date: Sat, 7 Jan 2017 21:36:05 +0100 +Subject: [PATCH] brcmfmac: setup wiphy bands after registering it first +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +During bands setup we disable all channels that firmware doesn't support +in the current regulatory setup. If we do this before wiphy_register +it will result in copying set flags (including IEEE80211_CHAN_DISABLED) +to the orig_flags which is supposed to be persistent. We don't want this +as regulatory change may result in enabling some channels. We shouldn't +mess with orig_flags then (by changing them or ignoring them) so it's +better to just take care of their proper values. + +This patch cleanups code a bit (by taking orig_flags more seriously) and +allows further improvements like disabling really unavailable channels. +We will need that e.g. if some frequencies should be disabled for good +due to hardware setup (design). + +Signed-off-by: Rafał Miłecki +Acked-by: Arend van Spriel +Signed-off-by: Kalle Valo +--- + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +@@ -6564,8 +6564,7 @@ static int brcmf_setup_wiphy(struct wiph + wiphy->bands[NL80211_BAND_5GHZ] = band; + } + } +- err = brcmf_setup_wiphybands(wiphy); +- return err; ++ return 0; + } + + static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg) +@@ -6930,6 +6929,12 @@ struct brcmf_cfg80211_info *brcmf_cfg802 + goto priv_out; + } + ++ err = brcmf_setup_wiphybands(wiphy); ++ if (err) { ++ brcmf_err("Setting wiphy bands failed (%d)\n", err); ++ goto wiphy_unreg_out; ++ } ++ + /* If cfg80211 didn't disable 40MHz HT CAP in wiphy_register(), + * setup 40MHz in 2GHz band and enable OBSS scanning. + */