* [PATCH-mac8011] mac80211: fix ignored channel parameter
From: Simon Wunderlich @ 2013-08-21 13:30 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
my earlier patch "mac80211: change IBSS channel state to chandef"
created a regression by ignoring the channel parameter in
__ieee80211_sta_join_ibss, which breaks IBSS channel selection. This
patch fixes this situation by using the right channel and adopting the
selected bandwidth mode.
Cc: stable@vger.kernel.org
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
This version is based on mac80211.git for fixes, and the bandwidth
handling was changed in ieee80211_sta_join_ibss to more readable.
---
net/mac80211/ibss.c | 33 +++++++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index ea7b9c2..f292e8f 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -36,7 +36,7 @@
static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
const u8 *bssid, const int beacon_int,
- struct ieee80211_channel *chan,
+ struct cfg80211_chan_def *req_chandef,
const u32 basic_rates,
const u16 capability, u64 tsf,
bool creator)
@@ -51,6 +51,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
u32 bss_change;
u8 supp_rates[IEEE80211_MAX_SUPP_RATES];
struct cfg80211_chan_def chandef;
+ struct ieee80211_channel *chan;
struct beacon_data *presp;
int frame_len;
@@ -81,7 +82,9 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
- chandef = ifibss->chandef;
+ /* make a copy of the chandef, it could be modified below. */
+ chandef = *req_chandef;
+ chan = chandef.chan;
if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
chandef.width = NL80211_CHAN_WIDTH_20;
chandef.center_freq1 = chan->center_freq;
@@ -259,10 +262,12 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
struct cfg80211_bss *cbss =
container_of((void *)bss, struct cfg80211_bss, priv);
struct ieee80211_supported_band *sband;
+ struct cfg80211_chan_def chandef;
u32 basic_rates;
int i, j;
u16 beacon_int = cbss->beacon_interval;
const struct cfg80211_bss_ies *ies;
+ enum nl80211_channel_type chan_type;
u64 tsf;
sdata_assert_lock(sdata);
@@ -270,6 +275,26 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
if (beacon_int < 10)
beacon_int = 10;
+ switch (sdata->u.ibss.chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_40:
+ chan_type = cfg80211_get_chandef_type(&sdata->u.ibss.chandef);
+ cfg80211_chandef_create(&chandef, cbss->channel, chan_type);
+ break;
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
+ cfg80211_chandef_create(&chandef, cbss->channel,
+ NL80211_CHAN_WIDTH_20_NOHT);
+ chandef.width = sdata->u.ibss.chandef.width;
+ break;
+ default:
+ /* fall back to 20 MHz for unsupported modes */
+ cfg80211_chandef_create(&chandef, cbss->channel,
+ NL80211_CHAN_WIDTH_20_NOHT);
+ break;
+ }
+
sband = sdata->local->hw.wiphy->bands[cbss->channel->band];
basic_rates = 0;
@@ -294,7 +319,7 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
__ieee80211_sta_join_ibss(sdata, cbss->bssid,
beacon_int,
- cbss->channel,
+ &chandef,
basic_rates,
cbss->capability,
tsf, false);
@@ -736,7 +761,7 @@ static void ieee80211_sta_create_ibss(struct ieee80211_sub_if_data *sdata)
sdata->drop_unencrypted = 0;
__ieee80211_sta_join_ibss(sdata, bssid, sdata->vif.bss_conf.beacon_int,
- ifibss->chandef.chan, ifibss->basic_rates,
+ &ifibss->chandef, ifibss->basic_rates,
capability, 0, true);
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2 3.11] mac80211: add missing channel context release
From: Johannes Berg @ 2013-08-21 13:04 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1377079496-27797-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-08-21 at 12:04 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> IBSS needs to release the channel context when leaving
> but I evidently missed that. Fix it.
Tested & applied.
johannes
^ permalink raw reply
* Re: [REGRESSION] 3.10.{6,7} crashes on network activity
From: Josh Boyer @ 2013-08-21 12:38 UTC (permalink / raw)
To: Arend van Spriel
Cc: Felix Fietkau, Greg Kroah-Hartman, Tom Gundersen,
stable@vger.kernel.org, Linux Wireless List, LKML, Johannes Berg
In-Reply-To: <52147FD2.9020401@broadcom.com>
On Wed, Aug 21, 2013 at 4:52 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>> Hi Felix,
>>>
>>> I have been diving into root causing why brcmsmac can not handle cck
>>> fallback rates, because it should. Maybe it is better to flag no cck
>>> support
>>> and only change brcmsmac.
>>
>>
>> We have a number of users hitting this in Fedora 18 and 19 now. We're
>> tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
>> and I'm sure we can find people to test easily.
>
>
> There is already another one (possibly) dealing with the same issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=989269
>
> One of them should probably be flagged as duplicate.
>
>
>> If you have a patch disabling cck in brcmsmac, I'd be happy to build a
>> kernel for people. If that's going to be some time coming, perhaps
>> it's better to grab Felix's patch on a temporary basis?
>
>
> I think it is better to grab Felix's patch because as we both observed there
> is stuff missing in brcmsmac to deal with CCK rates and A-MPDU packet
> aggregation.
OK, thanks.
Felix, are you going to send that upstream?
josh
^ permalink raw reply
* [PATCH] mac80211: fix ignored channel parameter
From: Simon Wunderlich @ 2013-08-21 11:40 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
my earlier patch "mac80211: change IBSS channel state to chandef"
created a regression by ignoring the channel parameter in
__ieee80211_sta_join_ibss, which breaks IBSS channel selection. This
patch fixes this situation by using the right channel and adopting the
selected bandwidth mode.
Cc: stable@vger.kernel.org
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
net/mac80211/ibss.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 74de0f1..2669595 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -201,7 +201,7 @@ error:
static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
const u8 *bssid, const int beacon_int,
- struct ieee80211_channel *chan,
+ struct cfg80211_chan_def *req_chandef,
const u32 basic_rates,
const u16 capability, u64 tsf,
bool creator)
@@ -213,6 +213,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
struct cfg80211_bss *bss;
u32 bss_change;
struct cfg80211_chan_def chandef;
+ struct ieee80211_channel *chan;
struct beacon_data *presp;
enum nl80211_bss_scan_width scan_width;
bool have_higher_than_11mbit;
@@ -244,7 +245,9 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
- chandef = ifibss->chandef;
+ /* make a copy of the chandef, it could be modified below. */
+ chandef = *req_chandef;
+ chan = chandef.chan;
if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
if (chandef.width == NL80211_CHAN_WIDTH_5 ||
chandef.width == NL80211_CHAN_WIDTH_10 ||
@@ -339,6 +342,7 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
struct cfg80211_bss *cbss =
container_of((void *)bss, struct cfg80211_bss, priv);
struct ieee80211_supported_band *sband;
+ struct cfg80211_chan_def chandef;
u32 basic_rates;
int i, j;
u16 beacon_int = cbss->beacon_interval;
@@ -352,6 +356,13 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
if (beacon_int < 10)
beacon_int = 10;
+ chandef.chan = cbss->channel;
+ chandef.width = sdata->u.ibss.chandef.width;
+ chandef.center_freq1 = chandef.chan->center_freq +
+ sdata->u.ibss.chandef.center_freq1 -
+ sdata->u.ibss.chandef.chan->center_freq;
+ chandef.center_freq2 = 0;
+
sband = sdata->local->hw.wiphy->bands[cbss->channel->band];
rate_flags = ieee80211_chandef_rate_flags(&sdata->u.ibss.chandef);
shift = ieee80211_vif_get_shift(&sdata->vif);
@@ -385,7 +396,7 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
__ieee80211_sta_join_ibss(sdata, cbss->bssid,
beacon_int,
- cbss->channel,
+ &chandef,
basic_rates,
cbss->capability,
tsf, false);
@@ -867,7 +878,7 @@ static void ieee80211_sta_create_ibss(struct ieee80211_sub_if_data *sdata)
sdata->drop_unencrypted = 0;
__ieee80211_sta_join_ibss(sdata, bssid, sdata->vif.bss_conf.beacon_int,
- ifibss->chandef.chan, ifibss->basic_rates,
+ &ifibss->chandef, ifibss->basic_rates,
capability, 0, true);
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 09/16] wcn36xx: Add smd.c
From: Joe Perches @ 2013-08-21 11:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: Eugene Krasnikov, linux-wireless, wcn36xx
In-Reply-To: <1377072922.15268.4.camel@jlt4.sipsolutions.net>
On Wed, 2013-08-21 at 10:15 +0200, Johannes Berg wrote:
> It should really be u8* instead of void*, since void* pointer arithmetic
> isn't really defined I think?
Well, it is for gcc and void * arithmetic is
widely used throughout the kernel.
^ permalink raw reply
* [PATCH v2 3.11] mac80211: add missing channel context release
From: Johannes Berg @ 2013-08-21 10:04 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
IBSS needs to release the channel context when leaving
but I evidently missed that. Fix it.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ibss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index ea7b9c2..5e8bb3b 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1138,6 +1138,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
BSS_CHANGED_IBSS);
+ ieee80211_vif_release_channel(sdata);
synchronize_rcu();
kfree(presp);
--
1.8.4.rc2
^ permalink raw reply related
* [PATCH 3.11] mac80211: add missing channel context release
From: Johannes Berg @ 2013-08-21 10:04 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
IBSS needs to release the channel context when leaving
but I evidently missed that. Fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ibss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index ea7b9c2..5e8bb3b 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1138,6 +1138,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
BSS_CHANGED_IBSS);
+ ieee80211_vif_release_channel(sdata);
synchronize_rcu();
kfree(presp);
--
1.8.4.rc2
^ permalink raw reply related
* Re: [PATCH] mac80211: add missing channel context release
From: Johannes Berg @ 2013-08-21 9:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1377079129-23481-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-08-21 at 11:58 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> IBSS needs to release the channel context when leaving
> but I evidently missed that. Fix it.
>
> Change-Id: Iaa87fdd143d5a1a7eac5b0bb63d11dca372a6bb3
Umm, I'll remove that :)
johannes
^ permalink raw reply
* [PATCH] mac80211: add missing channel context release
From: Johannes Berg @ 2013-08-21 9:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
IBSS needs to release the channel context when leaving
but I evidently missed that. Fix it.
Change-Id: Iaa87fdd143d5a1a7eac5b0bb63d11dca372a6bb3
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ibss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 74de0f1..5fb1b14 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1304,6 +1304,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
BSS_CHANGED_IBSS);
+ ieee80211_vif_release_channel(sdata);
synchronize_rcu();
kfree(presp);
--
1.8.4.rc2
^ permalink raw reply related
* [PATCH V2 12/12] brcmsmac: add support for BCM4313 iPA variant
From: Arend van Spriel @ 2013-08-21 9:45 UTC (permalink / raw)
To: John W. Linville; +Cc: Joe Perches, linux-wireless, Arend van Spriel
In-Reply-To: <1377007246-9957-13-git-send-email-arend@broadcom.com>
This patch completes the changes needed for supporting the
iPA variant cards of the BCM4313 wireless chipset.
Tested-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
Added 'static const' qualifier to address comment from Joe Perches.
This patch replaces the previous patch with
Message-ID: <1377007246-9957-13-git-send-email-arend@broadcom.com>
Regards,
Arend
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 73 ++++++++++++++------
1 file changed, 53 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
index 8fb1048..b2d6d6d 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -1826,6 +1826,19 @@ wlc_lcnphy_radio_2064_channel_tune_4313(struct brcms_phy *pi, u8 channel)
write_radio_reg(pi, RADIO_2064_REG038, 3);
write_radio_reg(pi, RADIO_2064_REG091, 7);
}
+
+ if (!(pi->sh->boardflags & BFL_FEM)) {
+ static const u8 reg038[14] = {
+ 0xd, 0xe, 0xd, 0xd, 0xd, 0xc, 0xa,
+ 0xb, 0xb, 0x3, 0x3, 0x2, 0x0, 0x0
+ };
+
+ write_radio_reg(pi, RADIO_2064_REG02A, 0xf);
+ write_radio_reg(pi, RADIO_2064_REG091, 0x3);
+ write_radio_reg(pi, RADIO_2064_REG038, 0x3);
+
+ write_radio_reg(pi, RADIO_2064_REG038, reg038[channel - 1]);
+ }
}
static int
@@ -2123,7 +2136,16 @@ static void wlc_lcnphy_tssi_setup(struct brcms_phy *pi)
{
struct phytbl_info tab;
u32 rfseq, ind;
+ enum lcnphy_tssi_mode mode;
+ u8 tssi_sel;
+ if (pi->sh->boardflags & BFL_FEM) {
+ tssi_sel = 0x1;
+ mode = LCNPHY_TSSI_EXT;
+ } else {
+ tssi_sel = 0xe;
+ mode = LCNPHY_TSSI_POST_PA;
+ }
tab.tbl_id = LCNPHY_TBL_ID_TXPWRCTL;
tab.tbl_width = 32;
tab.tbl_ptr = &ind;
@@ -2144,7 +2166,7 @@ static void wlc_lcnphy_tssi_setup(struct brcms_phy *pi)
mod_phy_reg(pi, 0x503, (0x1 << 4), (1) << 4);
- wlc_lcnphy_set_tssi_mux(pi, LCNPHY_TSSI_EXT);
+ wlc_lcnphy_set_tssi_mux(pi, mode);
mod_phy_reg(pi, 0x4a4, (0x1 << 14), (0) << 14);
mod_phy_reg(pi, 0x4a4, (0x1 << 15), (1) << 15);
@@ -2180,9 +2202,10 @@ static void wlc_lcnphy_tssi_setup(struct brcms_phy *pi)
mod_phy_reg(pi, 0x49a, (0x1ff << 0), (0xff) << 0);
if (LCNREV_IS(pi->pubpi.phy_rev, 2)) {
- mod_radio_reg(pi, RADIO_2064_REG028, 0xf, 0xe);
+ mod_radio_reg(pi, RADIO_2064_REG028, 0xf, tssi_sel);
mod_radio_reg(pi, RADIO_2064_REG086, 0x4, 0x4);
} else {
+ mod_radio_reg(pi, RADIO_2064_REG028, 0x1e, tssi_sel << 1);
mod_radio_reg(pi, RADIO_2064_REG03A, 0x1, 1);
mod_radio_reg(pi, RADIO_2064_REG11A, 0x8, 1 << 3);
}
@@ -4358,8 +4381,11 @@ wlc_lcnphy_load_tx_gain_table(struct brcms_phy *pi,
tab.tbl_len = 1;
tab.tbl_ptr = &val;
+ /* fixed gm_gain value for iPA */
+ gm_gain = 15;
for (j = 0; j < 128; j++) {
- gm_gain = gain_table[j].gm;
+ if (pi->sh->boardflags & BFL_FEM)
+ gm_gain = gain_table[j].gm;
val = (((u32) pa_gain << 24) |
(gain_table[j].pad << 16) |
(gain_table[j].pga << 8) | gm_gain);
@@ -4570,7 +4596,10 @@ static void wlc_radio_2064_init(struct brcms_phy *pi)
write_phy_reg(pi, 0x4ea, 0x4688);
- mod_phy_reg(pi, 0x4eb, (0x7 << 0), 2 << 0);
+ if (pi->sh->boardflags & BFL_FEM)
+ mod_phy_reg(pi, 0x4eb, (0x7 << 0), 2 << 0);
+ else
+ mod_phy_reg(pi, 0x4eb, (0x7 << 0), 3 << 0);
mod_phy_reg(pi, 0x4eb, (0x7 << 6), 0 << 6);
@@ -4581,6 +4610,13 @@ static void wlc_radio_2064_init(struct brcms_phy *pi)
wlc_lcnphy_rcal(pi);
wlc_lcnphy_rc_cal(pi);
+
+ if (!(pi->sh->boardflags & BFL_FEM)) {
+ write_radio_reg(pi, RADIO_2064_REG032, 0x6f);
+ write_radio_reg(pi, RADIO_2064_REG033, 0x19);
+ write_radio_reg(pi, RADIO_2064_REG039, 0xe);
+ }
+
}
static void wlc_lcnphy_radio_init(struct brcms_phy *pi)
@@ -4611,22 +4647,20 @@ static void wlc_lcnphy_tbl_init(struct brcms_phy *pi)
wlc_lcnphy_write_table(pi, &tab);
}
- tab.tbl_id = LCNPHY_TBL_ID_RFSEQ;
- tab.tbl_width = 16;
- tab.tbl_ptr = &val;
- tab.tbl_len = 1;
-
- val = 114;
- tab.tbl_offset = 0;
- wlc_lcnphy_write_table(pi, &tab);
+ if (!(pi->sh->boardflags & BFL_FEM)) {
+ tab.tbl_id = LCNPHY_TBL_ID_RFSEQ;
+ tab.tbl_width = 16;
+ tab.tbl_ptr = &val;
+ tab.tbl_len = 1;
- val = 130;
- tab.tbl_offset = 1;
- wlc_lcnphy_write_table(pi, &tab);
+ val = 150;
+ tab.tbl_offset = 0;
+ wlc_lcnphy_write_table(pi, &tab);
- val = 6;
- tab.tbl_offset = 8;
- wlc_lcnphy_write_table(pi, &tab);
+ val = 220;
+ tab.tbl_offset = 1;
+ wlc_lcnphy_write_table(pi, &tab);
+ }
if (CHSPEC_IS2G(pi->radio_chanspec)) {
if (pi->sh->boardflags & BFL_FEM)
@@ -5059,8 +5093,7 @@ bool wlc_phy_attach_lcnphy(struct brcms_phy *pi)
if (!wlc_phy_txpwr_srom_read_lcnphy(pi))
return false;
- if ((pi->sh->boardflags & BFL_FEM) &&
- (LCNREV_IS(pi->pubpi.phy_rev, 1))) {
+ if (LCNREV_IS(pi->pubpi.phy_rev, 1)) {
if (pi_lcn->lcnphy_tempsense_option == 3) {
pi->hwpwrctrl = true;
pi->hwpwrctrl_capable = true;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCHv3 09/18] mac80211: change IBSS channel state to chandef
From: Johannes Berg @ 2013-08-21 9:35 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368702045-27598-10-git-send-email-siwu@hrz.tu-chemnitz.de>
On Thu, 2013-05-16 at 13:00 +0200, Simon Wunderlich wrote:
> - cfg80211_chandef_create(&chandef, chan, ifibss->channel_type);
> + chandef = ifibss->chandef;
This part is obviously wrong - it ignores the given channel. Please post
a fix as soon as you can, with the code as it is now we never join an
existing IBSS correctly but always use the channel the user gave.
johannes
^ permalink raw reply
* [PATCH] mac80211: add missing channel context release
From: Johannes Berg @ 2013-08-21 9:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
IBSS needs to release the channel context when leaving
but I evidently missed that. Fix it.
Change-Id: Iaa87fdd143d5a1a7eac5b0bb63d11dca372a6bb3
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ibss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 74de0f1..5fb1b14 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1304,6 +1304,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
BSS_CHANGED_IBSS);
+ ieee80211_vif_release_channel(sdata);
synchronize_rcu();
kfree(presp);
--
1.8.4.rc2
^ permalink raw reply related
* Re: [PATCH 12/12] brcmsmac: add support for BCM4313 iPA variant
From: Arend van Spriel @ 2013-08-21 9:28 UTC (permalink / raw)
To: Joe Perches; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1377023415.2016.63.camel@joe-AO722>
On 08/20/2013 08:30 PM, Joe Perches wrote:
> On Tue, 2013-08-20 at 16:00 +0200, Arend van Spriel wrote:
>> This patch completes the changes needed for supporting the
>> iPA variant cards of the BCM4313 wireless chipset.
> []
>> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
> []
>> @@ -1826,6 +1826,17 @@ wlc_lcnphy_radio_2064_channel_tune_4313(struct brcms_phy *pi, u8 channel)
>> write_radio_reg(pi, RADIO_2064_REG038, 3);
>> write_radio_reg(pi, RADIO_2064_REG091, 7);
>> }
>> +
>> + if (!(pi->sh->boardflags & BFL_FEM)) {
>> + u8 reg038[14] = {0xd, 0xe, 0xd, 0xd, 0xd, 0xc,
>> + 0xa, 0xb, 0xb, 0x3, 0x3, 0x2, 0x0, 0x0};
>
> static const would reduce the object size.
You are right. I will change that.
>> + write_radio_reg(pi, RADIO_2064_REG02A, 0xf);
>> + write_radio_reg(pi, RADIO_2064_REG091, 0x3);
>> + write_radio_reg(pi, RADIO_2064_REG038, 0x3);
>> +
>> + write_radio_reg(pi, RADIO_2064_REG038, reg038[channel - 1]);
>
> Does anything limit channel to < 15?
The 4313 is a 2.4GHz wireless device so channel will always be in the
range 1 to 14. This is validated earlier in the call sequence leading to
this function.
> There seem to be an awful lot of magic numbers
> in the patch.
Unfortunately, that is the case for most of the phy code. Most stuff is
the result of tuning the phy performance.
Regards,
Arend
^ permalink raw reply
* [PATCH] mac80211: move setting WIPHY_FLAG_SUPPORTS_SCHED_SCAN into drivers
From: Johannes Berg @ 2013-08-21 9:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
mac80211 currently sets WIPHY_FLAG_SUPPORTS_SCHED_SCAN based on whether
the start_sched_scan operation is supported or not, but that will not
be correct for all drivers, we're adding scheduled scan to the iwlmvm
driver but it depends on firmware support.
Therefore, move setting WIPHY_FLAG_SUPPORTS_SCHED_SCAN into the drivers
so that they can control it regardless of implementing the operation.
This currently only affects the TI drivers since they're the only ones
implementing scheduled scan (in a mac80211 driver.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/ti/wlcore/main.c | 3 ++-
net/mac80211/main.c | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index d1b19c3..38995f9 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5623,7 +5623,8 @@ static int wl1271_init_ieee80211(struct wl1271 *wl)
wl->hw->wiphy->max_remain_on_channel_duration = 5000;
wl->hw->wiphy->flags |= WIPHY_FLAG_AP_UAPSD |
- WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
+ WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
+ WIPHY_FLAG_SUPPORTS_SCHED_SCAN;
/* make sure all our channels fit in the scanned_ch bitmask */
BUILD_BUG_ON(ARRAY_SIZE(wl1271_channels) +
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 25eb35b..21d5d44 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -892,9 +892,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
if (!local->ops->remain_on_channel)
local->hw.wiphy->max_remain_on_channel_duration = 5000;
- if (local->ops->sched_scan_start)
- local->hw.wiphy->flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN;
-
/* mac80211 based drivers don't support internal TDLS setup */
if (local->hw.wiphy->flags & WIPHY_FLAG_SUPPORTS_TDLS)
local->hw.wiphy->flags |= WIPHY_FLAG_TDLS_EXTERNAL_SETUP;
--
1.8.4.rc2
^ permalink raw reply related
* Re: [PATCH 01/16] wcn36xx: Add main.c
From: Eugene Krasnikov @ 2013-08-21 9:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377074351.15268.7.camel@jlt4.sipsolutions.net>
> [remove wcn list, it annoys me with moderator messages]
Sorry for that, now should be fixed.
>> >> + if (IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags) {
>> >> + sta_priv->is_data_encrypted = true;
>> >> + /* Reconfigure bss with encrypt_type */
>> >> + if (NL80211_IFTYPE_STATION == vif->type)
>> >> + wcn36xx_smd_config_bss(wcn,
>> >> + vif,
>> >> + sta,
>> >> + sta->addr,
>> >> + true);
>> >
>> > It seems to me this should not be here but you should have mac80211 set
>> > something in e.g. bss_conf that indicates encryption?
>> >
>>
>> It's a good idea and I tried to find anything encryption related in
>> bss_conf but without luck. I do not like this line myself so I would
>> really appreciate if you can point where exactly in
>> bss_conf/bss_info_changed information about encryption is located.
>
> There isn't anything, but you could always add it.
Aha, ok will add this to my todo list:)
>> >> + static const u32 cipher_suites[] = {
>> >> + WLAN_CIPHER_SUITE_TKIP,
>> >> + WLAN_CIPHER_SUITE_CCMP,
>> >> + };
>> >
>> > You actually don't want to support WEP, not even in software? Otherwise
>> > just leave this out and mac80211 will add it.
>>
>> WEP is supported by HW but wcn36xx does not configure it yet. Is that
>> ok to add HW WEP encryption in nearest future after wcn36xx is pushed
>> to upstream?
>
> I don't see why you'd even bother - why not just use software encryption
> for WEP for the time being? Then you don't need this code.
Because if I add something I test it, and that will take the same
amount of time as to add HW WEP ;) Let me add HW WEP since it's faster
then SW WEP.
>> >> + wcn->hw->wiphy->iface_combinations = &if_comb;
>> >> + wcn->hw->wiphy->n_iface_combinations = 1;
>> >
>> > Your code with "wcn->current_vif = " etc. *really* doesn't look like you
>> > support combinations. Are you positive this is OK?
>>
>> So far wcn36xx supports only one interface at once. But in the nearest
>> future it will definitely support more than one. So how about keeping
>> this for future?;)
>
> It's *wrong* though - you're saying two interfaces are supported and
> then they aren't. Don't do that.
You are right. Will remove this for now.
--
Best regards,
Eugene
^ permalink raw reply
* Re: [REGRESSION] 3.10.{6,7} crashes on network activity
From: Arend van Spriel @ 2013-08-21 8:52 UTC (permalink / raw)
To: Josh Boyer
Cc: Felix Fietkau, Greg Kroah-Hartman, Tom Gundersen,
stable@vger.kernel.org, Linux Wireless List, LKML, Johannes Berg
In-Reply-To: <CA+5PVA7gvnfX2vnpxEGCgaAYXRvA=SME4SYZpTESqLsMkgSu=g@mail.gmail.com>
On 08/21/2013 02:11 AM, Josh Boyer wrote:
> On Tue, Aug 20, 2013 at 4:15 AM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 08/20/2013 06:56 AM, Felix Fietkau wrote:
>>>
>>> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>>>>
>>>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>>>>
>>>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> Starting with 3.10.6 (and still present in .7) I get an oops on
>>>>>>> connecting to the network.
>>>>>>>
>>>>>>> The attached picture shows the oops. In case it does not reach the ML,
>>>>>>> the top of the call trace reads:
>>>>>>>
>>>>>>> brcms_c_compute_rtscts_dur
>>>>>>> brcms_c_ampdu_finalize
>>>>>>> ampdu_finalize
>>>>>>> dma_txfast
>>>>>>> brcms_c_txfifo
>>>>>>> brcms_c_sendpkt_mac80211
>>>>>>> brcms_ops_tx
>>>>>>> __ieee80211_tx
>>>>>>>
>>>>>>> I bisected the problem and the first bad commit is
>>>>>>>
>>>>>>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>>>>>> Author: Felix Fietkau <nbd@openwrt.org>
>>>>>>> Date: Fri Jun 28 21:04:35 2013 +0200
>>>>>>>
>>>>>>> mac80211/minstrel_ht: fix cck rate sampling
>>>>>>>
>>>>>>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>>>>>>
>>>>>>> Reverting it on top of .7 fixes the problem.
>>>>>>>
>>>>>>> I had the same (I suppose) problem on mainline some time ago, but I
>>>>>>> have not bisected it, verified that the problem still occurs there, or
>>>>>>> checked if reverting the upstream patch fixes it. I'd be happy to do
>>>>>>> that if it would help though.
>>>>>>>
>>>>>>> Let me know if you need any more information.
>>>>>>
>>>>>>
>>>>>> Do you have this same problem with 3.11-rc6 as well?
>>>>>
>>>>>
>>>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>>>> commit on top of -rc6 fixes the problem.
>>>>
>>>>
>>>> Great, thanks.
>>>>
>>>> Felix and Johannes, any chance we can get this reverted in Linus tree
>>>> soon, and push that revert back to the 3.10 stable tree as well?
>>>
>>> I'd like to avoid a revert, since that will simply replace one set of
>>> issues with another. Let's limit the use of the feature that brcmsmac
>>> can't handle to drivers that are known to work with it. Tom, Please
>>> test this patch to see if it fixes your issue.
>>
>>
>> Hi Felix,
>>
>> I have been diving into root causing why brcmsmac can not handle cck
>> fallback rates, because it should. Maybe it is better to flag no cck support
>> and only change brcmsmac.
>
> We have a number of users hitting this in Fedora 18 and 19 now. We're
> tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
> and I'm sure we can find people to test easily.
There is already another one (possibly) dealing with the same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=989269
One of them should probably be flagged as duplicate.
> If you have a patch disabling cck in brcmsmac, I'd be happy to build a
> kernel for people. If that's going to be some time coming, perhaps
> it's better to grab Felix's patch on a temporary basis?
I think it is better to grab Felix's patch because as we both observed
there is stuff missing in brcmsmac to deal with CCK rates and A-MPDU
packet aggregation.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 09/16] wcn36xx: Add smd.c
From: Eugene Krasnikov @ 2013-08-21 8:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Joe Perches, linux-wireless, wcn36xx
In-Reply-To: <1377072922.15268.4.camel@jlt4.sipsolutions.net>
>> >> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
>> > []
>> >> +int wcn36xx_smd_load_nv(struct wcn36xx *wcn)
>> >> +{
>> > []
>> >> + /* Add NV body itself */
>> >> + /* Rework me */
>> >> + memcpy(wcn->smd_buf + sizeof(msg_body),
>> >> + (void *)(&nv_d->table) + fm_offset,
>> >> + msg_body.nv_img_buffer_size);
>> >
>> > Does this really do what you want?
>> >
>> > Perhaps it should be:
>> >
>> > memcpy(wcn->smd_buf + sizeof(msg_body),
>> > ((void *)&nv_d->table) + fm_offset,
>> > msg_body.nv_img_buffer_size);
>> >
>>
>> Yes, this line is working. Tested it for ARM. Do you see any potential
>> problems with this pointer operation?
>
> It should really be u8* instead of void*, since void* pointer arithmetic
> isn't really defined I think?
>
> Other than that, this was just about precedence rules, and casts have a
> higher precedence.
>
Aha, now i understand what you mean. You are absolutely right it must
be u8*. Will fix in the next round.
--
Best regards,
Eugene
^ permalink raw reply
* Re: [PATCH 11/16] wcn36xx: Add txrx.c
From: Eugene Krasnikov @ 2013-08-21 8:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377032637.13829.42.camel@jlt4.sipsolutions.net>
> On Tue, 2013-08-20 at 19:41 +0200, Eugene Krasnikov wrote:
>
>> +int wcn36xx_start_tx(struct wcn36xx *wcn,
>> + struct wcn36xx_sta *sta_priv,
>> + struct sk_buff *skb)
>
> err ... this can return errors that you never handle, probably gets you
> leaks that way?
Good catch. In some corner cases ieee80211_free_txskb is not called.
--
Best regards,
Eugene
^ permalink raw reply
* Re: [PATCH 11/16] wcn36xx: Add txrx.c
From: Eugene Krasnikov @ 2013-08-21 8:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377032500.13829.41.camel@jlt4.sipsolutions.net>
>> + /* Data frames served first*/
>> + if (is_low) {
>> + /*
>> + * Sometimes in AP mode mac80211 is trying to send data
>> + * frame to nobody. Why?
>> + */
>> + if (!sta_priv)
>> + wcn36xx_warn("Sending data packet to nobody");
>
> Umm, really? Have you heard of something called multicast? ;-)
>
Do not know who wrote this code but this comment definitely must be removed!
--
Best regards,
Eugene
^ permalink raw reply
* Re: [PATCH 01/16] wcn36xx: Add main.c
From: Johannes Berg @ 2013-08-21 8:39 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: linux-wireless
In-Reply-To: <CAFSJ42ZH3ZJ+-+6wUbqQvaM8D2t6oWqyqkGiGRRx4o2NA60EjA@mail.gmail.com>
[remove wcn list, it annoys me with moderator messages]
> >> + if (IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags) {
> >> + sta_priv->is_data_encrypted = true;
> >> + /* Reconfigure bss with encrypt_type */
> >> + if (NL80211_IFTYPE_STATION == vif->type)
> >> + wcn36xx_smd_config_bss(wcn,
> >> + vif,
> >> + sta,
> >> + sta->addr,
> >> + true);
> >
> > It seems to me this should not be here but you should have mac80211 set
> > something in e.g. bss_conf that indicates encryption?
> >
>
> It's a good idea and I tried to find anything encryption related in
> bss_conf but without luck. I do not like this line myself so I would
> really appreciate if you can point where exactly in
> bss_conf/bss_info_changed information about encryption is located.
There isn't anything, but you could always add it.
> >> + static const u32 cipher_suites[] = {
> >> + WLAN_CIPHER_SUITE_TKIP,
> >> + WLAN_CIPHER_SUITE_CCMP,
> >> + };
> >
> > You actually don't want to support WEP, not even in software? Otherwise
> > just leave this out and mac80211 will add it.
>
> WEP is supported by HW but wcn36xx does not configure it yet. Is that
> ok to add HW WEP encryption in nearest future after wcn36xx is pushed
> to upstream?
I don't see why you'd even bother - why not just use software encryption
for WEP for the time being? Then you don't need this code.
> >> + wcn->hw->wiphy->iface_combinations = &if_comb;
> >> + wcn->hw->wiphy->n_iface_combinations = 1;
> >
> > Your code with "wcn->current_vif = " etc. *really* doesn't look like you
> > support combinations. Are you positive this is OK?
>
> So far wcn36xx supports only one interface at once. But in the nearest
> future it will definitely support more than one. So how about keeping
> this for future?;)
It's *wrong* though - you're saying two interfaces are supported and
then they aren't. Don't do that.
johannes
^ permalink raw reply
* Re: [PATCH 01/16] wcn36xx: Add main.c
From: Eugene Krasnikov @ 2013-08-21 8:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377032397.13829.40.camel@jlt4.sipsolutions.net>
> Just a cursory review ...
>
Any review is very welcome;)
>
>> + .cap = IEEE80211_HT_CAP_GRN_FLD
>> + | IEEE80211_HT_CAP_SGI_20
>
> wouldn't that usually be written as
>
> GRN_FLD |
> SGI_20 |
> ...
>
> (multiple similar places)
Will be fixed in the next round.
>> +#ifdef CONFIG_PM
>> +
>> +static const struct wiphy_wowlan_support wowlan_support = {
>> + .flags = WIPHY_WOWLAN_ANY,
>> + .n_patterns = 0,
>
> that n_patterns is pretty useless.
>
Will be removed in the next patch set.
>> +#define WCN36XX_SUPPORTED_FILTERS (0)
>> +
>> +static void wcn36xx_configure_filter(struct ieee80211_hw *hw,
>> + unsigned int changed,
>> + unsigned int *total, u64 multicast)
>> +{
>> + wcn36xx_dbg(WCN36XX_DBG_MAC, "mac configure filter");
>> +
>> + changed &= WCN36XX_SUPPORTED_FILTERS;
>
> That's pointless
Yes, it is better to remove wcn36xx_configure_filter completely for now.
>> + if (IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags) {
>> + sta_priv->is_data_encrypted = true;
>> + /* Reconfigure bss with encrypt_type */
>> + if (NL80211_IFTYPE_STATION == vif->type)
>> + wcn36xx_smd_config_bss(wcn,
>> + vif,
>> + sta,
>> + sta->addr,
>> + true);
>
> It seems to me this should not be here but you should have mac80211 set
> something in e.g. bss_conf that indicates encryption?
>
It's a good idea and I tried to find anything encryption related in
bss_conf but without luck. I do not like this line myself so I would
really appreciate if you can point where exactly in
bss_conf/bss_info_changed information about encryption is located.
>> + /* Not supported so far*/
>> + case IEEE80211_AMPDU_TX_STOP_CONT:
>> + ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
>> + break;
>> + case IEEE80211_AMPDU_TX_STOP_FLUSH:
>> + case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
>> + break;
>
> You can't just "not support" them - you have to at least stop the
> aggregation session, see the commit that introduced this.
>
Good point. Will fix this in the next round.
>> + static const u32 cipher_suites[] = {
>> + WLAN_CIPHER_SUITE_TKIP,
>> + WLAN_CIPHER_SUITE_CCMP,
>> + };
>
> You actually don't want to support WEP, not even in software? Otherwise
> just leave this out and mac80211 will add it.
WEP is supported by HW but wcn36xx does not configure it yet. Is that
ok to add HW WEP encryption in nearest future after wcn36xx is pushed
to upstream?
>> + wcn->hw->wiphy->iface_combinations = &if_comb;
>> + wcn->hw->wiphy->n_iface_combinations = 1;
>
> Your code with "wcn->current_vif = " etc. *really* doesn't look like you
> support combinations. Are you positive this is OK?
So far wcn36xx supports only one interface at once. But in the nearest
future it will definitely support more than one. So how about keeping
this for future?;)
>> + wcn->hw->wiphy->max_scan_ssids = 1;
>
> Really? You don't even have hardware scan, so why?
>
Good catch. wcn36xx used to have hw scan but now it is moved to sw
scan. Will remove this completely.
> johannes
>
--
Best regards,
Eugene
^ permalink raw reply
* [PATCH 3.11] iwl4965: fix rfkill set state regression
From: Stanislaw Gruszka @ 2013-08-21 8:18 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Stanislaw Gruszka
My current 3.11 fix:
commit 788f7a56fce1bcb2067b62b851a086fca48a0056
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Thu Aug 1 12:07:55 2013 +0200
iwl4965: reset firmware after rfkill off
broke rfkill notification to user-space . I missed that bug, because
I compiled without CONFIG_RFKILL, sorry about that.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlegacy/4965-mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index f2ed62e..7acf5ee 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -4464,9 +4464,9 @@ il4965_irq_tasklet(struct il_priv *il)
set_bit(S_RFKILL, &il->status);
} else {
clear_bit(S_RFKILL, &il->status);
- wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill);
il_force_reset(il, true);
}
+ wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill);
handled |= CSR_INT_BIT_RF_KILL;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 09/16] wcn36xx: Add smd.c
From: Johannes Berg @ 2013-08-21 8:15 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: Joe Perches, linux-wireless, wcn36xx
In-Reply-To: <CAFSJ42ZMk6sN6povWHkSodk0J7pBvyak8sH-MqNXVhi_iSmq9Q@mail.gmail.com>
On Wed, 2013-08-21 at 09:58 +0200, Eugene Krasnikov wrote:
> 2013/8/20 Joe Perches <joe@perches.com>:
> > On Tue, 2013-08-20 at 19:41 +0200, Eugene Krasnikov wrote:
> >
> >> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> > []
> >> +int wcn36xx_smd_load_nv(struct wcn36xx *wcn)
> >> +{
> > []
> >> + /* Add NV body itself */
> >> + /* Rework me */
> >> + memcpy(wcn->smd_buf + sizeof(msg_body),
> >> + (void *)(&nv_d->table) + fm_offset,
> >> + msg_body.nv_img_buffer_size);
> >
> > Does this really do what you want?
> >
> > Perhaps it should be:
> >
> > memcpy(wcn->smd_buf + sizeof(msg_body),
> > ((void *)&nv_d->table) + fm_offset,
> > msg_body.nv_img_buffer_size);
> >
>
> Yes, this line is working. Tested it for ARM. Do you see any potential
> problems with this pointer operation?
It should really be u8* instead of void*, since void* pointer arithmetic
isn't really defined I think?
Other than that, this was just about precedence rules, and casts have a
higher precedence.
johannes
^ permalink raw reply
* Re: [PATCH 09/16] wcn36xx: Add smd.c
From: Eugene Krasnikov @ 2013-08-21 7:58 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377022333.2016.59.camel@joe-AO722>
2013/8/20 Joe Perches <joe@perches.com>:
> On Tue, 2013-08-20 at 19:41 +0200, Eugene Krasnikov wrote:
>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> []
>> +int wcn36xx_smd_load_nv(struct wcn36xx *wcn)
>> +{
> []
>> + /* Add NV body itself */
>> + /* Rework me */
>> + memcpy(wcn->smd_buf + sizeof(msg_body),
>> + (void *)(&nv_d->table) + fm_offset,
>> + msg_body.nv_img_buffer_size);
>
> Does this really do what you want?
>
> Perhaps it should be:
>
> memcpy(wcn->smd_buf + sizeof(msg_body),
> ((void *)&nv_d->table) + fm_offset,
> msg_body.nv_img_buffer_size);
>
Yes, this line is working. Tested it for ARM. Do you see any potential
problems with this pointer operation?
--
Best regards,
Eugene
^ permalink raw reply
* Re: [PATCH 13/16] wcn36xx: Add wcn36xx.h
From: Eugene Krasnikov @ 2013-08-21 7:55 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377021890.2016.55.camel@joe-AO722>
Hi Joe,
Thank you very much for your comments.
Please find my comments bellow:
>> Adding wcn36xx.h
> []
>> +#define DRIVER_PREFIX "wcn36xx: "
> []
>
> I think you should use pr_fmt and/or netdev_<level>
Thanx, will add pr_fmt in the next round.
>> +#define wcn36xx_error(fmt, arg...) do { \
>> + pr_err(DRIVER_PREFIX "ERROR " fmt "\n", ##arg); \
>> + __WARN(); \
>> +} while (0)
>
> What value is there in this __WARN?
This warn is there just to scream louder every time when error happens:)
> Please use _err rather than _error
Thanx, will fix in the next patch set.
>> +#define wcn36xx_warn(fmt, arg...) \
>> + pr_warn(DRIVER_PREFIX "WARNING " fmt "\n", ##arg)
>> +
>> +#define wcn36xx_info(fmt, arg...) \
>> + pr_info(DRIVER_PREFIX fmt "\n", ##arg)
>> +
>> +#define wcn36xx_dbg(mask, fmt, arg...) do { \
>> + if (debug_mask & mask) \
>> + pr_debug(DRIVER_PREFIX fmt "\n", ##arg); \
>> +} while (0)
>> +
>> +#define wcn36xx_dbg_dump(mask, prefix_str, buf, len) do { \
>> + if (debug_mask & mask) \
>> + print_hex_dump(KERN_DEBUG, prefix_str, \
>> + DUMP_PREFIX_OFFSET, 32, 1, \
>> + buf, len, false); \
>> +} while (0)
>> +
>
> Please move the "\n" to the uses instead of the macro.
> This would be consistent with all the other ath macros.
Thanx, will fix in the next patch set.
--
Best regards,
Eugene
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox