* [PATCH v3 6/6] mac80211: process mesh channel switching using beacon
From: Chun-Yeow Yeoh @ 2013-10-03 0:33 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, devel, distro11s, Chun-Yeow Yeoh
In-Reply-To: <1380760429-26100-1-git-send-email-yeohchunyeow@cozybit.com>
Trigger the mesh channel switching procedure if the mesh STA
happens to miss the CSA action frame but able to receive the
beacon containing the CSA and MCSP elements from its peer
mesh STAs.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
---
v2: fix return value (Johannes Berg)
net/mac80211/mesh.c | 132 +++++++++++++++++++++++++++++++++++++++++++---
net/mac80211/spectmgmt.c | 6 +++
2 files changed, 130 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 21723ba..ae11134 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -851,6 +851,124 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data *sdata)
ieee80211_configure_filter(local);
}
+static bool
+ieee80211_mesh_process_chnswitch(struct ieee80211_sub_if_data *sdata,
+ struct ieee802_11_elems *elems, bool beacon)
+{
+ struct cfg80211_csa_settings params;
+ struct ieee80211_csa_ie csa_ie;
+ struct ieee80211_chanctx_conf *chanctx_conf;
+ struct ieee80211_chanctx *chanctx;
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ enum ieee80211_band band = ieee80211_get_sdata_band(sdata);
+ int err, num_chanctx;
+ u32 sta_flags;
+
+ if (sdata->vif.csa_active)
+ return true;
+
+ if (!ifmsh->mesh_id)
+ return false;
+
+ sta_flags = IEEE80211_STA_DISABLE_VHT;
+ switch (sdata->vif.bss_conf.chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ sta_flags |= IEEE80211_STA_DISABLE_HT;
+ case NL80211_CHAN_WIDTH_20:
+ sta_flags |= IEEE80211_STA_DISABLE_40MHZ;
+ break;
+ default:
+ break;
+ }
+
+ memset(¶ms, 0, sizeof(params));
+ memset(&csa_ie, 0, sizeof(csa_ie));
+ err = ieee80211_parse_ch_switch_ie(sdata, elems, beacon, band,
+ sta_flags, sdata->vif.addr,
+ &csa_ie);
+ if (err < 0)
+ return false;
+ if (err)
+ return false;
+
+ params.chandef = csa_ie.chandef;
+ params.count = csa_ie.count;
+
+ if (sdata->vif.bss_conf.chandef.chan->band !=
+ params.chandef.chan->band)
+ return false;
+
+ if (!cfg80211_chandef_usable(sdata->local->hw.wiphy, ¶ms.chandef,
+ IEEE80211_CHAN_DISABLED)) {
+ sdata_info(sdata,
+ "mesh STA %pM switches to unsupported channel (%d MHz, width:%d, CF1/2: %d/%d MHz), aborting\n",
+ sdata->vif.addr,
+ params.chandef.chan->center_freq,
+ params.chandef.width,
+ params.chandef.center_freq1,
+ params.chandef.center_freq2);
+ return false;
+ }
+
+ err = cfg80211_chandef_dfs_required(sdata->local->hw.wiphy,
+ ¶ms.chandef);
+ if (err < 0)
+ return false;
+ if (err) {
+ params.radar_required = true;
+ /* TODO: DFS not (yet) supported */
+ return false;
+ }
+
+ rcu_read_lock();
+ chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
+ if (!chanctx_conf)
+ goto failed_chswitch;
+
+ /* don't handle for multi-VIF cases */
+ chanctx = container_of(chanctx_conf, struct ieee80211_chanctx, conf);
+ if (chanctx->refcount > 1)
+ goto failed_chswitch;
+
+ num_chanctx = 0;
+ list_for_each_entry_rcu(chanctx, &sdata->local->chanctx_list, list)
+ num_chanctx++;
+
+ if (num_chanctx > 1)
+ goto failed_chswitch;
+
+ rcu_read_unlock();
+
+ mcsa_dbg(sdata,
+ "received channel switch announcement to go to channel %d MHz\n",
+ params.chandef.chan->center_freq);
+
+ params.block_tx = csa_ie.mode & WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT;
+ if (beacon)
+ ifmsh->chsw_ttl = csa_ie.ttl - 1;
+
+ if (ifmsh->chsw_ttl > 0)
+ ieee80211_mesh_csa_beacon(sdata, ¶ms, false);
+
+ sdata->csa_radar_required = params.radar_required;
+
+ if (params.block_tx)
+ ieee80211_stop_queues_by_reason(&sdata->local->hw,
+ IEEE80211_MAX_QUEUE_MAP,
+ IEEE80211_QUEUE_STOP_REASON_CSA);
+
+ sdata->local->csa_chandef = params.chandef;
+ sdata->vif.csa_active = true;
+
+ ieee80211_bss_info_change_notify(sdata, err);
+ drv_channel_switch_beacon(sdata, ¶ms.chandef);
+
+ return true;
+failed_chswitch:
+ rcu_read_unlock();
+ return false;
+}
+
static void
ieee80211_mesh_rx_probe_req(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt, size_t len)
@@ -957,6 +1075,9 @@ static void ieee80211_mesh_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
if (ifmsh->sync_ops)
ifmsh->sync_ops->rx_bcn_presp(sdata,
stype, mgmt, &elems, rx_status);
+
+ if (!ifmsh->chsw_init)
+ ieee80211_mesh_process_chnswitch(sdata, &elems, true);
}
int ieee80211_mesh_finish_csa(struct ieee80211_sub_if_data *sdata)
@@ -1052,7 +1173,7 @@ static void mesh_rx_csa_frame(struct ieee80211_sub_if_data *sdata,
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
struct ieee802_11_elems elems;
u16 pre_value;
- bool block_tx, fwd_csa = true;
+ bool fwd_csa = true;
size_t baselen;
u8 *pos, ttl;
@@ -1081,13 +1202,8 @@ static void mesh_rx_csa_frame(struct ieee80211_sub_if_data *sdata,
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
- /* block the Tx only after forwarding the CSA frame if required */
- block_tx = elems.mesh_chansw_params_ie->mesh_flags &
- WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT;
- if (block_tx)
- ieee80211_stop_queues_by_reason(&sdata->local->hw,
- IEEE80211_MAX_QUEUE_MAP,
- IEEE80211_QUEUE_STOP_REASON_CSA);
+ if (!ieee80211_mesh_process_chnswitch(sdata, &elems, false))
+ mcsa_dbg(sdata, "Failed to process CSA action frame");
}
static void ieee80211_mesh_rx_mgmt_action(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/spectmgmt.c b/net/mac80211/spectmgmt.c
index a298e12..a40da20 100644
--- a/net/mac80211/spectmgmt.c
+++ b/net/mac80211/spectmgmt.c
@@ -74,6 +74,12 @@ int ieee80211_parse_ch_switch_ie(struct ieee80211_sub_if_data *sdata,
return 1;
}
+ /* 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;
+ }
+
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) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] cfg80211: enable regulatory hints for strict custom settings
From: Luis R. Rodriguez @ 2013-10-03 1:33 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luis R. Rodriguez, smihir, tushnimb
If we have a wiphy with an ISO3166-alpha2 regulatory domain
programmed with the strict flag set we wait until the wiphy
gets its wiphy->regd programmed before allowing regulatory
domains hints other than country IE hints from processing
on the wiphy. The existing check however discards the
possibility of custom regulatory domains having also used
the strict flag and these will not have the wiphy->regd
set. Custom strict regulatory domains never set the wiphy->regd
though as such currently all regulatory hints other than
country IE hints are being ignored on these wiphys.
All custom strict regulatory domains set the wiphy with the
WIPHY_FLAG_CUSTOM_REGULATORY and use wiphy_apply_custom_regulatory().
Enhance the check for the strict ISO3166-alpha2 regulatory domain
case by exempting the WIPHY_FLAG_CUSTOM_REGULATORY case. This
will enable other regulatory hints to be processed now for
these strict custom regulatory domains.
Cc: smihir@qti.qualcomm.com
Cc: tushnimb@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
net/wireless/reg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5164716..9b488c7 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -992,6 +992,7 @@ static bool ignore_reg_update(struct wiphy *wiphy,
*/
if (wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY && !wiphy->regd &&
initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE &&
+ !(wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY) &&
!is_world_regdom(lr->alpha2)) {
REG_DBG_PRINT("Ignoring regulatory request set by %s "
"since the driver requires its own regulatory "
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 2/2] cfg80211: simplfy strict custom alpha2 regdomain check
From: Luis R. Rodriguez @ 2013-10-03 1:33 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luis R. Rodriguez, smihir, tushnimb
In-Reply-To: <1380763990-5981-1-git-send-email-mcgrof@do-not-panic.com>
This makes it easier to read.
Cc: smihir@qti.qualcomm.com
Cc: tushnimb@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
net/wireless/reg.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9b488c7..ec3d45e 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -964,6 +964,13 @@ static bool reg_dev_ignore_cell_hint(struct wiphy *wiphy)
}
#endif
+static bool wiphy_strict_alpha2_regd(struct wiphy *wiphy)
+{
+ if (wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY &&
+ !(wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY))
+ return true;
+ return false;
+}
static bool ignore_reg_update(struct wiphy *wiphy,
enum nl80211_reg_initiator initiator)
@@ -990,9 +997,8 @@ static bool ignore_reg_update(struct wiphy *wiphy,
* wiphy->regd will be set once the device has its own
* desired regulatory domain set
*/
- if (wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY && !wiphy->regd &&
+ if (wiphy_strict_alpha2_regd(wiphy) && !wiphy->regd &&
initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE &&
- !(wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY) &&
!is_world_regdom(lr->alpha2)) {
REG_DBG_PRINT("Ignoring regulatory request set by %s "
"since the driver requires its own regulatory "
--
1.8.4.rc3
^ permalink raw reply related
* RE: [PATCH] cfg80211: Pass station supported channel and oper class info to kernel
From: Undekari, Sunil Dutt @ 2013-10-03 7:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, j@w1.fi
In-Reply-To: <1380704456.13329.8.camel@jlt4.sipsolutions.net>
VGhhbmtzIEpvaGFubmVzIGZvciB0aGUgcmV2aWV3Lg0KDQo+SXQgc2VlbXMgeW91IHNob3VsZCB2
YWxpZGF0ZSB0aGF0IHRoZSBsZW5ndGggaXMgZXZlbiwgYW5kIGF0IGxlYXN0IDI/DQpDYW4gSSBr
bm93IHdoeSB0aGUgY2hlY2sgZm9yIGV2ZW4vIGF0bGVhc3QgMiBpcz8gVGhvdWdoIEkgd291bGQg
dmFsaWRhdGUgZm9yIGEgbm9uIHplcm8gbGVuZ3RoIGFuZCByZXR1cm4gZmFpbHVyZSBpbiB0aGUg
ZWxzZSwgY29uc2lkZXJpbmcgYSBjYXNlIHdoZXJlIHRoZSBURExTIHBlZXIgYWR2ZXJ0aXNlcyBh
IHNpbmdsZSBjaGFubmVsLiBTaG91bGRuJ3QgaXQgc3VmZmljZT8NCg0KPiBEb2VzIHRoaXMgZXZl
biBtYWtlIHNlbnNlIGluIHNldF9zdGF0aW9uKCkgcmF0aGVyIHRoYW4gb25seSBuZXdfc3RhdGlv
bigpPw0KSSB3b3VsZCBoYXZlIHRoaXMgaW4gYm90aCBuZXdfc3RhdGlvbiBhbmQgc2V0X3N0YXRp
b24uIENvbnNpZGVyaW5nIHRoZSBjdXJyZW50IGJlaGF2aW9yIG9mIHRoZSBzdXBwbGljYW50IHdo
ZXJlIG5ld19zdGF0aW9uIGFuZCBzZXRfc3RhdGlvbiBhcmUgaW52b2tlZCBiZWZvcmUgYW5kIGFm
dGVyIHRoZSBUUEsgaGFuZHNoYWtlLCBpdCB3b3VsZCBiZSBmaW5lIHRvIGhhdmUgb25seSBpbiBz
ZXRfc3RhdGlvbiBidXQgSSBzdXBwb3NlIE5MIGNoYW5nZXMgc2hvdWxkIG5vdCByZWx5IG9uIHN1
cHBsaWNhbnQncyBiZWhhdmlvci4NCg0KUmVnYXJkcywNClN1bmlsDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogSm9oYW5uZXMgQmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0
aW9ucy5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDAyLCAyMDEzIDI6MzEgUE0NClRv
OiBVbmRla2FyaSwgU3VuaWwgRHV0dA0KQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9y
ZzsgakB3MS5maQ0KU3ViamVjdDogUmU6IFtQQVRDSF0gY2ZnODAyMTE6IFBhc3Mgc3RhdGlvbiBz
dXBwb3J0ZWQgY2hhbm5lbCBhbmQgb3BlciBjbGFzcyBpbmZvIHRvIGtlcm5lbA0KDQpPbiBUdWUs
IDIwMTMtMDgtMjcgYXQgMTE6MTQgKzA1MzAsIFN1bmlsIER1dHQgd3JvdGU6DQoNCj4gKwlpZiAo
aW5mby0+YXR0cnNbTkw4MDIxMV9BVFRSX1NUQV9TVVBQT1JURURfQ0hBTk5FTFNdKSB7DQo+ICsJ
CXBhcmFtcy0+c3VwcG9ydGVkX2NoYW5uZWxzID0NCj4gKwkJICAgICBubGFfZGF0YShpbmZvLT5h
dHRyc1tOTDgwMjExX0FUVFJfU1RBX1NVUFBPUlRFRF9DSEFOTkVMU10pOw0KPiArCQlwYXJhbXMt
PnN1cHBvcnRlZF9jaGFubmVsc19sZW4gPQ0KPiArCQkgICAgIG5sYV9sZW4oaW5mby0+YXR0cnNb
Tkw4MDIxMV9BVFRSX1NUQV9TVVBQT1JURURfQ0hBTk5FTFNdKTsNCg0KSXQgc2VlbXMgeW91IHNo
b3VsZCB2YWxpZGF0ZSB0aGF0IHRoZSBsZW5ndGggaXMgZXZlbiwgYW5kIGF0IGxlYXN0IDI/DQoN
Cj4gKwlpZiAoaW5mby0+YXR0cnNbTkw4MDIxMV9BVFRSX1NUQV9TVVBQT1JURURfT1BFUl9DTEFT
U0VTXSkgew0KPiArCQlwYXJhbXMtPnN1cHBvcnRlZF9vcGVyX2NsYXNzZXMgPQ0KPiArCQkgbmxh
X2RhdGEoaW5mby0+YXR0cnNbTkw4MDIxMV9BVFRSX1NUQV9TVVBQT1JURURfT1BFUl9DTEFTU0VT
XSk7DQo+ICsJCXBhcmFtcy0+c3VwcG9ydGVkX29wZXJfY2xhc3Nlc19sZW4gPQ0KPiArCQkgIG5s
YV9sZW4oaW5mby0+YXR0cnNbTkw4MDIxMV9BVFRSX1NUQV9TVVBQT1JURURfT1BFUl9DTEFTU0VT
XSk7DQoNClNpbWlsYXJseSBoZXJlICh3aXRoIGRpZmZlcmVudCBydWxlcykNCg0KRG9lcyB0aGlz
IGV2ZW4gbWFrZSBzZW5zZSBpbiBzZXRfc3RhdGlvbigpIHJhdGhlciB0aGFuIG9ubHkgbmV3X3N0
YXRpb24oKT8NCg0Kam9oYW5uZXMNCg0K
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: remove duplicate rf_vals for RF3053.
From: Kevin Lo @ 2013-10-03 7:48 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users
We already have rf_vals_3x with same values. Hence rf_vals_3053 is removed
in this patch.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
---
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index f414978..deb8a01 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -7416,72 +7416,6 @@ static const struct rf_channel
rf_vals_5592_xtal40[] = {
{196, 83, 0, 12, 1},
};
-static const struct rf_channel rf_vals_3053[] = {
- /* Channel, N, R, K */
- {1, 241, 2, 2},
- {2, 241, 2, 7},
- {3, 242, 2, 2},
- {4, 242, 2, 7},
- {5, 243, 2, 2},
- {6, 243, 2, 7},
- {7, 244, 2, 2},
- {8, 244, 2, 7},
- {9, 245, 2, 2},
- {10, 245, 2, 7},
- {11, 246, 2, 2},
- {12, 246, 2, 7},
- {13, 247, 2, 2},
- {14, 248, 2, 4},
-
- {36, 0x56, 0, 4},
- {38, 0x56, 0, 6},
- {40, 0x56, 0, 8},
- {44, 0x57, 0, 0},
- {46, 0x57, 0, 2},
- {48, 0x57, 0, 4},
- {52, 0x57, 0, 8},
- {54, 0x57, 0, 10},
- {56, 0x58, 0, 0},
- {60, 0x58, 0, 4},
- {62, 0x58, 0, 6},
- {64, 0x58, 0, 8},
-
- {100, 0x5B, 0, 8},
- {102, 0x5B, 0, 10},
- {104, 0x5C, 0, 0},
- {108, 0x5C, 0, 4},
- {110, 0x5C, 0, 6},
- {112, 0x5C, 0, 8},
-
- /* NOTE: Channel 114 has been removed intentionally.
- * The EEPROM contains no TX power values for that,
- * and it is disabled in the vendor driver as well.
- */
-
- {116, 0x5D, 0, 0},
- {118, 0x5D, 0, 2},
- {120, 0x5D, 0, 4},
- {124, 0x5D, 0, 8},
- {126, 0x5D, 0, 10},
- {128, 0x5E, 0, 0},
- {132, 0x5E, 0, 4},
- {134, 0x5E, 0, 6},
- {136, 0x5E, 0, 8},
- {140, 0x5F, 0, 0},
-
- {149, 0x5F, 0, 9},
- {151, 0x5F, 0, 11},
- {153, 0x60, 0, 1},
- {157, 0x60, 0, 5},
- {159, 0x60, 0, 7},
- {161, 0x60, 0, 9},
- {165, 0x61, 0, 1},
- {167, 0x61, 0, 3},
- {169, 0x61, 0, 5},
- {171, 0x61, 0, 7},
- {173, 0x61, 0, 9},
-};
-
static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
{
struct hw_mode_spec *spec = &rt2x00dev->spec;
@@ -7570,14 +7504,11 @@ static int rt2800_probe_hw_mode(struct
rt2x00_dev *rt2x00dev)
rt2x00_rf(rt2x00dev, RF5392)) {
spec->num_channels = 14;
spec->channels = rf_vals_3x;
- } else if (rt2x00_rf(rt2x00dev, RF3052)) {
+ } else if (rt2x00_rf(rt2x00dev, RF3052) ||
+ rt2x00_rf(rt2x00dev, RF3053)) {
spec->supported_bands |= SUPPORT_BAND_5GHZ;
spec->num_channels = ARRAY_SIZE(rf_vals_3x);
spec->channels = rf_vals_3x;
- } else if (rt2x00_rf(rt2x00dev, RF3053)) {
- spec->supported_bands |= SUPPORT_BAND_5GHZ;
- spec->num_channels = ARRAY_SIZE(rf_vals_3053);
- spec->channels = rf_vals_3053;
} else if (rt2x00_rf(rt2x00dev, RF5592)) {
spec->supported_bands |= SUPPORT_BAND_5GHZ;
^ permalink raw reply related
* Re: [rt2x00-users] [PATCH 1/2] rt2x00: rt2800lib: remove TXMIXER_GAIN entries from the extended EEPROM map
From: Paul Menzel @ 2013-10-03 8:38 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1380742914-22486-1-git-send-email-juhosg@openwrt.org>
[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]
Dear Gabor,
thank you for the patch!
Am Mittwoch, den 02.10.2013, 21:41 +0200 schrieb Gabor Juhos:
> The comments are indicating the TXMIXER_GAIN_BG and
> the TXMIXED_GAIN_A entries are overlapping with the
(I think if you use »the« twice, it is just singular »entry«.)
> RSSI_BG2 and RSSI_A2 entries in the extended EEPROM
> map. This is not correct, becuase the upper byte of
bec*au*se
> the RSSI_BG2 and RSSI_A2 entries are reserved. There
> are no TX mixer gain values are stored at all in the
> extended EEPROM.
>
> Remove the initialization of these entries from the
> extended EEPROM map to reflect this.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index c706ddc..c979bb7 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -280,10 +280,8 @@ static const unsigned int rt2800_eeprom_map_ext[EEPROM_WORD_COUNT] = {
> [EEPROM_RSSI_BG] = 0x0028,
> [EEPROM_TXPOWER_DELTA] = 0x0028, /* Overlaps with RSSI_BG */
> [EEPROM_RSSI_BG2] = 0x0029,
> - [EEPROM_TXMIXER_GAIN_BG] = 0x0029, /* Overlaps with RSSI_BG2 */
> [EEPROM_RSSI_A] = 0x002a,
> [EEPROM_RSSI_A2] = 0x002b,
> - [EEPROM_TXMIXER_GAIN_A] = 0x002b, /* Overlaps with RSSI_A2 */
> [EEPROM_TXPOWER_BG1] = 0x0030,
> [EEPROM_TXPOWER_BG2] = 0x0037,
> [EEPROM_EXT_TXPOWER_BG3] = 0x003e,
Do you know if this fixes any problems and should be backported to
stable? If any testing can be done on
idVendor 0x148f Ralink Technology, Corp.
idProduct 0x2870 RT2870 Wireless Adapter
please tell me.
With the fixes above,
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 2/2] rt2x00: rt2800lib: remove TXPOWER_DELTA entry from extended EEPROM map
From: Paul Menzel @ 2013-10-03 8:40 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1380742914-22486-2-git-send-email-juhosg@openwrt.org>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
Am Mittwoch, den 02.10.2013, 21:41 +0200 schrieb Gabor Juhos:
> The TXPOWER_DELTA field of the regular EEPROM
> stores the TX power compensation value for HT40.
> The extended EEPROM has no such field, it stores
> separate TX power values for HT20 and for HT40.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 1 -
> 1 file changed, 1 deletion(-)
[…]
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [rt2x00-users] [PATCH] rt2x00: rt2800lib: remove duplicate rf_vals for RF3053.
From: Paul Menzel @ 2013-10-03 8:42 UTC (permalink / raw)
To: Kevin Lo; +Cc: John Linville, linux-wireless, users
In-Reply-To: <524D2139.4000608@kevlo.org>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
Am Donnerstag, den 03.10.2013, 15:48 +0800 schrieb Kevin Lo:
> We already have rf_vals_3x with same values. Hence rf_vals_3053 is removed
> in this patch.
>
> Signed-off-by: Kevin Lo <kevlo@kevlo.org>
> ---
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
> b/drivers/net/wireless/rt2x00/rt2800lib.c
[…]
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: Sedat Dilek @ 2013-10-03 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, wireless
In-Reply-To: <1380612524.14430.0.camel@jlt4.sipsolutions.net>
On Tue, Oct 1, 2013 at 9:28 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2013-09-30 at 16:32 -0400, John W. Linville wrote:
>> On Mon, Sep 30, 2013 at 11:07:54AM +0200, Johannes Berg wrote:
>> > On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
>> > > From: Johannes Berg <johannes.berg@intel.com>
>> > >
>> > > The merge b35c8097 seems to have lost commit eabc4ac5d,
>> > > put the code back.
>> > >
>> > > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>> >
>> > Ah, forgot to say - John, I think you should apply this as a patch,
>> > having it in my pull request seems odd. But if you're of another opinion
>> > I can stick it into my next -next pull request too.
>>
>> OK -- does this need to be treated as a fix? Or is -next OK?
>
> I believe the merge damage only occurred during merging wireless.git (or
> one of its upstreams) into wireless-next.git.
>
Hmm, this patch applies also for Linux v3.12-rc3+, so you are sure it
is not for iwlwifi-3.12-fixes?
- Sedat -
^ permalink raw reply
* Re: [PATCH 0/7] brcmfmac: cleanup and new device support
From: Arend van Spriel @ 2013-10-03 11:25 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1380107146-24026-1-git-send-email-arend@broadcom.com>
On 09/25/2013 01:05 PM, Arend van Spriel wrote:
> This series has a few cleanup patches fixing a sparse error, cleaning
> up the rx path and also changing the firmware filename approach after
> getting feedback on this by Stephen Warren. The remaining patches are
> adding support for the BCM4339 SDIO chipset.
>
> This series is intended for v3.13 kernel and applies to the master
> branch of the wireless-next repository.
Hi John,
Did you miss this series from last week?
Regards,
Arend
> Arend van Spriel (2):
> brcmfmac: fix sparse error 'bad constant expression'
> brcmfmac: rework rx path bus interface
>
> Franky Lin (4):
> brcmfmac: sync firmware event list
> brcmfmac: add BCM4339 SDIO interface support
> brcmfmac: add valid core index check in related functions
> brcmfmac: reserve memory for bus layer in sk_buff::cb
>
> Hante Meuleman (1):
> brcmfmac: Use fw filename and nvram based of devid for sdio.
>
> .../net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 11 +-
> drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 2 -
> drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h | 2 +-
> .../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 38 ++--
> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 234 ++++++++++++--------
> drivers/net/wireless/brcm80211/brcmfmac/fweh.h | 5 +-
> drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 2 +
> .../net/wireless/brcm80211/brcmfmac/sdio_chip.c | 28 +++
> .../net/wireless/brcm80211/brcmfmac/sdio_chip.h | 8 +
> drivers/net/wireless/brcm80211/brcmfmac/usb.c | 5 +-
> .../net/wireless/brcm80211/include/brcm_hw_ids.h | 1 +
> 11 files changed, 211 insertions(+), 125 deletions(-)
>
^ permalink raw reply
* [PATCH 1/3] bcma: reject PCI cards in bcma.
From: Hauke Mehrtens @ 2013-10-03 11:49 UTC (permalink / raw)
To: linville
Cc: linux-wireless, zajec5, arend, brcm80211-dev-list, jogo,
Hauke Mehrtens
bcma currently only supports PCIe cards and no PCI cards, reject them
if we find them. I have never heard of any PCI card using the AI bus
(bcma), all of them are using ssb instead.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/bcma/host_pci.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index a355e63..a1caf9c 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -188,8 +188,11 @@ static int bcma_host_pci_probe(struct pci_dev *dev,
pci_write_config_dword(dev, 0x40, val & 0xffff00ff);
/* SSB needed additional powering up, do we have any AMBA PCI cards? */
- if (!pci_is_pcie(dev))
- bcma_err(bus, "PCI card detected, report problems.\n");
+ if (!pci_is_pcie(dev)) {
+ bcma_err(bus, "PCI card detected, they are not supported.\n");
+ err = -ENXIO;
+ goto err_pci_release_regions;
+ }
/* Map MMIO */
err = -ENOMEM;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] bcma: add PCI id 0x4313
From: Hauke Mehrtens @ 2013-10-03 11:49 UTC (permalink / raw)
To: linville
Cc: linux-wireless, zajec5, arend, brcm80211-dev-list, jogo,
Hauke Mehrtens
In-Reply-To: <1380800951-28643-1-git-send-email-hauke@hauke-m.de>
This PCI id is used by some BCM4313 cards without a sprom. I have seen
such a card on a router connected to some BCM63XX SoC via PCIe. There
are cards out there with the same PCI id and a BCM4311, which is a pre
ieee80211n chip only supporting ieee80211a, these are still not
supported by b43 and not detected by ssb.
This devices was found by someone in this ticket:
https://dev.openwrt.org/ticket/13551
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/bcma/host_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index a1caf9c..6fb98b5 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -272,6 +272,7 @@ static SIMPLE_DEV_PM_OPS(bcma_pm_ops, bcma_host_pci_suspend,
static DEFINE_PCI_DEVICE_TABLE(bcma_pci_bridge_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x0576) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4313) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 43224) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4331) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4353) },
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] brcmsmac: add support for a BCM4313 with PCI id 0x4313
From: Hauke Mehrtens @ 2013-10-03 11:49 UTC (permalink / raw)
To: linville
Cc: linux-wireless, zajec5, arend, brcm80211-dev-list, jogo,
Hauke Mehrtens
In-Reply-To: <1380800951-28643-1-git-send-email-hauke@hauke-m.de>
There are some BCM4313 out there with a PCI id of 0x4313. These devices
are missing a sprom and are only used on routers or other embedded
devices. We found one connected to a BCM63XX SoC.
This devices was found by someone in this ticket:
https://dev.openwrt.org/ticket/13551
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 4608e0e..df6229e 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -5695,7 +5695,7 @@ static bool brcms_c_chipmatch_pci(struct bcma_device *core)
return true;
if ((device == BCM43224_D11N_ID) || (device == BCM43225_D11N2G_ID))
return true;
- if (device == BCM4313_D11N2G_ID)
+ if (device == BCM4313_D11N2G_ID || device == BCM4313_CHIP_ID)
return true;
if ((device == BCM43236_D11N_ID) || (device == BCM43236_D11N2G_ID))
return true;
--
1.7.10.4
^ permalink raw reply related
* Re: [rt2x00-users] [PATCH 1/2] rt2x00: rt2800lib: remove TXMIXER_GAIN entries from the extended EEPROM map
From: Gabor Juhos @ 2013-10-03 12:05 UTC (permalink / raw)
To: Paul Menzel; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1380789509.8125.6.camel@mattotaupa>
Dear Paul,
<...>
>> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
>> index c706ddc..c979bb7 100644
>> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
>> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
>> @@ -280,10 +280,8 @@ static const unsigned int rt2800_eeprom_map_ext[EEPROM_WORD_COUNT] = {
>> [EEPROM_RSSI_BG] = 0x0028,
>> [EEPROM_TXPOWER_DELTA] = 0x0028, /* Overlaps with RSSI_BG */
>> [EEPROM_RSSI_BG2] = 0x0029,
>> - [EEPROM_TXMIXER_GAIN_BG] = 0x0029, /* Overlaps with RSSI_BG2 */
>> [EEPROM_RSSI_A] = 0x002a,
>> [EEPROM_RSSI_A2] = 0x002b,
>> - [EEPROM_TXMIXER_GAIN_A] = 0x002b, /* Overlaps with RSSI_A2 */
>> [EEPROM_TXPOWER_BG1] = 0x0030,
>> [EEPROM_TXPOWER_BG2] = 0x0037,
>> [EEPROM_EXT_TXPOWER_BG3] = 0x003e,
>
> Do you know if this fixes any problems and should be backported to
> stable?
This is a cleanup patch, it does not fix any problem. The removed entries are
not used by the code at all.
> If any testing can be done on
>
> idVendor 0x148f Ralink Technology, Corp.
> idProduct 0x2870 RT2870 Wireless Adapter
>
> please tell me.
The extended EEPROM map is used only for the RT3593 chipset, it does not affect
RT2870 in any way.
>
> With the fixes above,
>
> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Thank you for the review! I will send an updated version.
-Gabor
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: remove duplicate rf_vals for RF3053.
From: Gabor Juhos @ 2013-10-03 12:06 UTC (permalink / raw)
To: Kevin Lo; +Cc: John Linville, linux-wireless, users
In-Reply-To: <524D2139.4000608@kevlo.org>
2013.10.03. 9:48 keltezéssel, Kevin Lo írta:
> We already have rf_vals_3x with same values. Hence rf_vals_3053 is removed
> in this patch.
>
> Signed-off-by: Kevin Lo <kevlo@kevlo.org>
For completeness, the comment of rf_vals_3x should be updated to indicate that
it also supports RF3053. Otherwise the patch is fine.
-Gabor
^ permalink raw reply
* [PATCH v2 2/2] rt2x00: rt2800lib: remove TXPOWER_DELTA entry from extended EEPROM map
From: Gabor Juhos @ 2013-10-03 12:07 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Paul Menzel, Gabor Juhos
In-Reply-To: <1380802022-28646-1-git-send-email-juhosg@openwrt.org>
The TXPOWER_DELTA field of the regular EEPROM
stores the TX power compensation value for HT40.
The extended EEPROM has no such field, it stores
separate TX power values for HT20 and for HT40.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
---
Changes since v1:
- add Paul's Acked-by tag
---
drivers/net/wireless/rt2x00/rt2800lib.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c979bb7..315f4af 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -278,7 +278,6 @@ static const unsigned int rt2800_eeprom_map_ext[EEPROM_WORD_COUNT] = {
[EEPROM_LNA] = 0x0026,
[EEPROM_EXT_LNA2] = 0x0027,
[EEPROM_RSSI_BG] = 0x0028,
- [EEPROM_TXPOWER_DELTA] = 0x0028, /* Overlaps with RSSI_BG */
[EEPROM_RSSI_BG2] = 0x0029,
[EEPROM_RSSI_A] = 0x002a,
[EEPROM_RSSI_A2] = 0x002b,
--
1.7.10
^ permalink raw reply related
* [PATCH v2 1/2] rt2x00: rt2800lib: remove TXMIXER_GAIN entries from the extended EEPROM map
From: Gabor Juhos @ 2013-10-03 12:07 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Paul Menzel, Gabor Juhos
The comments are indicating that the TXMIXER_GAIN_BG
and TXMIXED_GAIN_A entries are overlapping with the
RSSI_BG2 and RSSI_A2 entries in the extended EEPROM
map. This is not correct, because the upper byte of
the RSSI_BG2 and RSSI_A2 entries are reserved. There
are no TX mixer gain values are stored at all in the
extended EEPROM.
Remove the initialization of these entries from the
extended EEPROM map to reflect this.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
---
Changes since v1:
- improve commit message and fix a typo
- add Paul's Acked-by tag
---
drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c706ddc..c979bb7 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -280,10 +280,8 @@ static const unsigned int rt2800_eeprom_map_ext[EEPROM_WORD_COUNT] = {
[EEPROM_RSSI_BG] = 0x0028,
[EEPROM_TXPOWER_DELTA] = 0x0028, /* Overlaps with RSSI_BG */
[EEPROM_RSSI_BG2] = 0x0029,
- [EEPROM_TXMIXER_GAIN_BG] = 0x0029, /* Overlaps with RSSI_BG2 */
[EEPROM_RSSI_A] = 0x002a,
[EEPROM_RSSI_A2] = 0x002b,
- [EEPROM_TXMIXER_GAIN_A] = 0x002b, /* Overlaps with RSSI_A2 */
[EEPROM_TXPOWER_BG1] = 0x0030,
[EEPROM_TXPOWER_BG2] = 0x0037,
[EEPROM_EXT_TXPOWER_BG3] = 0x003e,
--
1.7.10
^ permalink raw reply related
* [PATCH/RFT 0/3] ath10k: fixes
From: Michal Kazior @ 2013-10-03 13:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This patchset addresses recently spotted issue
with (yet another) scheduling while atomic bug
(the other being WEP key index setting). This one
is related to hw_config() and powersave settings.
This comes from recent changes I've do to HTC/WMI.
WMI commands can now block so it's illegal to call
them in an atomic context anymore.
ath10k needs to setup some settings per-vdev (i.e.
per-interface) such as powersave, rts, fragmentation.
Until now mac80211 iteration functions were used.
However using non-atomic iteration function variant
doesn't solve the problem as it introduces an
issue with iflist_mtx deadlock in some cases.
I briefly tried to reproduce the issue Kalle
reported but was unsuccessful thus the "/RFT".
Michal Kazior (3):
ath10k: fix add_interface failure handling
ath10k: track vif list internally
ath10k: fix scheduling while atomic config bug
drivers/net/wireless/ath/ath10k/core.c | 2 +
drivers/net/wireless/ath/ath10k/core.h | 3 +
drivers/net/wireless/ath/ath10k/mac.c | 199 ++++++++++++++++----------------
3 files changed, 107 insertions(+), 97 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH/RFT 2/3] ath10k: track vif list internally
From: Michal Kazior @ 2013-10-03 13:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380805765-31521-1-git-send-email-michal.kazior@tieto.com>
mac80211 interface interations functions have
peculiar locking issues. This patch introduces
internal (to ath10k) vif list that will be used
for vif iteration purposes.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.c | 2 ++
drivers/net/wireless/ath/ath10k/core.h | 3 +++
drivers/net/wireless/ath/ath10k/mac.c | 3 +++
3 files changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 7b5dd09..4d04dc8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -710,6 +710,7 @@ struct ath10k *ath10k_core_create(void *hif_priv, struct device *dev,
mutex_init(&ar->conf_mutex);
spin_lock_init(&ar->data_lock);
+ INIT_LIST_HEAD(&ar->arvifs);
INIT_LIST_HEAD(&ar->peers);
init_waitqueue_head(&ar->peer_mapping_wq);
@@ -817,6 +818,7 @@ int ath10k_core_start(struct ath10k *ar)
goto err_disconnect_htc;
ar->free_vdev_map = (1 << TARGET_NUM_VDEVS) - 1;
+ INIT_LIST_HEAD(&ar->arvifs);
return 0;
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index ce36daa..de20ac0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -205,6 +205,8 @@ struct ath10k_peer {
#define ATH10K_VDEV_SETUP_TIMEOUT_HZ (5*HZ)
struct ath10k_vif {
+ struct list_head list;
+
u32 vdev_id;
enum wmi_vdev_type vdev_type;
enum wmi_vdev_subtype vdev_subtype;
@@ -402,6 +404,7 @@ struct ath10k {
/* protects shared structure data */
spinlock_t data_lock;
+ struct list_head arvifs;
struct list_head peers;
wait_queue_head_t peer_mapping_wq;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 7f8b258..292e5cd 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2051,6 +2051,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
}
ar->free_vdev_map &= ~BIT(arvif->vdev_id);
+ list_add(&arvif->list, &ar->arvifs);
vdev_param = ar->wmi.vdev_param->def_keyid;
ret = ath10k_wmi_vdev_set_param(ar, 0, vdev_param,
@@ -2131,6 +2132,7 @@ err_peer_delete:
err_vdev_delete:
ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
ar->free_vdev_map &= ~BIT(arvif->vdev_id);
+ list_del(&arvif->list);
err:
mutex_unlock(&ar->conf_mutex);
return ret;
@@ -2153,6 +2155,7 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
spin_unlock_bh(&ar->data_lock);
ar->free_vdev_map |= 1 << (arvif->vdev_id);
+ list_del(&arvif->list);
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
ret = ath10k_peer_delete(arvif->ar, arvif->vdev_id, vif->addr);
--
1.7.9.5
^ permalink raw reply related
* [PATCH/RFT 1/3] ath10k: fix add_interface failure handling
From: Michal Kazior @ 2013-10-03 13:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380805765-31521-1-git-send-email-michal.kazior@tieto.com>
If something failed along add_interface() setup it
was possible to leak a vdev id, vdev and peer.
This could end up with leaked FW state or FW crash
(assuming add_interface() failure wasn't a result of
a crash).
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 50 ++++++++++++++++++++++++---------
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 8684e03..7f8b258 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2001,18 +2001,17 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
if ((vif->type == NL80211_IFTYPE_MONITOR) && ar->monitor_present) {
ath10k_warn("Only one monitor interface allowed\n");
ret = -EBUSY;
- goto exit;
+ goto err;
}
bit = ffs(ar->free_vdev_map);
if (bit == 0) {
ret = -EBUSY;
- goto exit;
+ goto err;
}
arvif->vdev_id = bit - 1;
arvif->vdev_subtype = WMI_VDEV_SUBTYPE_NONE;
- ar->free_vdev_map &= ~(1 << arvif->vdev_id);
if (ar->p2p)
arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_DEVICE;
@@ -2048,26 +2047,32 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->vdev_subtype, vif->addr);
if (ret) {
ath10k_warn("WMI vdev create failed: ret %d\n", ret);
- goto exit;
+ goto err;
}
+ ar->free_vdev_map &= ~BIT(arvif->vdev_id);
+
vdev_param = ar->wmi.vdev_param->def_keyid;
ret = ath10k_wmi_vdev_set_param(ar, 0, vdev_param,
arvif->def_wep_key_index);
- if (ret)
+ if (ret) {
ath10k_warn("Failed to set default keyid: %d\n", ret);
+ goto err_vdev_delete;
+ }
vdev_param = ar->wmi.vdev_param->tx_encap_type;
ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
ATH10K_HW_TXRX_NATIVE_WIFI);
- if (ret)
+ if (ret) {
ath10k_warn("Failed to set TX encap: %d\n", ret);
+ goto err_vdev_delete;
+ }
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
ret = ath10k_peer_create(ar, arvif->vdev_id, vif->addr);
if (ret) {
ath10k_warn("Failed to create peer for AP: %d\n", ret);
- goto exit;
+ goto err_vdev_delete;
}
}
@@ -2076,38 +2081,57 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
value = WMI_STA_PS_RX_WAKE_POLICY_WAKE;
ret = ath10k_wmi_set_sta_ps_param(ar, arvif->vdev_id,
param, value);
- if (ret)
+ if (ret) {
ath10k_warn("Failed to set RX wake policy: %d\n", ret);
+ goto err_peer_delete;
+ }
param = WMI_STA_PS_PARAM_TX_WAKE_THRESHOLD;
value = WMI_STA_PS_TX_WAKE_THRESHOLD_ALWAYS;
ret = ath10k_wmi_set_sta_ps_param(ar, arvif->vdev_id,
param, value);
- if (ret)
+ if (ret) {
ath10k_warn("Failed to set TX wake thresh: %d\n", ret);
+ goto err_peer_delete;
+ }
param = WMI_STA_PS_PARAM_PSPOLL_COUNT;
value = WMI_STA_PS_PSPOLL_COUNT_NO_MAX;
ret = ath10k_wmi_set_sta_ps_param(ar, arvif->vdev_id,
param, value);
- if (ret)
+ if (ret) {
ath10k_warn("Failed to set PSPOLL count: %d\n", ret);
+ goto err_peer_delete;
+ }
}
ret = ath10k_mac_set_rts(arvif, ar->hw->wiphy->rts_threshold);
- if (ret)
+ if (ret) {
ath10k_warn("failed to set rts threshold for vdev %d (%d)\n",
arvif->vdev_id, ret);
+ goto err_peer_delete;
+ }
ret = ath10k_mac_set_frag(arvif, ar->hw->wiphy->frag_threshold);
- if (ret)
+ if (ret) {
ath10k_warn("failed to set frag threshold for vdev %d (%d)\n",
arvif->vdev_id, ret);
+ goto err_peer_delete;
+ }
if (arvif->vdev_type == WMI_VDEV_TYPE_MONITOR)
ar->monitor_present = true;
-exit:
+ mutex_unlock(&ar->conf_mutex);
+ return 0;
+
+err_peer_delete:
+ if (arvif->vdev_type == WMI_VDEV_TYPE_AP)
+ ath10k_wmi_peer_delete(ar, arvif->vdev_id, vif->addr);
+err_vdev_delete:
+ ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
+ ar->free_vdev_map &= ~BIT(arvif->vdev_id);
+err:
mutex_unlock(&ar->conf_mutex);
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH/RFT 3/3] ath10k: fix scheduling while atomic config bug
From: Michal Kazior @ 2013-10-03 13:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380805765-31521-1-git-send-email-michal.kazior@tieto.com>
Recent HTC/WMI changes introduced the bug. ath10k
was using _atomic iteration function with
sleepable functions.
mac80211 provides another iteration function but
it cannot be safely called in hw_config() callback
due to local->iflist_mtx being possibly acquired
already.
The patch uses internal vif list for iteration
purposes and removes/refactors no longer necessary
_iter functions.
Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 146 ++++++++++++++-------------------
1 file changed, 62 insertions(+), 84 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 292e5cd..df6f973 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -723,35 +723,30 @@ static void ath10k_control_ibss(struct ath10k_vif *arvif,
/*
* Review this when mac80211 gains per-interface powersave support.
*/
-static void ath10k_ps_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
+static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
{
- struct ath10k_generic_iter *ar_iter = data;
- struct ieee80211_conf *conf = &ar_iter->ar->hw->conf;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k *ar = arvif->ar;
+ struct ieee80211_conf *conf = &ar->hw->conf;
enum wmi_sta_powersave_param param;
enum wmi_sta_ps_mode psmode;
int ret;
lockdep_assert_held(&arvif->ar->conf_mutex);
- if (vif->type != NL80211_IFTYPE_STATION)
- return;
+ if (arvif->vif->type != NL80211_IFTYPE_STATION)
+ return 0;
if (conf->flags & IEEE80211_CONF_PS) {
psmode = WMI_STA_PS_MODE_ENABLED;
param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
- ret = ath10k_wmi_set_sta_ps_param(ar_iter->ar,
- arvif->vdev_id,
- param,
+ ret = ath10k_wmi_set_sta_ps_param(ar, arvif->vdev_id, param,
conf->dynamic_ps_timeout);
if (ret) {
ath10k_warn("Failed to set inactivity time for VDEV: %d\n",
arvif->vdev_id);
- return;
+ return ret;
}
-
- ar_iter->ret = ret;
} else {
psmode = WMI_STA_PS_MODE_DISABLED;
}
@@ -759,11 +754,14 @@ static void ath10k_ps_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
ath10k_dbg(ATH10K_DBG_MAC, "mac vdev %d psmode %s\n",
arvif->vdev_id, psmode ? "enable" : "disable");
- ar_iter->ret = ath10k_wmi_set_psmode(ar_iter->ar, arvif->vdev_id,
- psmode);
- if (ar_iter->ret)
+ ret = ath10k_wmi_set_psmode(ar, arvif->vdev_id, psmode);
+ if (ret) {
ath10k_warn("Failed to set PS Mode: %d for VDEV: %d\n",
psmode, arvif->vdev_id);
+ return ret;
+ }
+
+ return 0;
}
/**********************/
@@ -1919,9 +1917,10 @@ static void ath10k_stop(struct ieee80211_hw *hw)
cancel_work_sync(&ar->restart_work);
}
-static void ath10k_config_ps(struct ath10k *ar)
+static int ath10k_config_ps(struct ath10k *ar)
{
- struct ath10k_generic_iter ar_iter;
+ struct ath10k_vif *arvif;
+ int ret;
lockdep_assert_held(&ar->conf_mutex);
@@ -1930,17 +1929,17 @@ static void ath10k_config_ps(struct ath10k *ar)
* vdevs at this point we must not iterate over this interface list.
* This setting will be updated upon add_interface(). */
if (ar->state == ATH10K_STATE_RESTARTED)
- return;
-
- memset(&ar_iter, 0, sizeof(struct ath10k_generic_iter));
- ar_iter.ar = ar;
+ return 0;
- ieee80211_iterate_active_interfaces_atomic(
- ar->hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_ps_iter, &ar_iter);
+ list_for_each_entry(arvif, &ar->arvifs, list) {
+ ret = ath10k_mac_vif_setup_ps(arvif);
+ if (ret) {
+ ath10k_warn("could not setup powersave (%d)\n", ret);
+ break;
+ }
+ }
- if (ar_iter.ret)
- ath10k_warn("failed to set ps config (%d)\n", ar_iter.ret);
+ return ret;
}
static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
@@ -2834,86 +2833,65 @@ static int ath10k_cancel_remain_on_channel(struct ieee80211_hw *hw)
* Both RTS and Fragmentation threshold are interface-specific
* in ath10k, but device-specific in mac80211.
*/
-static void ath10k_set_rts_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
-{
- struct ath10k_generic_iter *ar_iter = data;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
- u32 rts = ar_iter->ar->hw->wiphy->rts_threshold;
- lockdep_assert_held(&arvif->ar->conf_mutex);
+static int ath10k_set_rts_threshold(struct ieee80211_hw *hw, u32 value)
+{
+ struct ath10k *ar = hw->priv;
+ struct ath10k_vif *arvif;
+ int ret;
/* During HW reconfiguration mac80211 reports all interfaces that were
* running until reconfiguration was started. Since FW doesn't have any
* vdevs at this point we must not iterate over this interface list.
* This setting will be updated upon add_interface(). */
- if (ar_iter->ar->state == ATH10K_STATE_RESTARTED)
- return;
-
- ath10k_dbg(ATH10K_DBG_MAC, "mac vdev %d rts_threshold %d\n",
- arvif->vdev_id, rts);
-
- ar_iter->ret = ath10k_mac_set_rts(arvif, rts);
- if (ar_iter->ret)
- ath10k_warn("Failed to set RTS threshold for VDEV: %d\n",
- arvif->vdev_id);
-}
-
-static int ath10k_set_rts_threshold(struct ieee80211_hw *hw, u32 value)
-{
- struct ath10k_generic_iter ar_iter;
- struct ath10k *ar = hw->priv;
-
- memset(&ar_iter, 0, sizeof(struct ath10k_generic_iter));
- ar_iter.ar = ar;
+ if (ar->state == ATH10K_STATE_RESTARTED)
+ return 0;
mutex_lock(&ar->conf_mutex);
- ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_set_rts_iter, &ar_iter);
+ list_for_each_entry(arvif, &ar->arvifs, list) {
+ ath10k_dbg(ATH10K_DBG_MAC, "mac vdev %d rts threshold %d\n",
+ arvif->vdev_id, value);
+
+ ret = ath10k_mac_set_rts(arvif, value);
+ if (ret) {
+ ath10k_warn("could not set rts threshold for vdev %d (%d)\n",
+ arvif->vdev_id, ret);
+ break;
+ }
+ }
mutex_unlock(&ar->conf_mutex);
- return ar_iter.ret;
+ return ret;
}
-static void ath10k_set_frag_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
+static int ath10k_set_frag_threshold(struct ieee80211_hw *hw, u32 value)
{
- struct ath10k_generic_iter *ar_iter = data;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
- u32 frag = ar_iter->ar->hw->wiphy->frag_threshold;
-
- lockdep_assert_held(&arvif->ar->conf_mutex);
+ struct ath10k *ar = hw->priv;
+ struct ath10k_vif *arvif;
+ int ret;
/* During HW reconfiguration mac80211 reports all interfaces that were
* running until reconfiguration was started. Since FW doesn't have any
* vdevs at this point we must not iterate over this interface list.
* This setting will be updated upon add_interface(). */
- if (ar_iter->ar->state == ATH10K_STATE_RESTARTED)
- return;
-
- ath10k_dbg(ATH10K_DBG_MAC, "mac vdev %d fragmentation_threshold %d\n",
- arvif->vdev_id, frag);
-
- ar_iter->ret = ath10k_mac_set_frag(arvif, frag);
- if (ar_iter->ret)
- ath10k_warn("Failed to set frag threshold for VDEV: %d\n",
- arvif->vdev_id);
-}
-
-static int ath10k_set_frag_threshold(struct ieee80211_hw *hw, u32 value)
-{
- struct ath10k_generic_iter ar_iter;
- struct ath10k *ar = hw->priv;
-
- memset(&ar_iter, 0, sizeof(struct ath10k_generic_iter));
- ar_iter.ar = ar;
+ if (ar->state == ATH10K_STATE_RESTARTED)
+ return 0;
mutex_lock(&ar->conf_mutex);
- ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_set_frag_iter, &ar_iter);
+ list_for_each_entry(arvif, &ar->arvifs, list) {
+ ath10k_dbg(ATH10K_DBG_MAC, "mac vdev %d fragmentation threshold %d\n",
+ arvif->vdev_id, value);
+
+ ret = ath10k_mac_set_rts(arvif, value);
+ if (ret) {
+ ath10k_warn("could not set fragmentation threshold for vdev %d (%d)\n",
+ arvif->vdev_id, ret);
+ break;
+ }
+ }
mutex_unlock(&ar->conf_mutex);
- return ar_iter.ret;
+ return ret;
}
static void ath10k_flush(struct ieee80211_hw *hw, u32 queues, bool drop)
--
1.7.9.5
^ permalink raw reply related
* Re: Idea: wifi-over-ethernet (bear with me)
From: Erik Elmore @ 2013-10-03 16:08 UTC (permalink / raw)
To: Julian Calaby; +Cc: linux-wireless
In-Reply-To: <CA+=D8wnh59iQfmk8nDjnEZUBHpiZBXFBWwtGu_y_Ldy1b06Jnw@mail.gmail.com>
It occurs to me now that latency in the repeated frames may be causing
problems for me, but I'm not really certain. I'm not exactly sure how
best to test this idea, yet (needs more thought). Perhaps I could
have two linux-based devices at either end with debug-level logging
on.
I wonder how these so-called "wifi range extenders" work. I might
guess they're little more than repeater devices. I'll need to do some
research to find out whether or not they do any sort of processing of
the frames. If they do, then they will also need to know the
encryption keys or maybe they'll need to associate with an AP to
function. If that's the case, then it might not work for my needs.
In the end, my goal is to make it possible for Nintendo 3DS game
consoles to be able to "street pass" over the internet (I know this is
silly, but I have some spare time on my hands right now). I believe
that process works like ad-hoc networks, except it doesn't use beacons
to advertise and instead uses probe requests to a certain known value.
I'm guessing that is so the consoles don't appear on lists of
available networks for PC users. I also believe the session is
encrypted, but I have no insight yet as to how to guess the key. I
was hoping that a real-time repeater system would be adequate, so I
didn't have to process the frames.
+=
Erik Elmore
On Mon, Sep 30, 2013 at 11:39 PM, Erik Elmore <erik@erikelmore.com> wrote:
> There are a few big ideas, but the one big idea that got me started on
> this line of thought was to make it possible for devices that only
> support ad-hoc networks to function over great distances.
>
> On Mon, Sep 30, 2013 at 8:42 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
>> Hi Erik,
>>
>> On Tue, Oct 1, 2013 at 5:40 AM, Erik Elmore <erik@erikelmore.com> wrote:
>>> Hello, linux-wireless. I have an idea that I'd like to get some
>>> feedback from you all. I admit this idea is weird/flawed/broken and
>>> seemingly useless, but I do have a practical application in mind, so
>>> please hear me out.
>>>
>>> Imagine two physical locations, site 1 and 2, that are well outside of
>>> normal wifi range of each other. Each site has a device that listens
>>> for a subset of wifi frames and then sends them over a distribution
>>> network to its counterpart at the other site. Each device will also
>>> re-transmit frames received via the distribution network. Let's call
>>> these devices listener1 and listener2.
>>>
>>> Each site also contains one client device that wants to form an ad-hoc
>>> network with the one in the other site. Assuming that listener1 and
>>> listener2 are configured to forward frames having a TA belonging to
>>> the client device in their site, is it feasible for these devices to
>>> form an ad-hoc network with the help of the listener devices?
>>
>> Firstly, what's the big plan? - I can't see any useful reason to
>> "tunnel" ad-hoc networks between two points, assuming that you did
>> have all the hardware and software working properly, what is the end
>> goal here, why do you need to have two devices at remote locations
>> form an ad-hoc network with each other? What goal do you have in mind
>> that wouldn't work with a normal managed network?
>>
>> Just so you know, this sort of setup is almost painfully easy to
>> achieve if you use managed networks. - You could simply have a VPN or
>> tunnelling setup of some type between the two access points and have
>> that bridged into the wireless network. This would be 100% transparent
>> as far as clients on the network would be concerned. My previous job
>> had a network that worked somewhat like that with VPNs connecting
>> three offices with WiFi, two data centres and several remote clients
>> into a "single" big network.
>>
>> Thanks,
>>
>> --
>> Julian Calaby
>>
>> Email: julian.calaby@gmail.com
>> Profile: http://www.google.com/profiles/julian.calaby/
>> .Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00: rt2800lib: fix VGC level adjustment for RT3572 and RT3593
From: Gabor Juhos @ 2013-10-03 16:40 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1380650596-18659-2-git-send-email-juhosg@openwrt.org>
2013.10.01. 20:03 keltezéssel, Gabor Juhos írta:
> The Ralink DPO_RT5572_LinuxSTA_2.6.1.3_20121022
> reference driver uses different RSSI threshold
> and VGC adjustment values for the RT3572 and for
> the RT3593 chipsets.
>
> Update the rt2800_link_tuner function to use the
> same values. Also change the comment in the function
> to make it more generic.
>
> References:
>
> RT35xx_ChipAGCAdjust function in chips/rt35xx.c
> RSSI_FOR_MID_LOW_SENSIBILITY constant in include/chip/rtmp_phy.h
> RT3593_R66_MID_LOW_SENS_GET macro in include/chip/rt3593.h
> RT3593_R66_NON_MID_LOW_SEMS_GET macro in include/chips/rt3593.h
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 25c550a..0dd15b2 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -4465,17 +4465,25 @@ void rt2800_link_tuner(struct rt2x00_dev *rt2x00dev, struct link_qual *qual,
>
> if (rt2x00_rt_rev(rt2x00dev, RT2860, REV_RT2860C))
> return;
> - /*
> - * When RSSI is better then -80 increase VGC level with 0x10, except
> - * for rt5592 chip.
> +
> + /* When RSSI is better than a certain threshold, increase VGC
> + * with a chip specific value in order to improve the balance
> + * between sensibility and noise isolation.
> */
>
> vgc = rt2800_get_default_vgc(rt2x00dev);
>
> - if (rt2x00_rt(rt2x00dev, RT5592) && qual->rssi > -65)
> + if ((rt2x00_rt(rt2x00dev, RT3572) ||
> + rt2x00_rt(rt2x00dev, RT3593)) && qual->rssi > -65) {
> + if (rt2x00dev->curr_band == IEEE80211_BAND_2GHZ)
> + vgc += 0x20;
> + else
> + vgc += 0x10;
> + } else if (rt2x00_rt(rt2x00dev, RT5592) && qual->rssi > -65) {
> vgc += 0x20;
> - else if (qual->rssi > -80)
> + } else if (qual->rssi > -80) {
> vgc += 0x10;
> + }
Erm, this seems broken even in the original code. If the rssi value is between
-65 and -80, vgc will be increased by 0x10 regardless of the actual chipset.
John, please skip this patch set. I will send a modified version.
-Gabor
^ permalink raw reply
* Re: ath9k AR9287 status?
From: Bruno Randolf @ 2013-10-03 17:05 UTC (permalink / raw)
To: Bruno Randolf, Oleksij Rempel, linux-wireless, nbd, sujith; +Cc: Ingo Randolf
In-Reply-To: <5249A2F7.5090908@einfach.org>
On 09/30/2013 05:12 PM, Bruno Randolf wrote:
> On 09/30/2013 02:27 PM, Oleksij Rempel wrote:
>>>> Check:
>>>> - PCIe related power managment - ASPM.
>
> Hmm, disabling ASPM in the BIOS and per kernel command line
> (pcie_aspm=off) did not help.
>
>> I use 3.11 right now. In case of PCIe issue, backport wont help you.
>> Test completely new kernel.
>
> I'll try 3.11 later.
I just tried current wireless-testing (3.12.0-rc3-wl) and it shows the
same problems.
For reference:
Card: Unex DNXA-97 (AR9287) http://unex.com.tw/product/dnxa-97
Board: Advantech MIO-2261N (Atom N260)
ASPM is disabled in the BIOS and by pcie_aspm=off. Scanning seems to
work, but when I start up hostapd (v2.0, simple AP config) nothing
happens (no AP is found by clients). When I stop hostapd the system
freezes with "BUG: soft lockup - CPU#3 stuck for 23s! (hostapd:2250)"
bruno
^ permalink raw reply
* pull request: bluetooth-next 2013-10-03
From: Gustavo Padovan @ 2013-10-03 17:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
Hi John,
A series of patches for 3.12. The big work here is from Marcel and Johan. They
did a lot of work in the L2CAP, HCI and MGMT layers. The most important ones
are the addition of a new MGMT command to enable/disable LE advertisement and
the introduction of the HCI user channel to allow applications to get directly
and exclusive access to Bluetooth devices.
Please pull, or let me know of any issues. Thanks!
Gustavo
--
The following changes since commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20:
rt2800: change initialization sequence to fix system freeze (2013-09-09 14:44:34 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next for-upstream
for you to fetch changes up to 4f3e219d95a3c31b916dcd5e2631c4e440736f79:
Bluetooth: Only one command per L2CAP LE signalling is supported (2013-10-03 16:09:59 +0300)
----------------------------------------------------------------
Amitkumar Karwar (4):
Bluetooth: btmrvl: add btmrvl_send_sync_cmd() function
Bluetooth: btmrvl: get rid of struct btmrvl_cmd
Bluetooth: btmrvl: add setup handler
Bluetooth: btmrvl: add calibration data download support
Andre Guedes (2):
Bluetooth: Fix security level for peripheral role
Bluetooth: Fix encryption key size for peripheral role
DoHyun Pyun (8):
Bluetooth: Add the definition and structure for Set Reserved LT_ADDR
Bluetooth: Add the definition and structure for Delete Reserved LT_ADDR
Bluetooth: Add the definition and structure for Set CSB Data
Bluetooth: Add the structure for Write Sync Train Parameters
Bluetooth: Add the definition and structure for Set CSB
Bluetooth: Add the definition for Start Synchronization Train
Bluetooth: Add the definition and stcuture for Sync Train Complete
Bluetooth: Add the definition for Slave Page Response Timeout
Gianluca Anzolin (1):
Bluetooth: don't release the port in rfcomm_dev_state_change()
Gustavo Padovan (1):
Merge git://git.kernel.org/.../bluetooth/bluetooth
Johan Hedberg (25):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
Bluetooth: Remove unused event mask struct
Bluetooth: Fix double error response for l2cap_create_chan_req
Bluetooth: Fix L2CAP error return used for failed channel lookups
Bluetooth: Fix L2CAP Disconnect response for unknown CID
Bluetooth: Fix L2CAP command reject reason
Bluetooth: Fix sending responses to identified L2CAP response packets
Bluetooth: Fix responding to invalid L2CAP signaling commands
Bluetooth: Fix waiting for clearing of BT_SK_SUSPEND flag
Bluetooth: Add synchronization train parameters reading support
Bluetooth: Add event mask page 2 setting support
Bluetooth: Add clarifying comment to bt_sock_wait_state()
Bluetooth: Clean up socket locking in l2cap_sock_recvmsg
Bluetooth: Fix busy return for mgmt_set_powered in some cases
Bluetooth: Move mgmt response convenience functions to a better location
Bluetooth: Use async request for LE enable/disable
Bluetooth: Add new mgmt setting for LE advertising
Bluetooth: Add new mgmt_set_advertising command
Bluetooth: Refactor hci_dev_open to a separate hci_dev_do_open function
Bluetooth: Fix workqueue synchronization in hci_dev_open
Bluetooth: Introduce a new HCI_BREDR_ENABLED flag
Bluetooth: Add a new mgmt_set_bredr command
Bluetooth: Fix REJECTED vs NOT_SUPPORTED mgmt responses
Bluetooth: Fix advertising data flags with disabled BR/EDR
Ken O'Brien (1):
Bluetooth: btusb: Add support for Belkin F8065bf
Marcel Holtmann (35):
Bluetooth: Refactor raw socket filter into more readable code
Bluetooth: Fix handling of getpeername() for HCI sockets
Bluetooth: Fix handling of getsockname() for HCI sockets
Bluetooth: Report error for HCI reset ioctl when device is down
Bluetooth: Fix error handling for HCI socket options
Bluetooth: Restrict ioctls to HCI raw channel sockets
Bluetooth: Introduce user channel flag for HCI devices
Bluetooth: Introduce new HCI socket channel for user operation
Bluetooth: Use devname:vhci module alias for virtual HCI driver
Bluetooth: Add support creating virtual AMP controllers
Bluetooth: Disable upper layer connections when user channel is active
Bluetooth: Use GFP_KERNEL when cloning SKB in a workqueue
Bluetooth: Only schedule raw queue when user channel is active
Bluetooth: Use only 2 bits for controller type information
Bluetooth: Replace BDADDR_LOCAL with BDADDR_NONE
Bluetooth: Provide high speed configuration option
Bluetooth: Send new settings event when changing high speed option
Bluetooth: Require CAP_NET_ADMIN for HCI User Channel operation
Bluetooth: Enable -D__CHECK_ENDIAN__ for sparse by default
Bluetooth: Restrict disabling of HS when controller is powered off
Bluetooth: Add management command for setting static address
Bluetooth: Increment management interface revision
Bluetooth: Fix memory leak with L2CAP signal channels
Bluetooth: Restrict SSP setting changes to BR/EDR enabled controllers
Bluetooth: Allow setting static address even if LE is disabled
Bluetooth: Restrict loading of link keys to BR/EDR capable controllers
Bluetooth: Restrict loading of long term keys to LE capable controllers
Bluetooth: Allow changing device class when BR/EDR is disabled
Bluetooth: Fix switch statement order for L2CAP fixed channels
Bluetooth: Don't copy L2CAP LE signalling to raw sockets
Bluetooth: SMP packets are only valid on LE connections
Bluetooth: L2CAP connectionless channels are only valid for BR/EDR
Bluetooth: Drop packets on ATT fixed channel on BR/EDR
Bluetooth: Check minimum length of SMP packets
Bluetooth: Only one command per L2CAP LE signalling is supported
Peng Chen (1):
Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
Peter Senna Tschudin (1):
Bluetooth: Fix assignment of 0/1 to bool variables
Raphael Kubo da Costa (1):
Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
Syam Sidhardhan (1):
Bluetooth: Fix ACL alive for long in case of non pariable devices
drivers/bluetooth/Makefile | 2 +
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/btmrvl_drv.h | 12 +-
drivers/bluetooth/btmrvl_main.c | 269 +++++++++++++++---------
drivers/bluetooth/btmrvl_sdio.c | 15 +-
drivers/bluetooth/btmrvl_sdio.h | 2 +
drivers/bluetooth/btusb.c | 5 +
drivers/bluetooth/hci_vhci.c | 170 ++++++++++-----
include/net/bluetooth/bluetooth.h | 5 +-
include/net/bluetooth/hci.h | 82 +++++++-
include/net/bluetooth/hci_core.h | 2 +-
include/net/bluetooth/l2cap.h | 1 +
include/net/bluetooth/mgmt.h | 11 +
net/bluetooth/Makefile | 2 +
net/bluetooth/af_bluetooth.c | 41 ++++
net/bluetooth/hci_conn.c | 4 +
net/bluetooth/hci_core.c | 213 +++++++++++++++----
net/bluetooth/hci_event.c | 23 ++-
net/bluetooth/hci_sock.c | 204 ++++++++++++++----
net/bluetooth/l2cap_core.c | 169 +++++++++------
net/bluetooth/l2cap_sock.c | 20 +-
net/bluetooth/mgmt.c | 562 ++++++++++++++++++++++++++++++++++++++++----------
net/bluetooth/rfcomm/sock.c | 7 +-
net/bluetooth/rfcomm/tty.c | 35 +---
net/bluetooth/smp.c | 15 +-
25 files changed, 1390 insertions(+), 483 deletions(-)
^ 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