There are more patches to backport that should go before these.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
+++ /dev/null
-From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
-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 <rafal@milecki.pl>
-Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
-Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
----
-
---- 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;
- }
- }
+++ /dev/null
-From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
-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 <rafal@milecki.pl>
-Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
----
-
---- 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, \
- }
+++ /dev/null
-From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
-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 <rafal@milecki.pl>
-Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
-Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
----
-
---- 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.
- */
--- /dev/null
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
+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 <rafal@milecki.pl>
+Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+---
+
+--- 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;
+ }
+ }
--- /dev/null
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
+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 <rafal@milecki.pl>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+---
+
+--- 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, \
+ }
--- /dev/null
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
+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 <rafal@milecki.pl>
+Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+---
+
+--- 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.
+ */
projects / openwrt / staging / lynxis.git / commitdiff