Re: [PATCH RFC/RFT 1/2] ath9k: rename struct ath_txq to struct ath_hwq
I've already received an automated report that this patch fails to
build. Oops.
Apparently only when either CONFIG_ATH9K_TX99=y or
CONFIG_ATH9K_CHANNEL_CONTEXT=y .
I missed a few things in the ath_txq to ath_hwq rename and failed to
catch it because I didn't have those turned on in my .config .
So if you want to test this before I resubmit, make sure those two
configs are turned off in your .config, or maybe try patching with the
diff below.
I plan to resend the patch soon (probably tomorrow) with this fix
squashed in, after I do some test compiling to make sure I've actually
fixed it.
-Tim Shepard
s...@alum.mit.edu
___ _ ___ _ _ _ ___ ___ _ _ _ _ _ _ ___ _ _ _ ___ _ ___ _ ___
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index 50e614b..0297588 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1006,7 +1006,7 @@ static void ath_scan_send_probe(struct ath_softc *sc,
if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, band, NULL))
goto error;
- txctl.txq = sc->tx.txq_map[IEEE80211_AC_VO];
+ txctl.hwq = sc->tx.hwq_map[IEEE80211_AC_VO];
txctl.force_channel = true;
if (ath_tx_start(sc->hw, skb, &txctl))
goto error;
@@ -1128,7 +1128,7 @@ ath_chanctx_send_vif_ps_frame(struct ath_softc *sc,
struct ath_vif *avp,
}
memset(&txctl, 0, sizeof(txctl));
- txctl.txq = sc->tx.txq_map[IEEE80211_AC_VO];
+ txctl.hwq = sc->tx.hwq_map[IEEE80211_AC_VO];
txctl.sta = sta;
txctl.force_channel = true;
if (ath_tx_start(sc->hw, skb, &txctl)) {
diff --git a/drivers/net/wireless/ath/ath9k/tx99.c
b/drivers/net/wireless/ath/ath9k/tx99.c
index ac4781f..0a9ed5c 100644
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -21,7 +21,7 @@ static void ath9k_tx99_stop(struct ath_softc *sc)
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
- ath_drain_all_txq(sc);
+ ath_drain_all_hwq(sc);
ath_startrecv(sc);
ath9k_hw_set_interrupts(ah);
@@ -125,7 +125,7 @@ static int ath9k_tx99_init(struct ath_softc *sc)
return -ENOMEM;
memset(&txctl, 0, sizeof(txctl));
- txctl.txq = sc->tx.txq_map[IEEE80211_AC_VO];
+ txctl.hwq = sc->tx.hwq_map[IEEE80211_AC_VO];
ath_reset(sc, NULL);
@@ -133,7 +133,7 @@ static int ath9k_tx99_init(struct ath_softc *sc)
ath9k_hw_disable_interrupts(ah);
atomic_set(&ah->intr_ref_cnt, -1);
- ath_drain_all_txq(sc);
+ ath_drain_all_hwq(sc);
ath_stoprecv(sc);
sc->tx99_state = true;
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC/RFT 1/2] ath9k: rename struct ath_txq to struct ath_hwq
Tim Shepard writes: > Also use hwq instead of txq to refer to it throughout ath9k/*. This > is prep work for using mac80211's new intermediate queues, which are > called txq, and it would be too confusing if both are called txq. You should add Signed-off-by to both patches in case someone else wants to work with these. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT] mac80211: implement fq_codel for software queuing
On 4 March 2016 at 03:48, Tim Shepard wrote: [...] > (I am interested in knowing what other mac80211 drivers have been > modified to use the mac80211 intermediate software queues. I know > Michal mentioned he has patches for ath10k that are not yet released, > and I know Felix is finishing up the mt76 driver which uses them.) Patches for ath10k are under review since quite some time now (but are not merged yet). The latest re-spin is: http://lists.infradead.org/pipermail/ath10k/2016-March/006923.html Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211_hwsim: Set global RRM capability
On 03/03/2016 05:45 PM, Johannes Berg wrote: > On Wed, 2016-03-02 at 12:36 +, Grumbach, Emmanuel wrote: >>> >> I had the same thinking, but somehow people convinced me that a >> driver may prefer not to advertise this without its explicit >> consent. > > So ... What are the arguments? :) > Well.. a driver may not want to advertise it... Moot... I guess we can / should move it to mac80211. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT] mac80211: implement fq_codel for software queuing
If you want to try out Michal's patch you'll need a mac80211 driver that uses the new intermediate queues. I just submitted a PATCH RFC/RFT to modify ath9k to use the new intermediate software queues. There are very few (zero or close to zero) drivers in linux which do that, and Michal's patch does not do anything at all unless your driver uses the new intermediate software queues. See If you want to try out Michal's patch you'll need a mac80211 driver that uses the new intermediate queues. I just submitted a PATCH RFC/RFT to modify ath9k to use the new intermediate software queues. There are very few (zero or close to zero) drivers in linux which do that, and Michal's patch does not do anything at all unless your driver uses the new intermediate software queues. See my post from a few hours ago with subject: [PATCH RFC/RFT 0/2] ath9k: use mac80211 intermediate software queues (I am interested in knowing what other mac80211 drivers have been modified to use the mac80211 intermediate software queues. I know Michal mentioned he has patches for ath10k that are not yet released, and I know Felix is finishing up the mt76 driver which uses them.) -Tim Shepard s...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC/RFT 2/2] ath9k: use mac80211 intermediate software queues
This patch leaves the code for ath9k's internal per-node per-tid
queues in place and just modifies the driver to also pull from
the new mac80211 intermediate software queues, and implements
the .wake_tx_queue method, which will cause mac80211 to deliver
packets to be sent via the new intermediate queue.
---
drivers/net/wireless/ath/ath9k/ath9k.h | 16 +++-
drivers/net/wireless/ath/ath9k/debug_sta.c |8 +-
drivers/net/wireless/ath/ath9k/init.c |1 +
drivers/net/wireless/ath/ath9k/main.c |1 +
drivers/net/wireless/ath/ath9k/xmit.c | 122
5 files changed, 129 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 1118b3d..96cbcad 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -145,8 +145,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct
ath_descdma *dd,
#define BAW_WITHIN(_start, _bawsz, _seqno) \
_seqno) - (_start)) & 4095) < (_bawsz))
-#define ATH_AN_2_TID(_an, _tidno) (&(_an)->tid[(_tidno)])
-
#define IS_HT_RATE(rate) (rate & 0x80)
#define IS_CCK_RATE(rate) ((rate >= 0x18) && (rate <= 0x1e))
#define IS_OFDM_RATE(rate) ((rate >= 0x8) && (rate <= 0xf))
@@ -232,8 +230,10 @@ struct ath_buf {
struct ath_atx_tid {
struct list_head list;
+ struct sk_buff_head i_q;
struct sk_buff_head buf_q;
struct sk_buff_head retry_q;
+ struct ieee80211_txq *txq;
struct ath_node *an;
struct ath_hwq *hwq;
unsigned long tx_buf[BITS_TO_LONGS(ATH_TID_MAX_BUFS)];
@@ -247,13 +247,13 @@ struct ath_atx_tid {
s8 bar_index;
bool active;
bool clear_ps_filter;
+ bool txq_nonempty;
};
struct ath_node {
struct ath_softc *sc;
struct ieee80211_sta *sta; /* station struct we're part of */
struct ieee80211_vif *vif; /* interface with which we're associated */
- struct ath_atx_tid tid[IEEE80211_NUM_TIDS];
u16 maxampdu;
u8 mpdudensity;
@@ -271,6 +271,15 @@ struct ath_node {
struct list_head list;
};
+static inline
+struct ath_atx_tid *ath_an_2_tid(struct ath_node *an, u8 tidno)
+{
+ struct ieee80211_sta *sta = an->sta;
+ struct ieee80211_vif *vif = an->vif;
+ struct ieee80211_txq *txq = sta? sta->txq[tidno] : vif->txq;
+ return (struct ath_atx_tid *) txq->drv_priv;
+}
+
struct ath_tx_control {
struct ath_hwq *hwq;
struct ath_node *an;
@@ -585,6 +594,7 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
u16 tids, int nframes,
enum ieee80211_frame_release_type reason,
bool more_data);
+void ath9k_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq);
//
/* VIFs */
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c
b/drivers/net/wireless/ath/ath9k/debug_sta.c
index a9f4a92..100cbfd 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -25,6 +25,7 @@ static ssize_t read_file_node_aggr(struct file *file, char
__user *user_buf,
{
struct ath_node *an = file->private_data;
struct ath_softc *sc = an->sc;
+ struct ieee80211_txq *txq;
struct ath_atx_tid *tid;
struct ath_hwq *hwq;
u32 len = 0, size = 4096;
@@ -52,8 +53,11 @@ static ssize_t read_file_node_aggr(struct file *file, char
__user *user_buf,
"TID", "SEQ_START", "SEQ_NEXT", "BAW_SIZE",
"BAW_HEAD", "BAW_TAIL", "BAR_IDX", "SCHED", "PAUSED");
- for (tidno = 0, tid = &an->tid[tidno];
-tidno < IEEE80211_NUM_TIDS; tidno++, tid++) {
+ for (tidno = 0;
+tidno < IEEE80211_NUM_TIDS; tidno++) {
+
+ txq = an->sta->txq[tidno];
+ tid = (struct ath_atx_tid *) txq->drv_priv;
hwq = tid->hwq;
ath_hwq_lock(sc, hwq);
if (tid->active) {
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index d96055f..7d4427a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -882,6 +882,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct
ieee80211_hw *hw)
hw->max_rate_tries = 10;
hw->sta_data_size = sizeof(struct ath_node);
hw->vif_data_size = sizeof(struct ath_vif);
+ hw->txq_data_size = sizeof(struct ath_atx_tid);
hw->extra_tx_headroom = 4;
hw->wiphy->available_antennas_rx = BIT(ah->caps.max_rxchains) - 1;
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index d39eec8..6cb27b2 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2668,4 +2668,5 @@ struct ieee80211_ops ath9k_ops = {
[PATCH RFC/RFT 1/2] ath9k: rename struct ath_txq to struct ath_hwq
Also use hwq instead of txq to refer to it throughout ath9k/*. This is prep work for using mac80211's new intermediate queues, which are called txq, and it would be too confusing if both are called txq. --- drivers/net/wireless/ath/ath9k/ath9k.h | 50 +-- drivers/net/wireless/ath/ath9k/beacon.c| 10 +- drivers/net/wireless/ath/ath9k/debug.c | 34 +- drivers/net/wireless/ath/ath9k/debug.h |8 +- drivers/net/wireless/ath/ath9k/debug_sta.c |8 +- drivers/net/wireless/ath/ath9k/gpio.c |6 +- drivers/net/wireless/ath/ath9k/init.c | 18 +- drivers/net/wireless/ath/ath9k/link.c | 18 +- drivers/net/wireless/ath/ath9k/main.c | 42 +-- drivers/net/wireless/ath/ath9k/xmit.c | 512 ++-- 10 files changed, 353 insertions(+), 353 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index 5294595..1118b3d 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless/ath/ath9k/ath9k.h @@ -80,7 +80,7 @@ int ath_descdma_setup(struct ath_softc *sc, struct ath_descdma *dd, /* RX / TX */ /***/ -#defineATH_TXQ_SETUP(sc, i) ((sc)->tx.txqsetup & (1beacon.beaconq, &qi); @@ -47,8 +47,8 @@ static void ath9k_beaconq_config(struct ath_softc *sc) qi.tqi_cwmax = 0; } else { /* Adhoc mode; important thing is to use 2x cwmin. */ - txq = sc->tx.txq_map[IEEE80211_AC_BE]; - ath9k_hw_get_txq_props(ah, txq->axq_qnum, &qi_be); + hwq = sc->tx.hwq_map[IEEE80211_AC_BE]; + ath9k_hw_get_txq_props(ah, hwq->axq_qnum, &qi_be); qi.tqi_aifs = qi_be.tqi_aifs; if (ah->slottime == ATH9K_SLOT_TIME_20) qi.tqi_cwmin = 2*qi_be.tqi_cwmin; @@ -117,7 +117,7 @@ static struct ath_buf *ath9k_beacon_generate(struct ieee80211_hw *hw, struct ath_buf *bf; struct ath_vif *avp = (void *)vif->drv_priv; struct sk_buff *skb; - struct ath_txq *cabq = sc->beacon.cabq; + struct ath_hwq *cabq = sc->beacon.cabq; struct ieee80211_tx_info *info; struct ieee80211_mgmt *mgmt_hdr; int cabq_depth; @@ -180,7 +180,7 @@ static struct ath_buf *ath9k_beacon_generate(struct ieee80211_hw *hw, if (sc->cur_chan->nvifs > 1) { ath_dbg(common, BEACON, "Flushing previous cabq traffic\n"); - ath_draintxq(sc, cabq); + ath_drainhwq(sc, cabq); } } diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c index 6de64cf..5e9dda8 100644 --- a/drivers/net/wireless/ath/ath9k/debug.c +++ b/drivers/net/wireless/ath/ath9k/debug.c @@ -621,34 +621,34 @@ static int read_file_xmit(struct seq_file *file, void *data) return 0; } -static void print_queue(struct ath_softc *sc, struct ath_txq *txq, +static void print_queue(struct ath_softc *sc, struct ath_hwq *hwq, struct seq_file *file) { - ath_txq_lock(sc, txq); + ath_hwq_lock(sc, hwq); - seq_printf(file, "%s: %d ", "qnum", txq->axq_qnum); - seq_printf(file, "%s: %2d ", "qdepth", txq->axq_depth); - seq_printf(file, "%s: %2d ", "ampdu-depth", txq->axq_ampdu_depth); - seq_printf(file, "%s: %3d ", "pending", txq->pending_frames); - seq_printf(file, "%s: %d\n", "stopped", txq->stopped); + seq_printf(file, "%s: %d ", "qnum", hwq->axq_qnum); + seq_printf(file, "%s: %2d ", "qdepth", hwq->axq_depth); + seq_printf(file, "%s: %2d ", "ampdu-depth", hwq->axq_ampdu_depth); + seq_printf(file, "%s: %3d ", "pending", hwq->pending_frames); + seq_printf(file, "%s: %d\n", "stopped", hwq->stopped); - ath_txq_unlock(sc, txq); + ath_hwq_unlock(sc, hwq); } static int read_file_queues(struct seq_file *file, void *data) { struct ieee80211_hw *hw = dev_get_drvdata(file->private); struct ath_softc *sc = hw->priv; - struct ath_txq *txq; + struct ath_hwq *hwq; int i; static const char *qname[4] = { "VO", "VI", "BE", "BK" }; for (i = 0; i < IEEE80211_NUM_ACS; i++) { - txq = sc->tx.txq_map[i]; + hwq = sc->tx.hwq_map[i]; seq_printf(file, "(%s): ", qname[i]); - print_queue(sc, txq, file); + print_queue(sc, hwq, file); } seq_puts(file, "(CAB): "); @@ -782,10 +782,10 @@ static int read_file_reset(struct seq_file *file, void *data) } void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf, -
[PATCH RFC/RFT 0/2] ath9k: use mac80211 intermediate software queues
Here is a patch in two parts to have ath9k make use the new intermediate queues in mac80211. It seems to work for me, but it clearly needs more testing. This should be useful to anyone who wants to try Michal's patch from last week "mac80211: implement fq_codel for software queuing" as that patch will not do anything unless you have a mac80211 driver that uses the new mac80211 intermediate queues and indicates to mac80211 that it does so by having a non-zero .wake_tx_queue method. The first patch just renames the struct ath_txq in ath9k to be struct ath_hwq and the renames the variables and fields holding a pointer to it to be hwq (instead of txq). This first patch is IMHO needed because I had an earlier version of this without renaming ath_txq and it was too mind bending to try and keep straight which was ath9k's txq (which is per hardware queue) and what was mac80211 txq (which is per station per tid). The second patch changes ath9k to use the new mac80211 intermediate software queues. I left the existing ath9k software queue mechanisms in place. They are used by the channel context code in some cases even for non-data frames, and in any case it seemed like a safer first step to get this working before removing code. Yes, we should eventually clean this up once this is tested and we figure out what the right way to do the clean up. I see little harm in leaving it stay for awhile. I have not tried any testing with CONFIG_ATH9K_CHANNEL_CONTEXT=y and I am not even sure what I would need to do to properly exercise that. Please comment and/or test. -Tim Shepard s...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with brcmfmac removing extra interface
Hi, brcmfmac in general is not capable of removing interfaces. If you take a look at brcmf_cfg80211_del_iface implementation, you'll see it returns -EOPNOTSUPP (except for p2p interfaces). However there is problem in handling NL80211_CMD_STOP_AP (with the brcmf_cfg80211_stop_ap callback). Current implementation calls brcmf_fil_cmd_int_set(ifp, BRCMF_C_DOWN, 1) if mbss support is enabled/used. Above call results in firmware generating BRCMF_E_LINK event. This event is handled with the following forward-traced functions chain: 1) brcmf_notify_connect_status 2) brcmf_notify_connect_status_ap 3) brcmf_remove_interface 4) brcmf_del_if 5) brcmf_net_detach 6) unregister_netdev So the result of NL80211_CMD_STOP_AP is interface being removed. The problem with this behavior is that interface can't be recreated after that: # iw phy phy1 interface add wlan1-1 type __ap [ 3602.929199] brcmfmac: brcmf_ap_add_vif: timeout occurred command failed: I/O error (-5) I hit this problem when trying to restart hostapd using BCM43602 and 2 BSSes. Could you analyze this problem and see if you see some way of solving this problem, please? -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: minstrel_ht: improve sample rate skip logic
There were a few issues that were slowing down the process of finding
the optimal rate, especially on devices with multi-rate retry
limitations:
When max_tp_rate[0] was slower than max_tp_rate[1], the code did not
sample max_tp_rate[1], which would often allow it to switch places with
max_tp_rate[0] (e.g. if only the first sampling attempts were bad, but the
rate is otherwise good).
Also, sample attempts of rates between max_tp_rate[0] and [1] were being
ignored in this case, because the code only checked if the rate was
slower than [1].
Fix this by checking against the fastest / second fastest max_tp_rate
instead of assuming a specific order between the two.
In my tests this patch significantly reduces the time until minstrel_ht
finds the optimal rate right after assoc
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel_ht.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 3928dbd..9197191 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -923,6 +923,7 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, struct
minstrel_ht_sta *mi)
struct minstrel_rate_stats *mrs;
struct minstrel_mcs_group_data *mg;
unsigned int sample_dur, sample_group, cur_max_tp_streams;
+ int tp_rate1, tp_rate2;
int sample_idx = 0;
if (mi->sample_wait > 0) {
@@ -944,14 +945,22 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, struct
minstrel_ht_sta *mi)
mrs = &mg->rates[sample_idx];
sample_idx += sample_group * MCS_GROUP_RATES;
+ /* Set tp_rate1, tp_rate2 to the highest / second highest max_tp_rate */
+ if (minstrel_get_duration(mi->max_tp_rate[0]) >
+ minstrel_get_duration(mi->max_tp_rate[1])) {
+ tp_rate1 = mi->max_tp_rate[1];
+ tp_rate2 = mi->max_tp_rate[0];
+ } else {
+ tp_rate1 = mi->max_tp_rate[0];
+ tp_rate2 = mi->max_tp_rate[1];
+ }
+
/*
* Sampling might add some overhead (RTS, no aggregation)
-* to the frame. Hence, don't use sampling for the currently
-* used rates.
+* to the frame. Hence, don't use sampling for the highest currently
+* used highest throughput or probability rate.
*/
- if (sample_idx == mi->max_tp_rate[0] ||
- sample_idx == mi->max_tp_rate[1] ||
- sample_idx == mi->max_prob_rate)
+ if (sample_idx == mi->max_tp_rate[0] || sample_idx == mi->max_prob_rate)
return -1;
/*
@@ -966,10 +975,10 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, struct
minstrel_ht_sta *mi)
* if the link is working perfectly.
*/
- cur_max_tp_streams = minstrel_mcs_groups[mi->max_tp_rate[0] /
+ cur_max_tp_streams = minstrel_mcs_groups[tp_rate1 /
MCS_GROUP_RATES].streams;
sample_dur = minstrel_get_duration(sample_idx);
- if (sample_dur >= minstrel_get_duration(mi->max_tp_rate[1]) &&
+ if (sample_dur >= minstrel_get_duration(tp_rate2) &&
(cur_max_tp_streams - 1 <
minstrel_mcs_groups[sample_group].streams ||
sample_dur >= minstrel_get_duration(mi->max_prob_rate))) {
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rate
Prevents excessive A-MSDU aggregation at low data rates or bad
conditions.
Signed-off-by: Felix Fietkau
---
net/mac80211/rc80211_minstrel_ht.c | 54 ++
1 file changed, 54 insertions(+)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 3928dbd..a9d5b28 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -882,6 +882,59 @@ minstrel_ht_set_rate(struct minstrel_priv *mp, struct
minstrel_ht_sta *mi,
ratetbl->rate[offset].flags = flags;
}
+static inline int
+minstrel_ht_get_prob_ewma(struct minstrel_ht_sta *mi, int rate)
+{
+ int group = rate / MCS_GROUP_RATES;
+ rate %= MCS_GROUP_RATES;
+ return mi->groups[group].rates[rate].prob_ewma;
+}
+
+static int
+minstrel_ht_get_max_amsdu_len(struct minstrel_ht_sta *mi)
+{
+ int group = mi->max_prob_rate / MCS_GROUP_RATES;
+ const struct mcs_group *g = &minstrel_mcs_groups[group];
+ int rate = mi->max_prob_rate % MCS_GROUP_RATES;
+
+ /* Disable A-MSDU if max_prob_rate is bad */
+ if (mi->groups[group].rates[rate].prob_ewma < MINSTREL_FRAC(50, 100))
+ return 1;
+
+ /* If the rate is slower than single-stream MCS1, make A-MSDU limit
small */
+ if (g->duration[rate] > MCS_DURATION(1, 0, 52))
+ return 500;
+
+ /*
+* If the rate is slower than single-stream MCS4, limit A-MSDU to usual
+* data packet size
+*/
+ if (g->duration[rate] > MCS_DURATION(1, 0, 104))
+ return 1600;
+
+ /*
+* If the rate is slower than single-stream MCS7, or if the max
throughput
+* rate success probability is less than 75%, limit A-MSDU to twice the
usual
+* data packet size
+*/
+ if (g->duration[rate] > MCS_DURATION(1, 0, 260) ||
+ (minstrel_ht_get_prob_ewma(mi, mi->max_tp_rate[0]) <
+MINSTREL_FRAC(75, 100)))
+ return 3200;
+
+ /*
+* HT A-MPDU limits maximum MPDU size under BA agreement to 4095 bytes.
+* Since aggregation sessions are started/stopped without txq flush, use
+* the limit here to avoid the complexity of having to de-aggregate
+* packets in the queue.
+*/
+ if (!mi->sta->vht_cap.vht_supported)
+ return IEEE80211_MAX_MPDU_LEN_HT_BA;
+
+ /* unlimited */
+ return 0;
+}
+
static void
minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
{
@@ -906,6 +959,7 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct
minstrel_ht_sta *mi)
minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_prob_rate);
}
+ mi->sta->max_rc_amsdu_len = minstrel_ht_get_max_amsdu_len(mi);
rates->rate[i].idx = -1;
rate_control_set_rates(mp->hw, mi->sta, rates);
}
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] mac80211: add A-MSDU tx support
Requires software tx queueing and fast-xmit support. For good
performance, drivers need frag_list support as well. This avoids the
need for copying data of aggregated frames. Running without it is only
supported for debugging purposes.
To avoid performance and packet size issues, the rate control module or
driver needs to limit the maximum A-MSDU size by setting
max_rc_amsdu_len in struct ieee80211_sta.
Signed-off-by: Felix Fietkau
---
include/linux/ieee80211.h | 3 +
include/net/mac80211.h | 19 ++
net/mac80211/agg-tx.c | 5 ++
net/mac80211/debugfs.c | 2 +
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/sta_info.c| 2 +
net/mac80211/tx.c | 156 +
7 files changed, 188 insertions(+)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 3b1f6ce..7ac7594 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -163,6 +163,9 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
/* 30 byte 4 addr hdr, 2 byte QoS, 2304 byte MSDU, 12 byte crypt, 4 byte FCS */
#define IEEE80211_MAX_FRAME_LEN2352
+/* Maximal size of an A-MSDU that can be transported in a HT BA session */
+#define IEEE80211_MAX_MPDU_LEN_HT_BA 4095
+
/* Maximal size of an A-MSDU */
#define IEEE80211_MAX_MPDU_LEN_HT_3839 3839
#define IEEE80211_MAX_MPDU_LEN_HT_7935 7935
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a5c..c3cfdf5 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -709,6 +709,7 @@ enum mac80211_tx_info_flags {
* @IEEE80211_TX_CTRL_PS_RESPONSE: This frame is a response to a poll
* frame (PS-Poll or uAPSD).
* @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate information
+ * @IEEE80211_TX_CTRL_AMSDU: This frame is an A-MSDU frame
*
* These flags are used in tx_info->control.flags.
*/
@@ -716,6 +717,7 @@ enum mac80211_tx_control_flags {
IEEE80211_TX_CTRL_PORT_CTRL_PROTO = BIT(0),
IEEE80211_TX_CTRL_PS_RESPONSE = BIT(1),
IEEE80211_TX_CTRL_RATE_INJECT = BIT(2),
+ IEEE80211_TX_CTRL_AMSDU = BIT(3),
};
/*
@@ -1741,6 +1743,7 @@ struct ieee80211_sta_rates {
* size is min(max_amsdu_len, 7935) bytes.
* Both additional HT limits must be enforced by the low level driver.
* This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
+ * @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by rate control.
* @txq: per-TID data TX queues (if driver uses the TXQ abstraction)
*/
struct ieee80211_sta {
@@ -1761,6 +1764,7 @@ struct ieee80211_sta {
bool mfp;
u8 max_amsdu_subframes;
u16 max_amsdu_len;
+ u16 max_rc_amsdu_len;
struct ieee80211_txq *txq[IEEE80211_NUM_TIDS];
@@ -1974,6 +1978,15 @@ struct ieee80211_txq {
* order and does not need to manage its own reorder buffer or BA session
* timeout.
*
+ * @IEEE80211_HW_TX_AMSDU: Hardware (or driver) supports software aggregated
+ * A-MSDU frames. Requires software tx queueing and fast-xmit support.
+ * When not using minstrel/minstrel_ht rate control, the driver should
+ * limit the maximum A-MSDU size based on the current tx rate by setting
+ * max_rc_amsdu_len in struct ieee80211_sta.
+ *
+ * @IEEE80211_HW_TX_FRAG_LIST: Hardware (or driver) supports sending frag_list
+ * skbs, needed for zero-copy software A-MSDU.
+ *
* @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
*/
enum ieee80211_hw_flags {
@@ -2011,6 +2024,8 @@ enum ieee80211_hw_flags {
IEEE80211_HW_BEACON_TX_STATUS,
IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR,
IEEE80211_HW_SUPPORTS_REORDERING_BUFFER,
+ IEEE80211_HW_TX_AMSDU,
+ IEEE80211_HW_TX_FRAG_LIST,
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
@@ -2083,6 +2098,9 @@ enum ieee80211_hw_flags {
* size is smaller (an example is LinkSys WRT120N with FW v1.0.07
* build 002 Jun 18 2012).
*
+ * @max_tx_fragments: maximum number of tx buffers per (A)-MSDU, sum
+ * of 1 + skb_shinfo(skb)->nr_frags for each skb in the frag_list.
+ *
* @offchannel_tx_hw_queue: HW queue ID to use for offchannel TX
* (if %IEEE80211_HW_QUEUE_CONTROL is set)
*
@@ -2137,6 +2155,7 @@ struct ieee80211_hw {
u8 max_rate_tries;
u8 max_rx_aggregation_subframes;
u8 max_tx_aggregation_subframes;
+ u8 max_tx_fragments;
u8 offchannel_tx_hw_queue;
u8 radiotap_mcs_details;
u16 radiotap_vht_details;
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 4932e9f..42fa810 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -935,6 +935,7 @@ void ieee80211_process_addba_resp(struct ieee80211_local
*local,
size_t len)
{
struct tid_ampdu_tx *tid_tx;
+ struct ieee80211_txq *txq
Re: alfa awus036nhr v2 and module rtl8xxxu
Larry Finger writes:
> On 02/29/2016 06:28 AM, Jes Sorensen wrote:
>> That one I have never seen before - could you try and insert some debug
>> prints to see where the RF initialization fails?
>
> The call to usb_control_msg() is returning -EPROTO (-71), but
> sometimes the system works. I added the following patch:
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> index 38aa3c2..8ab77a0 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> @@ -1979,9 +1979,12 @@ static int rtl8xxxu_write_rfreg(struct rtl8xxxu_priv
> *priv,
>
> /* Use XB for path B */
> ret = rtl8xxxu_write32(priv, rtl8xxxu_rfregs[path].lssiparm,
> dataaddr);
> - if (ret != sizeof(dataaddr))
> + if (ret != sizeof(dataaddr)) {
> + pr_info(" rtl8xxxu_write32() error %d: path %d,
> reg: 0x%x, data 0x%x, dataaddr 0x%x, lssiparm 0x%x\n",
> + ret, path, reg, data, dataaddr,
> rtl8xxxu_rfregs[path].lssiparm);
> + dump_stack();
> retval = -EIO;
> - else
> + } else
> retval = 0;
>
> udelay(1);
>
> When the error happens, my log contains
Odd, I wonder if my code writes the reigsters out to the device too
fast. You could try adding a call to read back the RF register before
exiting the function - preferably after the udelay().
Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] mt76: add common code shared between multiple chipsets
This will be used by drivers for MT76x2e, MT7603e and MT7628
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/debugfs.c | 72
drivers/net/wireless/mediatek/mt76/dma.c | 444 +++
drivers/net/wireless/mediatek/mt76/dma.h | 35 ++
drivers/net/wireless/mediatek/mt76/eeprom.c | 120 +++
drivers/net/wireless/mediatek/mt76/mac80211.c | 240 +
drivers/net/wireless/mediatek/mt76/mmio.c | 57 +++
drivers/net/wireless/mediatek/mt76/mt76.h | 303
drivers/net/wireless/mediatek/mt76/trace.c| 20 ++
drivers/net/wireless/mediatek/mt76/trace.h| 68
drivers/net/wireless/mediatek/mt76/tx.c | 499 ++
drivers/net/wireless/mediatek/mt76/util.c | 104 ++
drivers/net/wireless/mediatek/mt76/util.h | 104 ++
12 files changed, 2066 insertions(+)
create mode 100644 drivers/net/wireless/mediatek/mt76/debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mac80211.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mmio.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76.h
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.h
diff --git a/drivers/net/wireless/mediatek/mt76/debugfs.c
b/drivers/net/wireless/mediatek/mt76/debugfs.c
new file mode 100644
index 000..7587ff2
--- /dev/null
+++ b/drivers/net/wireless/mediatek/mt76/debugfs.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright (C) 2016 Felix Fietkau
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include "mt76.h"
+
+static int
+mt76_reg_set(void *data, u64 val)
+{
+ struct mt76_dev *dev = data;
+
+ dev->bus->wr(dev, dev->debugfs_reg, val);
+ return 0;
+}
+
+static int
+mt76_reg_get(void *data, u64 *val)
+{
+ struct mt76_dev *dev = data;
+
+ *val = dev->bus->rr(dev, dev->debugfs_reg);
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(fops_regval, mt76_reg_get, mt76_reg_set, "0x%08llx\n");
+
+static int
+mt76_queues_read(struct seq_file *s, void *data)
+{
+ struct mt76_dev *dev = dev_get_drvdata(s->private);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(dev->q_tx); i++) {
+ struct mt76_queue *q = &dev->q_tx[i];
+
+ if (!q->ndesc)
+ continue;
+
+ seq_printf(s,
+ "%d: queued=%d head=%d tail=%d swq_queued=%d\n",
+ i, q->queued, q->head, q->tail, q->swq_queued);
+ }
+
+ return 0;
+}
+
+struct dentry *mt76_register_debugfs(struct mt76_dev *dev)
+{
+ struct dentry *dir;
+
+ dir = debugfs_create_dir("mt76", dev->hw->wiphy->debugfsdir);
+ if (!dir)
+ return NULL;
+
+ debugfs_create_u32("regidx", S_IRUSR | S_IWUSR, dir, &dev->debugfs_reg);
+ debugfs_create_file("regval", S_IRUSR | S_IWUSR, dir, dev,
&fops_regval);
+ debugfs_create_blob("eeprom", S_IRUSR, dir, &dev->eeprom);
+ if (dev->otp.data)
+ debugfs_create_blob("otp", S_IRUSR, dir, &dev->otp);
+ debugfs_create_devm_seqfile(dev->dev, "queues", dir, mt76_queues_read);
+
+ return dir;
+}
+EXPORT_SYMBOL_GPL(mt76_register_debugfs);
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c
b/drivers/net/wireless/mediatek/mt76/dma.c
new file mode 100644
index 000..b22dbd4
--- /dev/null
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -0,0 +1,444 @@
+/*
+ * Copyright (C) 2016 Felix Fietkau
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include "mt76.h"
+#include "dma.h"
+
+#define DMA_DUMMY_TXWI ((void *) ~0)
+
+static int
+mt76_dma_alloc_queue(struct mt76_dev *dev, struct mt76_queue *q)
+{
+ int size;
+ int i;
+
+ spin_lock_init(&q->lock);
+ INIT_LIST
Re: [PATCH 2/2] mt76: add driver code for MT76x2e
On 2016-03-02 18:59, Felix Fietkau wrote: > This is a 2x2 PCIe 802.11ac chipset by MediaTek > > Signed-off-by: Felix Fietkau Found some minor tx queue issues. Will send a v2. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V11 1/2] nl80211: add feature for BSS selection support
On 3-3-2016 16:55, Johannes Berg wrote: > On Wed, 2016-03-02 at 20:37 +0100, Arend van Spriel wrote: >> Introducing a new feature that the driver can use to >> indicate the driver/firmware supports configuration of BSS >> selection criteria upon CONNECT command. This can be useful >> when multiple BSS-es are found belonging to the same ESS, >> ie. Infra-BSS with same SSID. The criteria can then be used to >> offload selection of a preferred BSS. >> > Applied, finally :) > > I moved the wiphy supported methods check into parse_bss_select() to > avoid the double error path in the caller, plus some editorial changes. Do you expect Kalle to take the brcmfmac patch or can it go through your tree? Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V11 1/2] nl80211: add feature for BSS selection support
On 3-3-2016 16:55, Johannes Berg wrote: > On Wed, 2016-03-02 at 20:37 +0100, Arend van Spriel wrote: >> Introducing a new feature that the driver can use to >> indicate the driver/firmware supports configuration of BSS >> selection criteria upon CONNECT command. This can be useful >> when multiple BSS-es are found belonging to the same ESS, >> ie. Infra-BSS with same SSID. The criteria can then be used to >> offload selection of a preferred BSS. >> > Applied, finally :) Yeah. I was afraid it would not make it in 4.6. > I moved the wiphy supported methods check into parse_bss_select() to > avoid the double error path in the caller, plus some editorial changes. Looking at it + /* user-space did not provide behaviour attribute */ + if (bss_select->behaviour == __NL80211_BSS_SELECT_ATTR_INVALID) + return -EINVAL; + + if (!(wiphy->bss_select_support & BIT(bss_select->behaviour))) + return -EINVAL; the first check is (and already was) redundant. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Proposal for per-radio configuration file.
Hello! While working on ath10k NICs, I found a need to have one radio be configured in one manner, and another in a different manner, and I need this config to happen before the NIC is booted in at least some cases. The primary reason is that the NIC has limited resources, so there is definite need to allow the user to optimize for their use case. For instance, more vdevs vs more peer objects. Module parameters do not work well for this because I want different NICs with the same driver to have different configuration. For ath10k, I implemented this with a text file for each NIC that is loaded with the firmware-load API, parsed in the kernel, and then used to configure the radio on bootup. A patch I used to do this is here. I think I ended up with a few follow-on patches to fix some bugs, but this has the idea: http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=6708e4047d91edf234239943332bc2f0d124d009 It seems to work fine in my testing, and is logically similar to loading board init files and so forth (which ath10k already uses). I am looking for feedback on this if anyone has any opinions The config files look like this: ]# ls -l /lib/firmware/ath10k/ total 12 -rw-r--r-- 1 root root 311 Feb 23 11:27 fwcfg-pci-:05:00.0.txt -rw-r--r-- 1 root root 330 Feb 23 11:18 fwcfg-pci-:07:00.0.txt rwxr-xr-x. 3 root root 4096 May 21 2015 QCA988X ]# cat /lib/firmware/ath10k/fwcfg-pci-:05:00.0.txt # Configuration for radio 1 vdevs = 64 peers = 127 stations = 127 rate_ctrl_objs = 36 regdom = 840 fwname = firmware-2.bin fwver = 2 nohwcrypt = 1 tx_desc = 680 #max_nss = 3 num_tids = 256 skid_limit = 128 [root@ben-ota-1 lanforge]# cat /lib/firmware/ath10k/fwcfg-pci-\:07\:00.0.txt # Configuration for radio 2 # Driver will pick defaults for any commented-out or missing variables. # vdevs = 8 # peers = 64 # stations = 64 # rate_ctrl_objs = 10 # regdom = 840 # fwname = firmware-5.bin # fwver = 5 # nohwcrypt = 1 # tx_desc = 1024 #max_nss = 3 # num_tids = 128 # skid_limit = 32 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT] mac80211: implement fq_codel for software queuing
On Tue, Mar 1, 2016 at 11:38 PM, Michal Kazior wrote:
> On 1 March 2016 at 15:02, Johannes Berg wrote:
>> On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>>>
>>> +typedef u64 codel_time_t;
>>
>> Do we really need this? And if yes, does it have to be in the public
>> header file? Why a typedef anyway?
>
> Hmm.. I don't think it's strictly necessary. I just wanted to keep as
> much from the original codel implementation as possible. I'm fine with
> using just u64.
This is an artifact of the original codel keeping time in (nsec >> 10)
to fit into a 32 bit int.
In codel5 we switched to native 64 bit timekeeping as simpler, to
improve logging and reason about.
u64 is fine.
>
>>> - * @txq_ac_max_pending: maximum number of frames per AC pending in
>>> all txq
>>> - * entries for a vif.
>>> + * @txq_cparams: codel parameters to control tx queueing dropping
>>> behavior
>>> + * @txq_limit: maximum number of frames queuesd
>>
>> typo - queued
>>
>>> @@ -2133,7 +2155,8 @@ struct ieee80211_hw {
>>> u8 uapsd_max_sp_len;
>>> u8 n_cipher_schemes;
>>> const struct ieee80211_cipher_scheme *cipher_schemes;
>>> - int txq_ac_max_pending;
>>> + struct codel_params txq_cparams;
>>
>> Should this really be a parameter the driver determines?
>
> I would think so, or at least it should be able to influence it in
> *some* way. You can have varying degree of induced latency depending
> on fw/hw tx queue depth, air conditions and possible tx rates implying
> different/varying RTT. Cake[1] even has a few RTT presets like: lan,
> internet, satellite.
While those presets have been useful in testing codel and (more
generically in cake we can rapidly change the bandwidth from userspace
for testing), in the real world you don't move from orbit to desktop
and back as rapidly as wifi does.
> I don't really have a plan how exactly a driver could make use of it
> for benefit though. It might end up not being necessary after all if
> generic tx scheduling materializes in mac80211.
What we envisioned here is ewma smoothing the target based on the
total service time needed for all active stations, per round. (There
are other possible approaches)
Say you serve 10 stations at 1ms each in one round, a codel target of
5ms will try to push things down too far. If in the next round, you
only serve 2 stations at 1ms each (but get back 10 responses at .5ms
each), you're still too high. If it's just one station, well, you can
get below 2ms if the driver is only sending 1ms, but maybe it's
sending 5ms...
If you have a large multicast burst, that burp will cause lost packets.
Merely getting typical wifi latencies under load down below the 20ms
range would be a good start, after that some testing, hard thought,
and evaluation are going to be needed. for early testing I think a
20ms fixed target would be safer than the existing 5ms.
Pushing the fq part of fq_codel on a per station basis as close to the
hardware as possible, and having better airtime fairness between
stations is a huge win in itself.
>
> [1]: http://www.bufferbloat.net/projects/codel/wiki/Cake
>
>
>>> +static void ieee80211_if_setup_no_queue(struct net_device *dev)
>>> +{
>>> + ieee80211_if_setup(dev);
>>> + dev->priv_flags |= IFF_NO_QUEUE;
>>> + /* Note for backporters: use dev->tx_queue_len = 0 instead
>>> of IFF_ */
>>
>> Heh. Remove that comment; we have an spatch in backports already :)
>
> I've put it in the RFC specifically in case anyone wants to port this
> bypassing backports, e.g. to openwrt's quilt (so when compilation
> fails, you can quickly fix it up). I'll remove it before proper
> submission obviously :)
>
>
>>> --- a/net/mac80211/sta_info.h
>>> +++ b/net/mac80211/sta_info.h
>>> @@ -19,6 +19,7 @@
>>> #include
>>> #include
>>> #include "key.h"
>>> +#include "codel_i.h"
>>>
>>> /**
>>> * enum ieee80211_sta_info_flags - Stations flags
>>> @@ -327,6 +328,32 @@ struct mesh_sta {
>>>
>>> DECLARE_EWMA(signal, 1024, 8)
>>>
>>> +struct txq_info;
>>> +
>>> +/**
>>> + * struct txq_flow - per traffic flow queue
>>> + *
>>> + * This structure is used to distinguish and queue different traffic
>>> flows
>>> + * separately for fair queueing/AQM purposes.
>>> + *
>>> + * @txqi: txq_info structure it is associated at given time
>>> + * @flowchain: can be linked to other flows for RR purposes
>>> + * @backlogchain: can be linked to other flows for backlog sorting
>>> purposes
>>> + * @queue: sk_buff queue
>>> + * @cvars: codel state vars
>>> + * @backlog: number of bytes pending in the queue
>>> + * @deficit: used for fair queueing balancing
>>> + */
>>> +struct txq_flow {
>>> + struct txq_info *txqi;
>>> + struct list_head flowchain;
>>> + struct list_head backlogchain;
>>> + struct sk_buff_head queue;
>>> + struct codel_vars cvars;
>>> + u32 backlog;
>>> + u32 deficit;
>>> +};
>>> +
>>> /**
>>> * struct sta_info - STA information
>>> *
>>> diff --git a/net/mac80211/tx.c b/net/mac80
Re: [PATCH] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
Hi johannes, On Thu, Mar 03, 2016 at 05:07:51PM +0100, Johannes Berg wrote: > On Thu, 2016-03-03 at 21:30 +0530, Mohammed Shafi Shajakhan wrote: > > > [shafi] This is part of the Per Station statistics requirement, > > Heh. Whose requirements? :) [shafi] We have this as part of ath10k debugfs based on the end user (or) a customer requirement and i think its make more sense to have this common across all wifi drivers rather thank simply dumping it in ath10k debugfs. I think its similar to 'ieee80211_frame_duration'(?) in mac80211 but for drivers like ath10k where this is calculated in firmware for rx and implementation specific. > > > the information from 'iw dev wlan#N station dump' which has > > rx_duration > > field will be used by application assesing the statistics > > /performance of various clients connected to our AP. We will plot > > a graph based on this information (assesing the rx time spent by > > AP for various clients). > > > > > > > > Are you really sure you mean "unicast"? What if the station is the > > > AP? Why wouldn't multicast frames it transmitted be accounted for? > > > > [shafi] This is based on the implementation by the driver/firmware. > > We are focused on the AP side so unicast frames, if you are ok with > > this change, i can change the documentation to be specific (generic > > for all the drivers) something like implementation specific (please > > advise) > > Ok, but for AP side I don't see the difference between "unicast" and > "all frames", since all frames from that station should be unicast? > Apart, perhaps, from some management frames the station might send > outside the BSS, but that's not likely to matter much? [shafi] exactly, I can change the documentation as you wish and this is implementation specific, and we have implemented like this in ath10k targeting AP mode. > > IOW, why not specify all frames, and let this make some sense for other > interface modes? > [shafi] Agreed. regards, shafi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix AP buffered multicast frames with queue control and txq
On Thu, Mar 3, 2016 at 7:14 AM, Johannes Berg wrote: > On Sun, 2016-02-28 at 09:35 -0800, Dave Taht wrote: >> On Sun, Feb 28, 2016 at 6:19 AM, Felix Fietkau >> wrote: >> > Buffered multicast frames must be passed to the driver directly via >> > drv_tx instead of going through the txq, otherwise they cannot >> > easily be >> > scheduled to be sent after DTIM. >> > >> > Signed-off-by: Felix Fietkau >> > --- >> > net/mac80211/tx.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c >> > index 3a7475f..b294820 100644 >> > --- a/net/mac80211/tx.c >> > +++ b/net/mac80211/tx.c >> > @@ -1247,7 +1247,8 @@ static void ieee80211_drv_tx(struct >> > ieee80211_local *local, >> > struct txq_info *txqi; >> > u8 ac; >> > >> > - if (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE) >> > + if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) || >> > + (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE)) >> > goto tx_normal; >> > >> > if (!ieee80211_is_data(hdr->frame_control)) >> > -- >> > 2.2.2 >> >> I would like > > Feel free to propose patches for anything you like :) At the moment all I can do is cheer people on, and try to assemble enough gear to test comprehensively when enough patches have landed in your tree... Go, felix! Go, Michal! Go Mohammed! Go, Ben! Go Tim! Go, Emmanuel! Go Johannes! > > johannes >> -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
On Thu, 2016-03-03 at 21:30 +0530, Mohammed Shafi Shajakhan wrote: > [shafi] This is part of the Per Station statistics requirement, Heh. Whose requirements? :) > the information from 'iw dev wlan#N station dump' which has > rx_duration > field will be used by application assesing the statistics > /performance of various clients connected to our AP. We will plot > a graph based on this information (assesing the rx time spent by > AP for various clients). > > > > > Are you really sure you mean "unicast"? What if the station is the > > AP? Why wouldn't multicast frames it transmitted be accounted for? > > [shafi] This is based on the implementation by the driver/firmware. > We are focused on the AP side so unicast frames, if you are ok with > this change, i can change the documentation to be specific (generic > for all the drivers) something like implementation specific (please > advise) Ok, but for AP side I don't see the difference between "unicast" and "all frames", since all frames from that station should be unicast? Apart, perhaps, from some management frames the station might send outside the BSS, but that's not likely to matter much? IOW, why not specify all frames, and let this make some sense for other interface modes? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
Hi Johannes, thanks for taking time to review this. On Thu, Mar 03, 2016 at 04:46:23PM +0100, Johannes Berg wrote: > On Wed, 2016-03-02 at 19:38 +0530, Mohammed Shafi Shajakhan wrote: > > From: Mohammed Shafi Shajakhan > > > > Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION' > > This flag will be set when drivers can fill rx_duration ( approximate > > total air time(usecs) for unicast data/management frames from the > > connected client) via 'drv_sta_statistics' callback > > So, what's that useful for? [shafi] This is part of the Per Station statistics requirement, the information from 'iw dev wlan#N station dump' which has rx_duration field will be used by application assesing the statistics /performance of various clients connected to our AP. We will plot a graph based on this information (assesing the rx time spent by AP for various clients). > > Are you really sure you mean "unicast"? What if the station is the AP? > Why wouldn't multicast frames it transmitted be accounted for? [shafi] This is based on the implementation by the driver/firmware. We are focused on the AP side so unicast frames, if you are ok with this change, i can change the documentation to be specific (generic for all the drivers) something like implementation specific (please advise) > > > Also make sta_info flags 'filled' as 64 bit to accomodate for new > > typo: accommodate [shafi] will fix this regards, shafi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V11 1/2] nl80211: add feature for BSS selection support
On Wed, 2016-03-02 at 20:37 +0100, Arend van Spriel wrote: > Introducing a new feature that the driver can use to > indicate the driver/firmware supports configuration of BSS > selection criteria upon CONNECT command. This can be useful > when multiple BSS-es are found belonging to the same ESS, > ie. Infra-BSS with same SSID. The criteria can then be used to > offload selection of a preferred BSS. > Applied, finally :) I moved the wiphy supported methods check into parse_bss_select() to avoid the double error path in the caller, plus some editorial changes. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mac80211: add A-MSDU tx support
On 2016-03-03 16:37, Johannes Berg wrote: > On Thu, 2016-03-03 at 16:11 +0100, Felix Fietkau wrote: >> >> For my own uses, I'd be perfectly fine with limiting A-MSDU size to >> HT limits even when using VHT - in fact I did that in an early RFC >> patch. I mainly relaxed the limit for VHT based on Emmanuel's >> feedback. I also have doubts about the value of A-MSDU size beyond >> 4095 bytes. >> >> Just let me know which way you'd like it, and I'll send v3 >> accordingly. >> > > I don't really know, I can live with both ways. I'm just a bit worried > that we make enabling this feature so complex that nobody will get it > right. > > Perhaps we could also just remove this, make the default > for max_rc_amsdu_len be 4095 (or so) and leave the rest to the rate > control? We could entirely remove this check here, and let minstrel > only use higher values if VHT is supported (and consequently will be > used)? Yeah, that makes sense. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: synchronize driver rx queues before removing a station
On Wed, 2016-03-02 at 23:46 +0200, Emmanuel Grumbach wrote: > From: Sara Sharon > > Some devices, like iwlwifi, have RSS queues. This may cause a > situation where a disassociation is handled in control path and > results in station removal while there are prior RX frames > that were still not processed in other queues. When they will > be processed the station will be gone, and the frames will be > dropped. > Add a synchronization interface to avoid that. When driver returns > from the synchronization mac80211 may remove the station. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
On Wed, 2016-03-02 at 19:38 +0530, Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION' > This flag will be set when drivers can fill rx_duration ( approximate > total air time(usecs) for unicast data/management frames from the > connected client) via 'drv_sta_statistics' callback So, what's that useful for? Are you really sure you mean "unicast"? What if the station is the AP? Why wouldn't multicast frames it transmitted be accounted for? > Also make sta_info flags 'filled' as 64 bit to accomodate for new typo: accommodate johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211_hwsim: Set global RRM capability
On Wed, 2016-03-02 at 12:36 +, Grumbach, Emmanuel wrote: > > > I had the same thinking, but somehow people convinced me that a > driver may prefer not to advertise this without its explicit > consent. So ... What are the arguments? :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mac80211: recalc min_def chanctx even when chandef is identical
On Thu, 2016-03-03 at 17:41 +0200, Arik Nemtsov wrote: > On Thu, Mar 3, 2016 at 5:40 PM, Johannes Berg net> wrote: > > All three applied, but I had to fix your Fixes tag commit ID, no > > idea > > what that referred to :) > > Yea I might have taken it from some internal tree :) > Oh, actually what prompted me to look at all was that it was too short - should be 12 hex digits. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] rhashtable: accept GFP flags in rhashtable_walk_init
On Thu, Mar 03, 2016 at 04:26:19PM +0100, Johannes Berg wrote: > On Wed, 2016-03-02 at 10:09 -0500, Bob Copeland wrote: > > In certain cases, the 802.11 mesh pathtable code wants to > > iterate over all of the entries in the forwarding table from > > the receive path, which is inside an RCU read-side critical > > section. Enable walks inside atomic sections by allowing > > GFP_ATOMIC allocations for the walker state. > > > > Change all existing callsites to pass in GFP_KERNEL. > > Applied both. You missed 3 callsites, I've fixed those. I hope I got > them all :) Ouch, thanks for the catch, I must've grepped only in net. And now I added those files to my build config. :) -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mac80211: recalc min_def chanctx even when chandef is identical
On Thu, Mar 3, 2016 at 5:40 PM, Johannes Berg wrote: > All three applied, but I had to fix your Fixes tag commit ID, no idea > what that referred to :) Yea I might have taken it from some internal tree :) Arik -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mac80211: recalc min_def chanctx even when chandef is identical
All three applied, but I had to fix your Fixes tag commit ID, no idea what that referred to :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mac80211: add A-MSDU tx support
On Thu, 2016-03-03 at 16:11 +0100, Felix Fietkau wrote: > > For my own uses, I'd be perfectly fine with limiting A-MSDU size to > HT limits even when using VHT - in fact I did that in an early RFC > patch. I mainly relaxed the limit for VHT based on Emmanuel's > feedback. I also have doubts about the value of A-MSDU size beyond > 4095 bytes. > > Just let me know which way you'd like it, and I'll send v3 > accordingly. > I don't really know, I can live with both ways. I'm just a bit worried that we make enabling this feature so complex that nobody will get it right. Perhaps we could also just remove this, make the default for max_rc_amsdu_len be 4095 (or so) and leave the rest to the rate control? We could entirely remove this check here, and let minstrel only use higher values if VHT is supported (and consequently will be used)? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] rhashtable: accept GFP flags in rhashtable_walk_init
On Wed, 2016-03-02 at 10:09 -0500, Bob Copeland wrote: > In certain cases, the 802.11 mesh pathtable code wants to > iterate over all of the entries in the forwarding table from > the receive path, which is inside an RCU read-side critical > section. Enable walks inside atomic sections by allowing > GFP_ATOMIC allocations for the walker state. > > Change all existing callsites to pass in GFP_KERNEL. Applied both. You missed 3 callsites, I've fixed those. I hope I got them all :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mac80211: mesh: move path tables into if_mesh
On Sun, 2016-02-28 at 20:03 -0500, Bob Copeland wrote: > The mesh path and mesh gate hashtables are global, containing > all of the mpaths for every mesh interface, but the paths are > all tied logically to a single interface. The common case is > just a single mesh interface, so optimize for that by moving > the global hashtable into the per-interface struct. > > Doing so allows us to drop sdata pointer comparisons inside > the lookups and also saves a few bytes of BSS and data. > All 4 applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix AP buffered multicast frames with queue control and txq
On Sun, 2016-02-28 at 09:35 -0800, Dave Taht wrote: > On Sun, Feb 28, 2016 at 6:19 AM, Felix Fietkau > wrote: > > Buffered multicast frames must be passed to the driver directly via > > drv_tx instead of going through the txq, otherwise they cannot > > easily be > > scheduled to be sent after DTIM. > > > > Signed-off-by: Felix Fietkau > > --- > > net/mac80211/tx.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c > > index 3a7475f..b294820 100644 > > --- a/net/mac80211/tx.c > > +++ b/net/mac80211/tx.c > > @@ -1247,7 +1247,8 @@ static void ieee80211_drv_tx(struct > > ieee80211_local *local, > > struct txq_info *txqi; > > u8 ac; > > > > - if (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE) > > + if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) || > > + (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE)) > > goto tx_normal; > > > > if (!ieee80211_is_data(hdr->frame_control)) > > -- > > 2.2.2 > > I would like Feel free to propose patches for anything you like :) johannes > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rate
On Thu, 2016-03-03 at 16:03 +0100, Felix Fietkau wrote: > > > This isn't *quite* right, since you have to take an 802.11 header > > (vs. > > an ethernet header) into account, I think? > It's only a rough approximation anyway to prevent very large A-MSDUs > from being created with low rates. > Right, but it seemed like the intent was to allow two full-MTU sized frames to be combined, which this doesn't. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix AP buffered multicast frames with queue control and txq
On Sun, 2016-02-28 at 15:19 +0100, Felix Fietkau wrote: > Buffered multicast frames must be passed to the driver directly via > drv_tx instead of going through the txq, otherwise they cannot easily > be scheduled to be sent after DTIM. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rate
On 2016-03-03 16:07, Johannes Berg wrote: > On Thu, 2016-03-03 at 16:03 +0100, Felix Fietkau wrote: >> >> > This isn't *quite* right, since you have to take an 802.11 header >> > (vs. >> > an ethernet header) into account, I think? >> It's only a rough approximation anyway to prevent very large A-MSDUs >> from being created with low rates. >> > > Right, but it seemed like the intent was to allow two full-MTU sized > frames to be combined, which this doesn't. I'll look into it some more to see if it's better to change the comment or the code in this case. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mac80211: add A-MSDU tx support
On 2016-03-03 15:54, Johannes Berg wrote: > On Wed, 2016-02-24 at 10:28 +0100, Felix Fietkau wrote: >> >> +/* >> + * HT A-MPDU limits maximum MPDU size to 4095 bytes. Since aggregation >> + * sessions are started/stopped without txq flush, use the limit here >> + * to avoid having to de-aggregate later. >> + */ >> +if (skb->len + head->len > 4095 && >> +!sta->sta.vht_cap.vht_supported) >> +goto out; > > I'm not entirely happy with this. You're silently assuming that when > VHT is supported, HT MCSes will never be used. > > This is (I think) true for minstrel_ht, but at the very least you > should also document it along with the max_rc_amsdu_len then, which btw > I was going to reword to: > > + * @IEEE80211_HW_TX_AMSDU: Hardware (or driver) supports software aggregated > + * A-MSDU frames. Requires software tx queueing and fast-xmit support. > + * When not using minstrel/minstrel_ht rate control, the driver needs to > + * limit the maximum A-MSDU size based on the current tx rate by setting > + * max_rc_amsdu_len in struct ieee80211_sta to avoid mac80211 building > + * A-MSDUs that require too much airtime (are too long for a TXOP.) > > > All that said, I'm not sure how much value there really is in > aggregating that much? I'd think the value of A-MSDU really is more for > lots of small frames like TCP ACKs, since the PER goes up exponentially > with the BER for A-MSDU (unlike A-MPDU.) For my own uses, I'd be perfectly fine with limiting A-MSDU size to HT limits even when using VHT - in fact I did that in an early RFC patch. I mainly relaxed the limit for VHT based on Emmanuel's feedback. I also have doubts about the value of A-MSDU size beyond 4095 bytes. Just let me know which way you'd like it, and I'll send v3 accordingly. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] cfg80211: Allow a scan request for a specific BSSID
On Fri, 2016-02-26 at 22:12 +0200, Jouni Malinen wrote: > This allows scans for a specific BSSID to be optimized by the user > space > application by requesting the driver to set the Probe Request frame > BSSID field (Address 3) to the specified BSSID instead of the > wildcard > BSSID. This prevents other APs from replying which reduces airtime > need > and latency in getting the response from the target AP through. > > This is an optimization and as such, it is acceptable for some of the > drivers not to support the mechanism. If not supported, the wildcard > BSSID will be used and more responses may be received. > Applied all three. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rate
On 2016-03-03 15:55, Johannes Berg wrote: > On Wed, 2016-02-24 at 10:29 +0100, Felix Fietkau wrote: > >> +/* >> + * If the rate is slower than single-stream MCS4, limit A-MSDU to usual >> + * data packet size >> + */ >> +if (g->duration[rate] > MCS_DURATION(1, 0, 104)) >> +return 1500; >> + >> +/* >> + * If the rate is slower than single-stream MCS7, limit A-MSDU to twice >> + * the usual data packet size >> + */ >> +if (g->duration[rate] > MCS_DURATION(1, 0, 260)) >> +return 3000; > > This isn't *quite* right, since you have to take an 802.11 header (vs. > an ethernet header) into account, I think? It's only a rough approximation anyway to prevent very large A-MSDUs from being created with low rates. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: use ieee80211_band in kernel space
On Thu, 2016-02-25 at 13:59 +0100, Arend Van Spriel wrote:
> On 25-2-2016 12:32, Arend van Spriel wrote:
> > The enumeration nl80211_band intends to expose the public part of
> > ieee80211_band enumeration. As such it should not be used in the
> > kernel. This patch changes nl80211_band usage to ieee80211_band.
> >
> Fixes: 59ad2160c285 ("nl80211: add feature for BSS selection
> support")
>
> Not sure if it is any of the trees already.
>
I'm tempted to just get rid of ieee80211_band and move the NUM thing to
nl80211.h.
Thoughts?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: document only injected *_RADIOTAP_* flags
On Wed, 2016-02-24 at 16:25 +0100, Sven Eckelmann wrote: > Not the internal flags but the radiotap flags are parsed when the > monitor > injected frames are prepared for transmission. Thus the documentation > should only document these. > Both applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: do not pass injected frames without a valid rate to the driver
On Wed, 2016-03-02 at 15:54 +0100, Felix Fietkau wrote: > Fall back to rate control if the requested bitrate was not found. > Applied, thakns. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mac80211: allow not sending MIC up from driver for HW crypto
On Wed, 2016-02-24 at 11:49 +0200, Emmanuel Grumbach wrote: > From: Sara Sharon > > When HW crypto is used, there's no need for the CCMP/GCMP MIC to > be available to mac80211, and the hardware might have removed it > already after checking. The MIC is also useless to have when the > frame is already decrypted, so allow indicating that it's not > present. > > Since we are running out of bits in mac80211_rx_flags, make > the flags field a u64. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rate
On Wed, 2016-02-24 at 10:29 +0100, Felix Fietkau wrote: > + /* > + * If the rate is slower than single-stream MCS4, limit A-MSDU to usual > + * data packet size > + */ > + if (g->duration[rate] > MCS_DURATION(1, 0, 104)) > + return 1500; > + > + /* > + * If the rate is slower than single-stream MCS7, limit A-MSDU to twice > + * the usual data packet size > + */ > + if (g->duration[rate] > MCS_DURATION(1, 0, 260)) > + return 3000; This isn't *quite* right, since you have to take an 802.11 header (vs. an ethernet header) into account, I think? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mac80211: add A-MSDU tx support
On Wed, 2016-02-24 at 10:28 +0100, Felix Fietkau wrote: > > + /* > + * HT A-MPDU limits maximum MPDU size to 4095 bytes. Since aggregation > + * sessions are started/stopped without txq flush, use the limit here > + * to avoid having to de-aggregate later. > + */ > + if (skb->len + head->len > 4095 && > + !sta->sta.vht_cap.vht_supported) > + goto out; I'm not entirely happy with this. You're silently assuming that when VHT is supported, HT MCSes will never be used. This is (I think) true for minstrel_ht, but at the very least you should also document it along with the max_rc_amsdu_len then, which btw I was going to reword to: + * @IEEE80211_HW_TX_AMSDU: Hardware (or driver) supports software aggregated + * A-MSDU frames. Requires software tx queueing and fast-xmit support. + * When not using minstrel/minstrel_ht rate control, the driver needs to + * limit the maximum A-MSDU size based on the current tx rate by setting + * max_rc_amsdu_len in struct ieee80211_sta to avoid mac80211 building + * A-MSDUs that require too much airtime (are too long for a TXOP.) All that said, I'm not sure how much value there really is in aggregating that much? I'd think the value of A-MSDU really is more for lots of small frames like TCP ACKs, since the PER goes up exponentially with the BER for A-MSDU (unlike A-MPDU.) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] mac80211: parse VHT info in injected frames
> On Tue, 2016-02-23 at 15:43 +0100, Lorenzo Bianconi wrote: >> Add VHT radiotap parsing support to ieee80211_parse_tx_radiotap(). >> That capability has been tested using a d-link dir-860l rev b1 >> running OpenWrt trunk and mt76 driver >> > Applied. In case you didn't see, Sven sent a patch to fix the other > docs. Yes, I did not send the patch since I had seen the one sent by Sven :-) > > johannes Regards, Lorenzo -- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] mac80211: parse VHT info in injected frames
On Tue, 2016-02-23 at 15:43 +0100, Lorenzo Bianconi wrote: > Add VHT radiotap parsing support to ieee80211_parse_tx_radiotap(). > That capability has been tested using a d-link dir-860l rev b1 > running OpenWrt trunk and mt76 driver > Applied. In case you didn't see, Sven sent a patch to fix the other docs. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] staging: wilc1000: remove unnecessary comments
This patch removes unnecessary comments because enum cfg_cmd_type
shows each command type without it.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/wilc_wlan_cfg.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index 9cf68b7..92f6d32 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -378,18 +378,18 @@ int wilc_wlan_cfg_set_wid(u8 *frame, u32 offset, u16 id,
u8 *buf, int size)
u8 type = (id >> 12) & 0xf;
int ret = 0;
- if (type == CFG_BYTE_CMD) {/*
byte command */
+ if (type == CFG_BYTE_CMD) {
if (size >= 1)
ret = wilc_wlan_cfg_set_byte(frame, offset, id, *buf);
- } else if (type == CFG_HWORD_CMD) { /* half word
command */
+ } else if (type == CFG_HWORD_CMD) {
if (size >= 2)
ret = wilc_wlan_cfg_set_hword(frame, offset, id, *((u16
*)buf));
- } else if (type == CFG_WORD_CMD) { /* word command */
+ } else if (type == CFG_WORD_CMD) {
if (size >= 4)
ret = wilc_wlan_cfg_set_word(frame, offset, id, *((u32
*)buf));
- } else if (type == CFG_STR_CMD) { /* string command */
+ } else if (type == CFG_STR_CMD) {
ret = wilc_wlan_cfg_set_str(frame, offset, id, buf, size);
- } else if (type == CFG_BIN_CMD) { /* binary command */
+ } else if (type == CFG_BIN_CMD) {
ret = wilc_wlan_cfg_set_bin(frame, offset, id, buf, size);
}
@@ -422,7 +422,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i = 0;
- if (type == CFG_BYTE_CMD) {/*
byte command */
+ if (type == CFG_BYTE_CMD) {
do {
if (g_cfg_byte[i].id == WID_NIL)
break;
@@ -434,7 +434,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i++;
} while (1);
- } else if (type == CFG_HWORD_CMD) { /* half word
command */
+ } else if (type == CFG_HWORD_CMD) {
do {
if (g_cfg_hword[i].id == WID_NIL)
break;
@@ -446,7 +446,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i++;
} while (1);
- } else if (type == CFG_WORD_CMD) { /* word command */
+ } else if (type == CFG_WORD_CMD) {
do {
if (g_cfg_word[i].id == WID_NIL)
break;
@@ -458,7 +458,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i++;
} while (1);
- } else if (type == CFG_STR_CMD) { /* string command */
+ } else if (type == CFG_STR_CMD) {
do {
if (g_cfg_str[i].id == WID_NIL)
break;
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] staging: wilc1000: use switch statement instead of multiple if statement
It is more readable than multiple if-else statement.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/wilc_wlan_cfg.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index 92f6d32..b3425b9 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -378,19 +378,31 @@ int wilc_wlan_cfg_set_wid(u8 *frame, u32 offset, u16 id,
u8 *buf, int size)
u8 type = (id >> 12) & 0xf;
int ret = 0;
- if (type == CFG_BYTE_CMD) {
+ switch (type) {
+ case CFG_BYTE_CMD:
if (size >= 1)
ret = wilc_wlan_cfg_set_byte(frame, offset, id, *buf);
- } else if (type == CFG_HWORD_CMD) {
+ break;
+
+ case CFG_HWORD_CMD:
if (size >= 2)
- ret = wilc_wlan_cfg_set_hword(frame, offset, id, *((u16
*)buf));
- } else if (type == CFG_WORD_CMD) {
+ ret = wilc_wlan_cfg_set_hword(frame, offset, id,
+ *((u16 *)buf));
+ break;
+
+ case CFG_WORD_CMD:
if (size >= 4)
- ret = wilc_wlan_cfg_set_word(frame, offset, id, *((u32
*)buf));
- } else if (type == CFG_STR_CMD) {
+ ret = wilc_wlan_cfg_set_word(frame, offset, id,
+*((u32 *)buf));
+ break;
+
+ case CFG_STR_CMD:
ret = wilc_wlan_cfg_set_str(frame, offset, id, buf, size);
- } else if (type == CFG_BIN_CMD) {
+ break;
+
+ case CFG_BIN_CMD:
ret = wilc_wlan_cfg_set_bin(frame, offset, id, buf, size);
+ break;
}
return ret;
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] staging: wilc1000: add enum cfg_type_cmd
This patch adds a new enum cfg_type_cmd to change hard-coded command
type.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/wilc_wlan_cfg.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index 6a33187..9cf68b7 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -18,6 +18,13 @@
* Global Data
*
/
+enum cfg_cmd_type {
+ CFG_BYTE_CMD= 0,
+ CFG_HWORD_CMD = 1,
+ CFG_WORD_CMD= 2,
+ CFG_STR_CMD = 3,
+ CFG_BIN_CMD = 4
+};
struct wilc_mac_cfg {
int mac_status;
@@ -371,18 +378,18 @@ int wilc_wlan_cfg_set_wid(u8 *frame, u32 offset, u16 id,
u8 *buf, int size)
u8 type = (id >> 12) & 0xf;
int ret = 0;
- if (type == 0) {/* byte command
*/
+ if (type == CFG_BYTE_CMD) {/*
byte command */
if (size >= 1)
ret = wilc_wlan_cfg_set_byte(frame, offset, id, *buf);
- } else if (type == 1) { /* half word command */
+ } else if (type == CFG_HWORD_CMD) { /* half word
command */
if (size >= 2)
ret = wilc_wlan_cfg_set_hword(frame, offset, id, *((u16
*)buf));
- } else if (type == 2) { /* word command */
+ } else if (type == CFG_WORD_CMD) { /* word command */
if (size >= 4)
ret = wilc_wlan_cfg_set_word(frame, offset, id, *((u32
*)buf));
- } else if (type == 3) { /* string command */
+ } else if (type == CFG_STR_CMD) { /* string command */
ret = wilc_wlan_cfg_set_str(frame, offset, id, buf, size);
- } else if (type == 4) { /* binary command */
+ } else if (type == CFG_BIN_CMD) { /* binary command */
ret = wilc_wlan_cfg_set_bin(frame, offset, id, buf, size);
}
@@ -415,7 +422,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i = 0;
- if (type == 0) {/* byte command
*/
+ if (type == CFG_BYTE_CMD) {/*
byte command */
do {
if (g_cfg_byte[i].id == WID_NIL)
break;
@@ -427,7 +434,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i++;
} while (1);
- } else if (type == 1) { /* half word command */
+ } else if (type == CFG_HWORD_CMD) { /* half word
command */
do {
if (g_cfg_hword[i].id == WID_NIL)
break;
@@ -439,7 +446,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i++;
} while (1);
- } else if (type == 2) { /* word command */
+ } else if (type == CFG_WORD_CMD) { /* word command */
do {
if (g_cfg_word[i].id == WID_NIL)
break;
@@ -451,7 +458,7 @@ int wilc_wlan_cfg_get_wid_value(u16 wid, u8 *buffer, u32
buffer_size)
}
i++;
} while (1);
- } else if (type == 3) { /* string command */
+ } else if (type == CFG_STR_CMD) { /* string command */
do {
if (g_cfg_str[i].id == WID_NIL)
break;
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] staging: wilc1000: remove commented codes
This patch removes commented codes in struct wilc_cfg_str.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/wilc_wlan_cfg.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index b992243..b25d772 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -136,7 +136,6 @@ static struct wilc_cfg_str g_cfg_str[] = {
{WID_BSSID, g_mac.bssid}, /* 6 bytes */
{WID_WEP_KEY_VALUE, g_mac.wep_key}, /* 27 bytes */
{WID_11I_PSK, g_mac.i_psk}, /* 65 bytes */
- /* {WID_11E_P_ACTION_REQ, g_mac.action_req}, */
{WID_HARDWARE_VERSION, g_mac.hardwareProductVersion},
{WID_MAC_ADDR, g_mac.mac_address},
{WID_PHY_VERSION, g_mac.phyversion},
@@ -144,10 +143,8 @@ static struct wilc_cfg_str g_cfg_str[] = {
{WID_SUPP_PASSWORD, g_mac.supp_password},
{WID_SITE_SURVEY_RESULTS, g_mac.scan_result},
{WID_SITE_SURVEY_RESULTS, g_mac.scan_result1},
- /* {WID_RX_POWER_LEVEL, g_mac.channel_rssi}, */
{WID_ASSOC_REQ_INFO, g_mac.assoc_req},
{WID_ASSOC_RES_INFO, g_mac.assoc_rsp},
- /* {WID_11N_P_ACTION_REQ, g_mac.action_req}, */
{WID_FIRMWARE_INFO, g_mac.firmware_version},
{WID_IP_ADDRESS, g_mac.ip_address},
{WID_NIL, NULL}
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] staging: wilc1000: rename hardwareProductVersion in struct wilc_mac_cfg
This patch renames hardwareProductVersion to hw_product_version to avoid
camelcase.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/wilc_wlan_cfg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c
b/drivers/staging/wilc1000/wilc_wlan_cfg.c
index b25d772..6a33187 100644
--- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
+++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
@@ -29,7 +29,7 @@ struct wilc_mac_cfg {
u8 supp_rate[24];
u8 wep_key[28];
u8 i_psk[66];
- u8 hardwareProductVersion[33];
+ u8 hw_product_version[33];
u8 phyversion[17];
u8 supp_username[21];
u8 supp_password[64];
@@ -136,7 +136,7 @@ static struct wilc_cfg_str g_cfg_str[] = {
{WID_BSSID, g_mac.bssid}, /* 6 bytes */
{WID_WEP_KEY_VALUE, g_mac.wep_key}, /* 27 bytes */
{WID_11I_PSK, g_mac.i_psk}, /* 65 bytes */
- {WID_HARDWARE_VERSION, g_mac.hardwareProductVersion},
+ {WID_HARDWARE_VERSION, g_mac.hw_product_version},
{WID_MAC_ADDR, g_mac.mac_address},
{WID_PHY_VERSION, g_mac.phyversion},
{WID_SUPP_USERNAME, g_mac.supp_username},
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] staging: wilc1000: use TAG_PARAM_OFFSET define
TAG_PARAM_OFFSET is defined at top of this file so that it is used
to simplify codes.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/coreconfigurator.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 25dc108..2c4ae1f 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -178,10 +178,8 @@ static inline void get_ssid(u8 *data, u8 *ssid, u8
*p_ssid_len)
u8 i = 0;
u8 j = 0;
- len = data[MAC_HDR_LEN + TIME_STAMP_LEN + BEACON_INTERVAL_LEN +
- CAP_INFO_LEN + 1];
- j = MAC_HDR_LEN + TIME_STAMP_LEN + BEACON_INTERVAL_LEN +
- CAP_INFO_LEN + 2;
+ len = data[TAG_PARAM_OFFSET + 1];
+ j = TAG_PARAM_OFFSET + 2;
if (len >= MAX_SSID_LEN)
len = 0;
@@ -335,10 +333,8 @@ s32 wilc_parse_network_info(u8 *msg_buffer,
tim_elm = get_tim_elm(msa, rx_len + FCS_LEN, index);
if (tim_elm)
network_info->dtim_period = tim_elm[3];
- ies = &msa[MAC_HDR_LEN + TIME_STAMP_LEN + BEACON_INTERVAL_LEN +
- CAP_INFO_LEN];
- ies_len = rx_len - (MAC_HDR_LEN + TIME_STAMP_LEN +
- BEACON_INTERVAL_LEN + CAP_INFO_LEN);
+ ies = &msa[TAG_PARAM_OFFSET];
+ ies_len = rx_len - TAG_PARAM_OFFSET;
if (ies_len > 0) {
network_info->ies = kmemdup(ies, ies_len, GFP_KERNEL);
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: mesh: convert path table to rhashtable
On Wed, 2016-03-02 at 14:43 -0500, David Miller wrote: > From: Bob Copeland > Date: Wed, 2 Mar 2016 10:09:20 -0500 > > > In the time since the mesh path table was implemented as an > > RCU-traversable, dynamically growing hash table, a generic RCU > > hashtable implementation was added to the kernel. > > > > Switch the mesh path table over to rhashtable to remove some code > > and also gain some features like automatic shrinking. > > > > Cc: Thomas Graf > > Cc: net...@vger.kernel.org > > Signed-off-by: Bob Copeland > > Johannes, feel free to take both patches via your tree, thanks. Will do, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nfc: pn544: Drop two useless checks in ACPI probe path
Hi Mika, On Thu, Mar 03, 2016 at 11:26:18AM +0200, Mika Westerberg wrote: > When pn544_hci_i2c_acpi_request_resources() gets called we already know > that the entries in ->acpi_match_table have matched ACPI ID of the device. > In addition I2C client pointer cannot be NULL in any case (otherwise I2C > core would not call ->probe() for the driver in the first place). > > Drop the two useless checks from the driver. > > Signed-off-by: Mika Westerberg > --- > drivers/nfc/pn544/i2c.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) Applied to nfc-next, thanks. Cheers, Samuel. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] nfc: pn544: Drop two useless checks in ACPI probe path
When pn544_hci_i2c_acpi_request_resources() gets called we already know
that the entries in ->acpi_match_table have matched ACPI ID of the device.
In addition I2C client pointer cannot be NULL in any case (otherwise I2C
core would not call ->probe() for the driver in the first place).
Drop the two useless checks from the driver.
Signed-off-by: Mika Westerberg
---
drivers/nfc/pn544/i2c.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index 76c318444304..45d0e667d7ae 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -877,20 +877,8 @@ exit_state_wait_secure_write_answer:
static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
{
struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
- const struct acpi_device_id *id;
struct gpio_desc *gpiod_en, *gpiod_fw;
- struct device *dev;
-
- if (!client)
- return -EINVAL;
-
- dev = &client->dev;
-
- /* Match the struct device against a given list of ACPI IDs */
- id = acpi_match_device(dev->driver->acpi_match_table, dev);
-
- if (!id)
- return -ENODEV;
+ struct device *dev = &client->dev;
/* Get EN GPIO from ACPI */
gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1,
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
