Hi all.
Out of history, the ath5k-devel and ath9k-devel mailing lists were hosted
on the mailing list server of the MadWifi project. I intend to shut the
server down, though, as the MadWifi project has ceased.
While in the past - back when both ath5k and ath9k were not yet part of
the kernel
lid user account for that to do, and I don't
have one atm.
[1] https://wireless.wiki.kernel.org/en/users/Drivers/ath9k
Bye, Mike
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS
--
https://patchwork.kernel.org/patch/9505653/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______
"Michael Renzmann" <mrenzm...@madwifi-project.org> writes:
> Out of history, the ath5k-devel and ath9k-devel mailing lists have been
> and still are hosted on the mailing list server of the MadWifi project. I
> intend to shut the server down, and thus I'm se
kernel.org/en/developers/documentation/submittingpatches
___________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
tland <mark.rutl...@arm.com>
> Cc: ath9k-de...@qca.qualcomm.com
> Cc: Kalle Valo <kv...@codeaurora.org>
> Cc: linux-wirel...@vger.kernel.org
> Cc: ath9k-devel@lists.ath9k.org
> Cc: net...@vger.kernel.org
2 patches applied to ath-next branch of ath.git, thanks.
d5a3a76a
, u32 size,
struct modal_eep_header *modal_hdr)
{
--
2.11.0
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
8>
No complaints so far so I guess people don't have any issues :) Please
submit this as a proper patch and if there are no comments I'll apply
it.
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
:
https://github.com/cozybit/authsae/issues/42
Kind regards,
Michel Stam
-Original Message-
From: ath9k-devel-boun...@lists.ath9k.org
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Antonio Quartulli
Sent: Saturday, October 22, 2016 15:42 PM
To: ath9k-devel@lists.ath9k.org
Cc
Hi all.
Out of history, the ath5k-devel and ath9k-devel mailing lists have been
and still are hosted on the mailing list server of the MadWifi project. I
intend to shut the server down, and thus I'm searching a new loving home
for the lists.
Besides a new home the lists also need some attention
to
be moderated. It appears that we've lost all the three people who in the
past were moderating ath5k-devel and ath9k-devel, for unknown reasons and
without notice. Thus I took care of the moderation queue, waved through
what looked like ham and got rid of tons of spam.
Sorry for any
to be
changed it might change some behaviour but I still don't understand
for which models and what should be tested exactly. It might break
something, but it still looks like a typo, doesn't it ? At least it's
confusing.
Thank you for reading.
--
Xavi Drudis Ferran
_____
ich isn't latency
sensitive). The only local services that I know of that could use
maximal-rate wifi are NAS systems using SMB, AFP, etc.
-Aaron
___________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
] [] ? wake_up_klogd+0x34/0x40
[ 64.084860] [] ? console_unlock+0x531/0x560
[ 64.087822] [] ? vprintk_emit+0x2bb/0x520
[ 64.090769] [] ? vprintk_default+0x29/0x40
thanks,
Mimi
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org
t.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=05860bed491b114a9f2d7a4f6e09fb02c0b69056
Yep, that resolved the problem. Thanks!
Mimi
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
The use of config_enabled() against config options is ambiguous.
In practical terms, config_enabled() is equivalent to IS_BUILTIN(),
but the author might have used it for the meaning of IS_ENABLED().
Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the
intention clearer.
This commit
?
Thanks
-Shengrong
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> now we get maximal testing time on -next.
So the -next trees are those that are open outside the merge window.
Right, got it; thanks :)
>>> And I assume I need to take v5:
>>>
>>> https://patchwork.kernel.org/patch/9311037/
>>
>> Yes. Haven't noticed anything that changed since that might conflict
>> with it, but let me know if I missed something and you want a refreshed
>> version.
>
> Thanks, I'll let you know if there are any problems.
Cool.
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ch/9311037/
Yes. Haven't noticed anything that changed since that might conflict
with it, but let me know if I missed something and you want a refreshed
version.
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
art getting lots of bug reports and eventually forced to revert it. If
> we just found a new serious regression the chances are that there are
> more lurking somewhere and this patch is just not ready yet.
So, the changes to mac80211 that fixes the known regressions of this
patch have gone in. Any chance of seeing this merged during the current
merge window? :)
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
.
Regards,
Umar Ali
0049-174-3801500
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
patches are ready to apply in two
> weeks. That would leave us only two weeks of -next time before the merge
> window, which I think is not enough for a controversial patch like this
> one. There might be other bugs lurking which haven't been found yet.
What, other hidden bugs? Unpossib
t still...). I already have a patch for the fast path and will go poke
at the slow path next. It'll probably require another workaround or two,
so I guess it won't be the architecturally clean ideal solution; but it
would make it possible to have something that works for 4.9 and then
iterate for a cleaner design for 4.10.
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ell? Or do I just dump the patch files
>> into the LEDE patches dir and send that as a patch to LEDE? (I see your
>> patch also refreshed subsequent patches; is there a script to do that
>> automatically?)
> You don't need to do anything here. LEDE does not use mac80211 and
> drivers from the kernel tree, it's built using backports.
> It's currently using a backports snapshot that I built myself from
> wireless-testing 2016-06-20, which already includes FQ-Codel.
Ah, didn't know that. Cool; and thanks for taking care of the
backporting :)
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Sebastian Gottschall <s.gottsch...@dd-wrt.com> writes:
> for me it crashes on wds sta on 3.18 kernels.
Bugger :/
> need to solder a serial to get more logs
That would be helpful :)
-Toke
___
ath9k-devel mailing list
ath9k-devel@lis
- Ted
___________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
tid->seq_start = tid->seq_next = 0;
@@ -2866,11 +2785,14 @@ void ath_tx_node_init(struct ath_softc *sc, struct
ath_node *an)
tid->baw_head = tid->baw_tail = 0;
tid->active= false;
tid->clear_ps_filter = true;
- __skb_queue_head_init(>buf_q);
+ tid->has_queued = false;
__skb_queue_head_init(>retry_q);
INIT_LIST_HEAD(>list);
acno = TID_TO_WME_AC(tidno);
tid->txq = sc->tx.txq_map[acno];
+
+ if (!an->sta)
+ break; /* just one multicast ath_atx_tid */
}
}
@@ -2880,9 +2802,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
struct ath_txq *txq;
int tidno;
- for (tidno = 0, tid = >tid[tidno];
-tidno < IEEE80211_NUM_TIDS; tidno++, tid++) {
-
+ for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
+ tid = ath_node_to_tid(an, tidno);
txq = tid->txq;
ath_txq_lock(sc, txq);
@@ -2894,6 +2815,9 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
tid->active = false;
ath_txq_unlock(sc, txq);
+
+ if (!an->sta)
+ break; /* just one multicast ath_atx_tid */
}
}
--
2.9.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
oored it out the wazoo, it won't do any
harm --- where as using the hwrng framework would be disastrous.
Cheerfs,
- Ted
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
non-data and data packets could be combined to overflow
> this limit (since I failed to check overflowing this limit where I
> pulled from the mac80211 intermediate queue).
Hmm, I'm not sure I can confidently say that what you describe would
never happen. But I'm pretty sure that ATH_MAX_QDEPTH wasn't what was
keeping it from happening...
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
where I've separated out the needed patches and rebased them on
mainline 4.4.9. Can I post that somewhere (or just email you the series)
and get you to include those as well? Or do I just dump the patch files
into the LEDE patches dir and send that as a patch to LEDE? (I see your
patch also refreshed subsequent patches; is there a script to do that
automatically?)
> I don't have time for testing it myself at the moment, but I'll try to
> get some people to do so.
Awesome :)
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
tid->an= an;
tid->tidno = tidno;
tid->seq_start = tid->seq_next = 0;
@@ -2866,11 +2797,14 @@ void ath_tx_node_init(struct ath_softc *sc, struct
ath_node *an)
tid->baw_head = tid->baw_tail = 0;
this can happen, but if we ever somehow end up with two skbs
>>> in the retry queue that do not fit into the Block-Ack window, there's
>>> potential for an infinite loop here.
>>
>> Yes, I realise that (v1 contained a comment on that). However, I don't
>> actually think it can happen: The code will only ever put one skb from
>> the intermediate queues on the retry queue (ath_tid_pull() is only
>> called if the retry queue is empty). Everything else on there are actual
>> retries that have been put on there by ath_tx_complete_aggr(). Figure
>> the latter will always be within the BAW?
> I think it would be a good idea to have a check there (with WARN_ON), in
> case there's some weird corner case with seqno handling, software retry
> and aggregation state changes.
Right, can do :)
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
as well.
> Testing and review feedback very welcome!
My own evaluation results are here:
https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html
-- I see aggregate throughput to multiple stations improve by a factor
of ~3 and latency under load decrease by a fact
() and wind up in the scenario above.
Well, presumably the upper layers won't try to transmit anything through
the old TX path if the start/stop logic is implemented properly. The
chanctx code already seems to call the ieee80211_{start,stop}_queue()
functions when changing context, so not sure what
tid->tidno = tidno;
tid->seq_start = tid->seq_next = 0;
@@ -2866,11 +2794,14 @@ void ath_tx_node_init(struct ath_softc *sc, struct
ath_node *an)
tid->baw_head = tid->baw_tail = 0;
tid->active = false;
tid->clear_ps_filter = true;
- __skb_queue_head_init(>buf_q);
+ tid->has_queued = false;
__skb_queue_head_init(>retry_q);
INIT_LIST_HEAD(>list);
acno = TID_TO_WME_AC(tidno);
tid->txq = sc->tx.txq_map[acno];
+
+ if (!an->sta)
+ break; /* just one multicast ath_atx_tid */
}
}
@@ -2880,9 +2811,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
struct ath_txq *txq;
int tidno;
- for (tidno = 0, tid = >tid[tidno];
-tidno < IEEE80211_NUM_TIDS; tidno++, tid++) {
-
+ for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
+ tid = ATH_AN_2_TID(an, tidno);
txq = tid->txq;
ath_txq_lock(sc, txq);
@@ -2894,6 +2824,9 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
tid->active = false;
ath_txq_unlock(sc, txq);
+
+ if (!an->sta)
+ break; /* just one multicast ath_atx_tid */
}
}
--
2.9.0
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
continue;
> Not sure if this can happen, but if we ever somehow end up with two skbs
> in the retry queue that do not fit into the Block-Ack window, there's
> potential for an infinite loop here.
Yes, I realise that (v1 contained a comment on that). However, I don't
actually think it
to improve it?
Thanks,
Dat
--
Thanks,
Dat
Sending from my iPhone
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
gt;tx.txq_map[acno];
+
+ if (!an->sta)
+ break; /* just one multicast ath_atx_tid */
}
}
@@ -2880,9 +2864,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
struct ath_txq *txq;
int tidno;
- for (tidno = 0, tid = >tid[tidno];
-tidno < IEEE80211_NUM_TIDS; tidno++, tid++) {
-
+ for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
+ tid = ATH_AN_2_TID(an, tidno);
txq = tid->txq;
ath_txq_lock(sc, txq);
@@ -2894,6 +2877,9 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
tid->active = false;
ath_txq_unlock(sc, txq);
+
+ if (!an->sta)
+ break; /* just one multicast ath_atx_tid */
}
}
--
2.8.3
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
e: they are limited a maximum of four milliseconds of (estimated)
airtime (for the BE queue; the others have different limits).
So in a sense there's already a dynamic limit on the hardware queues.
Now, whether four milliseconds is the right maximum aggregate size might
be worth discussing. It is the maximum allowed by the standard. Dave and
I have been
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
intermediate queue.
>
> Any frame that was pulled from the intermediate queue and prepared for
> tx, but which can't be sent right now can simply be queued to retry_q.
Right.
> This will also help with getting the diffstat insertion/deletion ratio
> under control ;)
Yes, that would
I doubt there is much to be gained to add a mechanism
to dynamically tune them (between 0 and 2?).
The exception being in case pulling from the mac80211 queue is too slow
to keep the hardware busy at the current settings. I see no problems
with this on my hardware, but that's an x86 box. I would p
there yet (to say the
least), so if you have a less buggy base I can work from that would be
cool ;)
-Toke
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
'm fine with having the RX side airtime accounting just ignore the
retransmission issue, at least for now.
-Toke
___________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
net/wireless/ath/ath9k/recv.c | 60 +++
drivers/net/wireless/ath/ath9k/xmit.c | 255 ++---
9 files changed, 386 insertions(+), 69 deletions(-)
--
2.8.3
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
ht
ardware queues
+* full.
+*
+* If we dequeued from a new queue, shuffle the queues, to prevent it
+* from hogging too much airtime. */
+ if(ath_tx_sched_aggr(sc, txq, tid)) {
+ if (!active || ((tid_list == >acq_new) &&
!list_empty(>acq_old)))
+ list_move_tail(>list, >acq_old);
+ goto begin;
}
+out:
rcu_read_unlock();
spin_unlock_bh(>chan_lock);
}
@@ -2931,6 +2981,8 @@ void ath_tx_node_init(struct ath_softc *sc, struct
ath_node *an)
struct ath_atx_tid *tid;
int tidno, acno;
+ an->airtime_deficit = 300;
+
for (tidno = 0;
tidno < IEEE80211_NUM_TIDS;
tidno++) {
--
2.8.3
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
rtime figures that correspond fairly well to
the TX airtime for running the same test in the opposite direction (I'm
running a ten-second UDP flood test and looking at the total airtime
accounted after the end of the run).
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ion? Will try doing that
and see what the result is.
-Toke
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
no++, tid++) {
+ for (tidno = 0;
+tidno < IEEE80211_NUM_TIDS; tidno++) {
+ swq = sta ? sta->txq[tidno] : vif->txq;
+ tid = (struct ath_atx_tid *) swq->drv_priv;
txq = tid->txq;
ath_txq_lock(sc, txq);
@@ -2894,6 +2982,9 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
tid->active = false;
ath_txq_unlock(sc, txq);
+
+ if (!sta)
+ break; /* just one multicast ath_atx_tid */
}
}
--
2.8.3
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
on is how much this really
contributes (at least in cases where we are not running behind because
of lack of CPU). And if there's a constant overhead it shouldn't matter
so much as long as it is the same for all stations. Certainly just
timestamping packets with the current time works well enough in the
qdisc layer...
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
iming. But there's only a timestamp of
the first symbol in rs_tstamp, and getting a time to compare it with is
difficult; by the time the frame is handled in the rx tasklet, way too
much time has been spent on interrupt handling etc for the current time
to be worth comparing with.
-Toke
___
eceived before the RX handler is called for the
first frame?
-Toke
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
way to fix my bug in the <=
> v2 patch where I fail to respect the hwq_max_pending values on the new
> transmit path, and I plan to post a v3 patch when I get that done.
What's the symptom of this? As I said I haven't noticed anything, but it
might be worth looking out for.
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ation from a
register in the hardware. There seems to be registers containing the
duration spent on each step in the retry chain; I simply sum these.
-Toke
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
or the
suggestion :)
-Toke
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
__
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
te entry). Am I wrong in thinking so? Or is this something else
entirely?
-Toke
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
-
if (ac_queue == queue ||
(sdata->vif.cab_queue == queue &&
local->queue_stop_reasons[ac_queue] == 0 &&
@@ -341,6 +339,9 @@ static void __ieee80211_stop_queue(struct ieee80211_hw *hw,
int queue,
trace_stop_queue(local, queue, reason);
+ if (local->ops->wake_tx_queue)
+ return;
+
if (WARN_ON(queue >= hw->queues))
return;
--
2.7.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
rcu_read_unlock();
spin_unlock_bh(>chan_lock);
}
@@ -2934,6 +2991,8 @@ void ath_tx_node_init(struct ath_softc *sc, struct
ath_node *an)
struct ath_atx_tid *tid;
int tidno, acno;
+ an->airtime_deficit = 300;
+
for (tidno = 0;
tidno < IEEE80211_NUM_TIDS;
tidno++) {
--
2.7.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
no++, tid++) {
+ for (tidno = 0;
+tidno < IEEE80211_NUM_TIDS; tidno++) {
+ swq = sta ? sta->txq[tidno] : vif->txq;
+ tid = (struct ath_atx_tid *) swq->drv_priv;
txq = tid->txq;
ath_txq_lock(sc, txq);
@@ -2894,6 +2982,9 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct
ath_node *an)
tid->active = false;
ath_txq_unlock(sc, txq);
+
+ if (!sta)
+ break; /* just one multicast ath_atx_tid */
}
}
--
2.7.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
r *)skb->data;
if (ieee80211_is_ack(hdr->frame_control))
--
2.7.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
symbol time
*/
-static u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
- int width, int half_gi, bool shortPreamble)
+u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
+ int width, int half_gi, bool shortPreamble)
{
showed up.
-Toke
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
- to use 4us v/s 3.6 us for symbol time
*/
-static u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
- int width, int half_gi, bool shortPreamble)
+u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
+ int width, int half_gi, bool
rc_status).
I'll go digging. Thanks, this was exactly the kind of feedback I had
hoped for! :)
-Toke
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
wer control on
> > TX99 for AR9280
> > Are there any patches around that would allow me to set the output power of
> > AR9280 on TX99 mode?
> > How is the power control made on TX99 mode for AR9280?
> >
> > Thanks in Advance,
> >
> > Luiz Oliveira Neto
> > ____
> ath_tx_edma_tasklet(), but failed to add the needed rcu_read_unlock()
> before a "return" in the middle of this function. This commit therefore
> adds the missing rcu_read_unlock().
>
> Reported-by: Gabriel C <nix.or@gmail.com>
> Sign
based devices (AR93XX, AR94XX, AR95XX), AR9002 based devices
> > (AR928X, AR922X) do not seem to implement the hw_tx99_set_txpower function.
> >
> > I could not find any information on how to implement the power control on
> > TX99 for AR9280
> > Are there any patches arou
ted-by if you wish.
Tested-by: Gabriel Craciunescu <nix.or....@gmail.com>
Regards,
Gabriel
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
/ Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ter
(rev 01)
Subsystem: Qualcomm Atheros AR93xx Wireless Network Adapter
Physical Slot: 6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- https://lists.ath9k.org/mailman/listinfo/ath9k-devel
quests.
>
> Yes, I'll try to get it to 4.10-rc2.
>
> --
> Kalle Valo
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
eless/qca,ath9k.txt | 48
> ++
> 1 file changed, 48 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
Acked-by: Rob Herring <r...@kernel.org>
___________
ath9k-devel mail
capability field simply
> cannot be trusted.
> I guess I would be okay with just having a disable property and adding
> an enable property later only if we end up actually needing it.
If EEPROM is commonly wrong or missing, then seems like you want to
plan ahead and support both enable and disable.
The other approach I've mentioned before is just put raw EEPROM data
into DT to override the EEPROM. This would be better if there's a
large number of settings you need.
Rob
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
xample, the node is defined as child node of the PCI controller:
> + {
> + ath9k@168c,002d {
unit address is not the vendor/device ID, but the reg value. So
'@7000,0,0' I think in this case. Double check the OF PCI bus binding.
> + compatible = "pci168c,002d";
&g
o be overlooked.
(I'm not testing using vifs on multiple channels. But even if I was,
I'm not sure if normal operation of wpa_supplicant or hostapd would
be enough to trigger these problems.)
-Tim Shepard
s...@alum.mit.edu
_____
enabled)
>
> for ath9k we default to a) but also allow b): the EEPROM (device
> specific calibration data) contains information about which bands are
> enabled (or not). But some manufacturers are shipping devices for
> example with the 5G band enabled, while the actual hardware doesn't
> support it.
And you can't determine that based on different device IDs? If you can
use vendor/device ID, then you should. If not, then this is fine.
Is it possible to have no EEPROM at all? If so, you might want to just
put the raw EEPROM data into DT rather than a property for every field
(I'm assuming there's more than just what you have properties for now).
Rob
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
-Tim Shepard
s...@alum.mit.edu
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
slowest processors are fast enough to avoid starvation.
If there's no aggregation, a limit of some sort is needed (probably to
prevent malfunction of the hardware/driver, but in any case to limit
excess latency). And this limit will depend on processor speed (and
will need to be autotuned at runtime).
anding this.
Tomorrow (after I get some sleep) I'm planning on taking a look at
what ath9k looks like with this patch of yours applied and see if that
makes it any easier to figure out what to do about the above bug(s) in
my original patch.
-Tim Shepard
renaming txq in ath9k first) or produce
a new patch that is more like Toke's reworking of my patch.
Hmm...
-Tim Shepard
s...@alum.mit.edu
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://l
new ieee80211 txq mechanism.
I think the renaming is worth doing, but I also understand the
renaming can be disruptive to others actively working on ath9k.
It would be nice to have another opinion on this.
-Tim Shepard
s...@alum.mit.edu
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
t want find hidden
> changes like this, even more so when the patch is going to a 4.7-rc
> release.
>
> Sudip, could you also test patch 9151847, please? You can download the
> patch from the patchwork link above.
This is also ok. Please add my
Tested-by: Sudip Mukherjee <sudip.mukher...@codethink.co.uk>
and maybe a Reported-by tag is also appropriate in this case.
Regards
Sudip
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ex WLM200NX have inverted LED polarity
(active high instead of active low).
The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.
Cc: <linux-wirel...@vger.kernel.org>
Cc: <ath9k-de...@qca.qualcomm.com>
Cc: <ath9k-devel@lists.ath9k.org>
Cc: &
getting useful stuff from the chanctx stuff).
Again, thanks for looking at this patch.
I'm now working on figuring out the right way to fix my bug in
the <= v2 patch where I fail to respect the hwq_max_pending
values on the new transmit path, and I plan to post a v3 patch
when I get that
tx stuff).
-Tim Shepard
s...@alum.mit.edu
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
alum.mit.edu
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ad of active low on some hardware.
Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.
Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.
Cc: <linux-wirel...@vger.kernel.org>
Cc: <ath9k-de...@qca.qualc
ex WLM200NX have inverted LED polarity
(active high instead of active low).
The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.
Cc: <linux-wirel...@vger.kernel.org>
Cc: <ath9k-de...@qca.qualcomm.com>
Cc: <ath9k-devel@lists.ath9k.org>
Cc: &
50_GPIO_MASK0x000F
> #define AR9561_GPIO_MASK0x000F
solves the problem.
Tested-by: Sudip Mukherjee <sudip.mukher...@codethink.co.uk>
Regards
Sudip
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
ule to
find that out.
Regards
Sudip
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
done:
add_hwgenerator_randomness should not be used in this scenario.
>
> Patch set to Rejected.
Ciao
Stephan
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
4a5286a3d ]---
If it is a known problem then great.. else i can debug and see what the
problem is. There are only few patches added for GPIO, so should not be
a problem to find out what is causing the error.
Regards
Sudip
_______
ath9k-devel mailing l
ytes_read));
+ add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
}
kfree(rng_buf);
--
2.7.4
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
((void *)rng_buf, bytes_read,
- ATH9K_RNG_ENTROPY(bytes_read));
+ add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
}
kfree(rng_buf);
--
2.7.4
_______
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
der
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
changed, 78 insertions(+), 78 deletions(-)
--
2.7.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
@
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
Cc: ath9k-de...@qca.qualcomm.com
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wirel...@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: net...@vger.kernel.org
---
drivers/
@
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
Cc: ath9k-de...@qca.qualcomm.com
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wirel...@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: net...@vger.kernel.org
---
drivers/
_fft+0xa8>
I'm debating now about whether we need to dump more of the code in the
oops - both before and after the faulting instruction...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest
1 - 100 of 11692 matches
Mail list logo
