Stanislaw et al,
Thanks for working on this, I have a small stack of different devices
covered by this driver which I'm excited to test with.
I'm running wireless-testing which may or may not be fully up to date
on the patches you have sent (head is at
c9cd161770dd1866207b70d41ec03c9a26eea94f
Once a txq is selected for transmission by next_txq(), all data from
txq are dequeued by driver till hardware descriptors are drained.
i.e the driver is still allowed to dequeue frames from txq even when
its fairness deficit goes negative during transmission. This breaks
fairness and also cause
txqs of all access categories are maintained in single list
and in uneven order. To fetch a specific AC's txq from the list,
lookup might have to traverse the entire list in worst case.
To speedup txq lookup, txq list are maintained per each AC.
Signed-off-by: Rajkumar Manoharan
---
On 2018-08-28 03:20, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan writes:
Ah, excellent; then it should be no problem to enforce the head node
access; worst case the pull mechanism will be at a different point in
the round-robin, which will sync up quickly.
Will fix it and rename as
>
> On Tue, 2018-08-28 at 23:07 +0200, Lorenzo Bianconi wrote:
> > Do not try to aggregate packets in a A-MSDU frame if max_tx_fragments
> > or max_amsdu_subframes is set to 1.
>
> Yeah that seems valid.
>
> > Moreover take into account
> > tail padding added on the first frame into flow backlog
On Tue, 2018-08-28 at 23:07 +0200, Lorenzo Bianconi wrote:
> Do not try to aggregate packets in a A-MSDU frame if max_tx_fragments
> or max_amsdu_subframes is set to 1.
Yeah that seems valid.
> Moreover take into account
> tail padding added on the first frame into flow backlog if
>
Do not try to aggregate packets in a A-MSDU frame if max_tx_fragments
or max_amsdu_subframes is set to 1. Moreover take into account
tail padding added on the first frame into flow backlog if
ieee80211_amsdu_realloc_pad routine on the second frame fails.
This patch fixes a kernel freeze that
Am 28.08.18 um 18:03 schrieb Johannes Berg:
> On Tue, 2018-08-28 at 18:00 +0200, Alexander Wetzel wrote:
>
>>> If you have a flag here, why say "userspace must not" rather than just
>>> outright prevent userspace from doing it?
>>
>> The userspace must not but currently of course is doing exactly
Am 28.08.18 um 10:48 schrieb Johannes Berg:
> On Tue, 2018-08-14 at 12:42 +0200, Alexander Wetzel wrote:
>>
>> +/* PTK only using key ID 0 needs special handling on rekey */
>> +if (new_key && sta && ptk0rekey) {
>> +local = old_key->local;
>> +sdata =
Am 28.08.18 um 10:47 schrieb Johannes Berg:
> On Tue, 2018-08-14 at 12:42 +0200, Alexander Wetzel wrote:
>> Drivers able to correctly replace a in-use key should set
>> NL80211_EXT_FEATURE_ATOMIC_KEY_REPLACE to allow the userspace (e.g.
>> hostapd or wpa_supplicant) to rekey PTK keys.
>>
>> The
Hi Stanislaw,
I had considerable difficulty getting the module compiled and
installed. I had ignored your first patch, and only applied the second
patch (that you said compiles), but it turns out to be missing the
variable declarations portion of the first patch. After taking that
portion of the
On Tue, 2018-08-28 at 18:00 +0200, Alexander Wetzel wrote:
> > If you have a flag here, why say "userspace must not" rather than just
> > outright prevent userspace from doing it?
>
> The userspace must not but currently of course is doing exactly that.
> Enforcing the new requirement would
Am 28.08.18 um 10:46 schrieb Johannes Berg:
> On Sat, 2018-08-18 at 22:53 +0200, Alexander Wetzel wrote:
>
>>> This looks good to me from a userspace perspective. I will try to
>>> implement support for this in iwd soon to give you a prototype to play
>>> with.
>>
>> Sounds promising, thank
Maya Erez wrote:
> Reset file is not used and may cause race conditions
> with operational driver if used.
>
> Signed-off-by: Karthick Gopalasubramanian
> Signed-off-by: Maya Erez
> Signed-off-by: Kalle Valo
9 patches applied to ath-next branch of ath.git, thanks.
32dcfe8316cd wil6210:
Felix Fietkau wrote:
> Tx99 is typically configured via a monitor mode interface, which does
> not get added to the driver as a vif. Since the code currently expects
> a configured virtual interface for tx99, enabling tx99 via debugfs fails.
> Since the vif is not needed anyway, remove all
On 2018-08-28 17:25, Johannes Berg wrote:
On Tue, 2018-08-28 at 17:22 +0530, murug...@codeaurora.org wrote:
Hi Johannes,
> Hmm. The subject/patch title isn't very clear - does it *implement* this
> requirement? Or do something else with it? Please clarify.
>
Yes, this patch implements the
The current mac80211 WDS (4-address mode) can be used to cover most of the
Multi-AP requirements for Data frames per the WFA Multi-AP Specification v1.0.
When configuring AP/STA interfaces in 4-address mode, they are able to function
as fronthaul AP/backhaul STA of Multi-AP device complying below
From: Sara Sharon
Rename functions.
Remove redundant assignments.
Add some comments
Signed-off-by: Sara Sharon
Signed-off-by: Johannes Berg
---
net/wireless/scan.c | 145 +++-
1 file changed, 75 insertions(+), 70 deletions(-)
diff --git
Hi,
I'm sending this out mostly as another hand-off/publishing, we don't
really think the patches are ready to be used in this form.
However, we did find a few issues in the original code, and the patches
address some of them.
If I remember correctly, we continued to have some list corruption
From: Sara Sharon
Turn on the multi-BSSID bit for supporting drivers.
Signed-off-by: Sara Sharon
Signed-off-by: Johannes Berg
---
include/linux/ieee80211.h | 5 +
include/net/mac80211.h| 3 +++
net/mac80211/debugfs.c| 1 +
net/mac80211/main.c | 4
4 files changed, 13
From: Sara Sharon
When holding data of the non-transmitting BSS, we need to keep
the transmitting BSS data on.
Otherwise it will be released, and release the non-transmitting
BSS with it.
Signed-off-by: Sara Sharon
Signed-off-by: Johannes Berg
---
net/wireless/core.h | 9 +
From: Sara Sharon
Mac80211 needs this info.
Signed-off-by: Sara Sharon
Signed-off-by: Johannes Berg
---
include/net/cfg80211.h | 2 ++
net/wireless/core.h| 10 +++
net/wireless/scan.c| 80 --
3 files changed, 45 insertions(+), 47
From: Sara Sharon
Signed-off-by: Sara Sharon
Signed-off-by: Johannes Berg
---
net/wireless/scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 75e1fc79a890..c08b39a622b7 100644
--- a/net/wireless/scan.c
+++
From: Peng Xu
This extends cfg80211 BSS table processing to be able to parse Multiple
BSSID element from Beacon and Probe Response frames and to update the
BSS profiles in internal database for non-transmitted BSSs.
Signed-off-by: Peng Xu
Signed-off-by: Jouni Malinen
Signed-off-by: Sara
On Tue, 2018-08-28 at 17:22 +0530, murug...@codeaurora.org wrote:
> Hi Johannes,
>
> > Hmm. The subject/patch title isn't very clear - does it *implement* this
> > requirement? Or do something else with it? Please clarify.
> >
>
> Yes, this patch implements the missing Rx requirement (ii) for
On 2018-08-28 11:58, Johannes Berg wrote:
>> ---
>> net/mac80211/rx.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
>> index a16ba568e2a3..686e5586e1f4 100644
>> --- a/net/mac80211/rx.c
>> +++ b/net/mac80211/rx.c
>> @@ -2313,7
Hi Johannes,
> Hmm. The subject/patch title isn't very clear - does it *implement* this
> requirement? Or do something else with it? Please clarify.
>
Yes, this patch implements the missing Rx requirement (ii) for backhaul STA
below.
..
> > Receiver requirements
> > -
> >
Viestintävirasto 15 AM/2018 M
Section 10 Non-specific short range devices
https://www.finlex.fi/data/normit/32670/Regulation_15AM.pdf
diff --git a/db.txt b/db.txt
index 8cf7dee..7abb064 100644
--- a/db.txt
+++ b/db.txt
@@ -460,6 +460,8 @@ country FI: DFS-ETSI
(5150 - 5250 @ 80), (23),
Rajkumar Manoharan writes:
>>> As mentioned earlier, next_txq() can not be used for fetching txq
>>> directly. So reorder_txq() needs to take care of refilling txq after
>>> serving them.
>>
>> Yeah, I got that; but see above. Unless there's a guarantee that the
>> push/pull mechanism will be
Hmm. The subject/patch title isn't very clear - does it *implement* this
requirement? Or do something else with it? Please clarify.
On Thu, 2018-08-16 at 18:17 +0530, Sathishkumar Muruganandam wrote:
> The current mac80211 WDS (4-address mode) can be used to cover most of the
> Multi-AP
On Mon, 2018-08-13 at 15:33 +0300, Alexei Avshalom Lazar wrote:
>
> /**
> + * struct ieee80211_sta_edmg_cap - EDMG capabilities
> + *
> + * This structure describes most essential parameters needed
> + * to describe 802.11ay EDMG capabilities
> + *
> + * @supported: is EDMG supported, Device may
On Mon, 2018-08-13 at 15:33 +0300, Alexei Avshalom Lazar wrote:
> The current support in the 60GHz band is for channels 1-4.
> Add support for channels 5 and 6.
> This requires enlarging ieee80211_channel.center_freq from u16 to u32.
Applied.
johannes
On Tue, 2018-07-10 at 14:16 -0500, Denis Kenzior wrote:
> > I'm not sure I see much point, since we'll have to deal with older wpa_s
> > basically forever?
>
> Do we though? I can understand not breaking userspace APIs, but it
> seems like this API had only a single user (up until recently)
On Wed, 2018-07-11 at 12:24 +0530, Tamizh chelvam wrote:
>
> > Again though - see above. I'm not sure it's even correct to link it to
> > the BSSID since until now, I think the configuration would remain
> > across
> > roaming?
> >
>
> As mentioned above storing configuration parameters in
On Wed, 2018-07-11 at 12:34 +0530, Tamizh chelvam wrote:
> I believe superset you meant will accept a signle threshold
> configuration also from user ?
Yes.
> If so, we can remove the single threshold api implementation.
I think here we can remove the single threshold API - we have it in the
Hi,
Sorry for the late reply, my work hours are limited right now.
> I wanted to give a try with rhashtable and get your thoughts, since it
> gave below flexibility to original patch,
> 1. avoids creating static memory when userspace starts accumulating
> stats. 36 rate entries were used in
On Tue, 2018-08-14 at 12:42 +0200, Alexander Wetzel wrote:
>
> + /* PTK only using key ID 0 needs special handling on rekey */
> + if (new_key && sta && ptk0rekey) {
> + local = old_key->local;
> + sdata = old_key->sdata;
> +
> + /* Stop TX till we are
On Tue, 2018-08-14 at 12:42 +0200, Alexander Wetzel wrote:
> Drivers able to correctly replace a in-use key should set
> NL80211_EXT_FEATURE_ATOMIC_KEY_REPLACE to allow the userspace (e.g.
> hostapd or wpa_supplicant) to rekey PTK keys.
>
> The userspace must detect a PTK rekey attempt and only
On Sat, 2018-08-18 at 22:53 +0200, Alexander Wetzel wrote:
> > This looks good to me from a userspace perspective. I will try to
> > implement support for this in iwd soon to give you a prototype to play
> > with.
>
> Sounds promising, thank you!
>
> I'm still unsure if we really need the API
On Wed, 2018-08-22 at 13:58 +0200, Stanislaw Gruszka wrote:
> On Wed, Aug 22, 2018 at 01:54:27PM +0200, Johannes Berg wrote:
> > On Wed, 2018-08-22 at 13:52 +0200, Stanislaw Gruszka wrote:
> > > Make wmm_rule be part of reg_rule structure. This simplify code
> > > a lot at cost of having bigger
On Wed, 2018-08-22 at 11:22 -0700, Pradeep Kumar Chitrapu wrote:
> > Should we just ignore that? Or perhaps add a separate capability for
> > it?
>
> Yes, even we behave the same. In that case, we can go ahead now with the
> capability to only enable FTM responder. If the driver wants to
On Tue, Aug 21, 2018 at 2:29 AM Luca Coelho wrote:
>
> Hi,
>
> On Sun, 2018-07-29 at 22:59 -0400, R. Alejandro Oquendo Muñoz wrote:
> > Hi,
> > Are there any plans to officially support "Killer/Wireless-AC 9260
> > wireless cards" in Linux 4.19?
> > For now this card works using this patch [1] in
42 matches
Mail list logo
