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
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
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
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? :)
>
W
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
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
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/bea
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
pat
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
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[
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_mi
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
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
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
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..
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 multipl
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 multipl
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
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 typ
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 b
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 t
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
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'
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,
>
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
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 pr
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
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
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 w
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-si
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 bo
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.h
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
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
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
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
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.
>
Ri
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 th
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-
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
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 prevent
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))
>> +
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 ie
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: s
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
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 alr
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;
> +
> + /*
> + *
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
> 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 fi
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 o
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
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_
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/s
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 10
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/wilc100
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/driver
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 ke
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 I2
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
59 matches
Mail list logo
