On Mittwoch, 28. März 2018 11:41:51 CEST ako...@codeaurora.org wrote:
[...]
> The rate average and throughput are relative. no?
In the sense that rate has a tendency to affect the expected throughput - yes.
But it is not like the expected throughput perfectly correlates with the rate
and you onl
On 2018-03-26 12:52, Sven Eckelmann wrote:
On Freitag, 23. März 2018 19:37:14 CEST Anilkumar Kolli wrote:
+static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k_sta *arsta = (struct ath10k_
On 2018-03-27 22:18, Steve deRosier wrote:
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
wrote:
Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a f
On 2018-03-27 18:24, Johannes Berg wrote:
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
+u16 ieee80211_get_noack_map(struct ieee80211_sub_if_data *sdata,
const u8 *mac)
+{
+ struct sta_info *sta;
+ u16 noack_map = 0;
+
+ /* Retrieve per-station noack_ma
On 2018-03-27 18:23, Johannes Berg wrote:
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
+ * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages
noack
+ * policy handling. Hardware (or driver) takes care of setting
+ * noack policy in the qos header
On 2018-03-27 18:17, Johannes Berg wrote:
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
- * @set_noack_map: Set the NoAck Map for the TIDs.
+ * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not
%NULL NoAck
+ * map will be applied for that particular peer. W
Thank you all guys for your work on this issue, and patience.
I think implementing a watchdog is a good idea: and BTW I don't think the
problem verifies so infrequently on a WL-330n3G
device, openwrt .config attached.
And, while on my MR200 MT7620A-based wi-fi card, the device is able to continu
Hi Thomas
I am able to see the correct values after I enable the wifi interface
and with the following changes.
Index: compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/debug.c
===
--- compat-wireless-2015-03-09.orig/drivers/
On 3/27/2018 4:42 PM, Denis Kenzior wrote:
Hi Arend,
On 03/27/2018 03:03 AM, Arend van Spriel wrote:
On 3/26/2018 7:52 PM, Denis Kenzior wrote:
The proposed patchset has been tested in a mac80211_hwsim based
environment with
hostapd and iwd.
Hi Denis,
Looking pretty good. Do you also have h
--
Greeting, once again is me Lucy Boston this is twice am contacting you
please is very urgent respond to me for more details through my.
Email:
dr.lucybos...@gmail.com
GIFT FROM MRS ANAKI BENSON / I and my husband were from Kuwait, my
husband worked with Kuwait embassy here in Ivory Coast for nine years
before he died, he deposited the sum of US $2.5 million dollars in the
bank of africa, my Doctor told me that I would not last for the next
eight months due to ca
These allocations are not freed upon release.
When on it; go for managed resources instead.
Signed-off-by: Marcus Folkesson
---
drivers/net/wireless/ath/ath10k/sdio.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c
Hi Stanislaw,
On Tue, Mar 27, 2018 at 07:18:16PM +0200, Stanislaw Gruszka wrote:
> On Tue, Mar 27, 2018 at 09:46:36AM +0200, Mathias Kresin wrote:
> > > Could you test just RX AMPDU patches, i.e.
> > >
> > > rt2800_change_rx_ampdu_factor.patch
> > > rt2800_change_rx_ampdu_density.patch
> > >
> >
On Tue, Mar 27, 2018 at 09:46:36AM +0200, Mathias Kresin wrote:
> > Could you test just RX AMPDU patches, i.e.
> >
> > rt2800_change_rx_ampdu_factor.patch
> > rt2800_change_rx_ampdu_density.patch
> >
> > I have somewhat positive results on RX performance on some devices
> > with those. Perhaps yo
Hi Peter,
On 2018-03-27 01:51, Peter Oh wrote:
Add QMI client driver for Q6 integrated WLAN connectivity subsystem.
Can you give an example which chipset series is Q6 integrated WLAN ?
Thanks,
Peter
SDM845/MSM8998 series is using the same, where WLAN firmware is running
on Q6 processor.
[please CC me since I'm not subscribed to the lists and terribly sorry
for HTML mails]
Oh hai!
I have Compex WLE1216V2-20 (based on QCA9984 chip) that isn't
supported by linux-firmware (git master), card init fails with
>[Mon Mar 26 17:18:47 2018] ath10k_pci :05:00.0: failed to fetch board d
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
wrote:
> Adds infrastructure for driver to offload NoAck functionality, driver
> like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a fan of adding a feature without some use of
Hi Arend,
On 03/27/2018 03:03 AM, Arend van Spriel wrote:
On 3/26/2018 7:52 PM, Denis Kenzior wrote:
The proposed patchset has been tested in a mac80211_hwsim based
environment with
hostapd and iwd.
Hi Denis,
Looking pretty good. Do you also have hostapd and iwd patches available
somewhere
Hi Kalle/Johannes,
On Tue, Mar 27, 2018 at 7:48 PM, Kalle Valo wrote:
> Johannes Berg writes:
>
>> On Fri, 2018-03-23 at 20:20 +0530, Amitkumar Karwar wrote:
>>
>>> > But maybe that's not really true at all? At least in one case it seems
>>> > you just kick off something called "bgscan".
>>>
>>>
Johannes Berg writes:
> On Fri, 2018-03-23 at 20:20 +0530, Amitkumar Karwar wrote:
>
>> > But maybe that's not really true at all? At least in one case it seems
>> > you just kick off something called "bgscan".
>>
>> Yes. We have different scan implementations for device is connected
>> and non-
Pkshih writes:
> On Tue, 2018-03-27 at 10:32 +0300, Kalle Valo wrote:
>> writes:
>>
>> > From: Ping-Ke Shih
>> >
>> > There are two or three physical antenna in 8822be WiFi modules, so btcoex
>> > introduce two coex files to handle these two cases.
>> >
>> > Signed-off-by: Ping-Ke Shih
>> > -
Izzy Kulbe writes:
> On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
>> Izzy Kulbe writes:
>>
>> > nvm the last message, attached the wrong file using the 9270
>> > instead of the 9260 firmware, which obviously wouldn't work.
>> > Here's the working patch:
>> >
>> >
>> > Add support for
Bandwidth change value reported via nl80211 contains mac80211
specific enum value(ieee80211_sta_rx_bw) and which is not
understand by userspace application. Map the mac80211 specific
value to nl80211_chan_width enum value to avoid using wrong value
in the userspace application. And used station's h
Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 and
userspace/cfg80211 doesn't know about that. This will lead to incorrect
result/assumption
SMPS_MODE change value notified via nl80211 contains mac80211
specific value(ieee80211_smps_mode) and user space application
will not know those values. This patch add support to map
the mac80211 enum value to nl80211_smps_mode which will be
understood by the userspace application.
Signed-off-by:
Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 and
userspace/cfg80211 doesn't know about that. This patchset change its
data type in the sta
On Sat, 2018-03-24 at 16:02 -0700, Quytelda Kahja wrote:
> The "document" refers to the file in which the changes were made
> ('include/linux/ieee80211.h').
You're the first person ever to do that, to my knowledge :)
Either way, I don't really want to merge this since it would break
staging, and
Hi Claudiu,
On Tue, 27 Mar 2018 11:55:52 +0300
Claudiu Beznea wrote:
> On 27.03.2018 10:22, Ajay Singh wrote:
> >
> > Please let me know, in case I have to rework and resubmit this patch
> > series to make them into staging branch.
> >
>
> As I suggested in patch 6, I prefer having the same
On Fri, 2018-03-23 at 20:20 +0530, Amitkumar Karwar wrote:
> > But maybe that's not really true at all? At least in one case it seems
> > you just kick off something called "bgscan".
>
> Yes. We have different scan implementations for device is connected
> and non-connected cases. In connected ca
On Sat, 2018-03-24 at 11:29 +0100, Alexander Wetzel wrote:
> Rekeying a pairwise key with encryption offload and only keyid 0 has two
> potential races which can freeze the wlan conection till rekeyed again:
>
> 1) For incomming packets:
> If the local STA installs the key prior to the remote
On 2018-03-27 18:26, Johannes Berg wrote:
On Tue, 2018-03-27 at 12:18 +0530, Tamizh chelvam wrote:
Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from
ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to
On Tue, 2018-03-27 at 14:48 +0200, Izzy Kulbe wrote:
> On Tue, 2018-03-27 at 15:38 +0300, Luciano Coelho wrote:
> > On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> > > On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > > Wait a bit. This ID looks strange, someone else reported thi
On Mon, 2018-03-26 at 22:24 +0200, Alexander Wetzel wrote:
> There are quite many interesting things visible here, not the least one
> that ath9k leaks unencrypted frames for both patched and unpatched
> mac80211 which at least for my patched variant probably allow to
> calculate the TK key and en
On Tue, 2018-03-27 at 12:18 +0530, Tamizh chelvam wrote:
> Currently bw and smps_mode are u8 type value in sta_opmode_info
> structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
> and ieee80211_smps_mode. These enum values are specific to mac80211 and
> userspace/cfg80211 doesn
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
>
> +u16 ieee80211_get_noack_map(struct ieee80211_sub_if_data *sdata, const u8
> *mac)
> +{
> + struct sta_info *sta;
> + u16 noack_map = 0;
> +
> + /* Retrieve per-station noack_map config for the receiver, if any */
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
>
> + * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages noack
> + * policy handling. Hardware (or driver) takes care of setting
> + * noack policy in the qos header and does not wait for the ack based
> + *
On Tue, 2018-03-27 at 15:38 +0300, Luciano Coelho wrote:
> On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> > On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > Wait a bit. This ID looks strange, someone else reported this
> > already
> > and it looked strange, with an incorrect su
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
>
> - * @set_noack_map: Set the NoAck Map for the TIDs.
> + * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not %NULL
> NoAck
> + * map will be applied for that particular peer. When peer is %NULL NoAck
> + * m
On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> > > Izzy Kulbe writes:
> > >
> > > > nvm the last message, attached the wrong file using the 9270
> > > > instead of the 9260
On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> > Izzy Kulbe writes:
> >
> > > nvm the last message, attached the wrong file using the 9270
> > > instead of the 9260 firmware, which obviously wouldn't work.
> > > Here's the working pat
On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> Izzy Kulbe writes:
>
> > nvm the last message, attached the wrong file using the 9270 instead of the
> > 9260 firmware, which obviously wouldn't work. Here's the working patch:
> >
> >
> > Add support for Rivet Networks Killer Wireless-AC
Izzy Kulbe writes:
> nvm the last message, attached the wrong file using the 9270 instead of the
> 9260 firmware, which obviously wouldn't work. Here's the working patch:
>
>
> Add support for Rivet Networks Killer Wireless-AC 1550 chipset,
> which is using the Intel Wireless-AC 9260 chip
>
> S
nvm the last message, attached the wrong file using the 9270 instead of the
9260 firmware, which obviously wouldn't work. Here's the working patch:
Add support for Rivet Networks Killer Wireless-AC 1550 chipset,
which is using the Intel Wireless-AC 9260 chip
Signed-off-by: Izzy Kulbe
---
dr
Add support for Rivet Networks Killer Wireless-AC 1550 chipset,
which is using the Intel Wireless-AC 9260 chip
Signed-off-by: Izzy Kulbe
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
b/driver
On Tue, 2018-03-27 at 10:32 +0300, Kalle Valo wrote:
> writes:
>
> > From: Ping-Ke Shih
> >
> > There are two or three physical antenna in 8822be WiFi modules, so btcoex
> > introduce two coex files to handle these two cases.
> >
> > Signed-off-by: Ping-Ke Shih
> > ---
> > .../realtek/rtlwifi/
Lorenzo Bianconi wrote:
> Fall back to software encryption for hw unsupported ciphers in order
> to fix the following warning in ieee80211_get_key_rx_seq routine:
>
> WARNING: CPU: 1 PID: 1277 at backports-2017-11-01/net/mac80211/key.c:
> 1010 mt76_wcid_key_setup+0x6c/0x138 [mt76]
> CPU: 1 PID:
Lorenzo Bianconi wrote:
> Fix a theoretical NULL pointer dereferencing in mt76x2_tx routine that
> can occurs for injected frames in a monitor vif since vif pointer could
> be NULL for that interfaces
>
> Fixes: 23405236460b ("mt76: fix transmission of encrypted mgmt frames")
> Signed-off-by: Lo
Lorenzo Bianconi wrote:
> Use mt76_poll_msec() in mt76pci_load_firmware to check if the firmware
> has been started instead of explicitly poll MCU running register
>
> Signed-off-by: Lorenzo Bianconi
Patch applied to wireless-drivers-next.git, thanks.
db2ad7c25a9a mt76: use mt76_poll_msec rou
Takashi Iwai wrote:
> The brcms_ucode_init_buf() duplicates the ucode chunks via kmemdup()
> with GFP_ATOMIC as a precondition of wl->lock acquired. This caused
> allocation failures sometimes as reported in the bugzilla below.
>
> When looking at the the real usage, one can find that it's call
Arend Van Spriel wrote:
> In case of a linux error brcmf_fil_cmd_data() blurts an error message
> in which the error code is translated to an error string. However, it
> maps it to a firmware error string which should not happen. Simply
> print only the numeric error code and be done with it.
>
Colin Ian King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in RT_TRACE message text.
>
> Signed-off-by: Colin Ian King
> Acked-by: Larry Finger "Absolute"
--
https://patchwork.kernel.org/patch/10292111/
https://wireless.wiki.kernel.org/en/developers/documentation/sub
Kevin Lo wrote:
> Correct comment. Set bit 3 and bit 4 of 0x0005 register (REG_APS_FSMCO + 1)
> to 0 which means disable WL suspend, not enable WL suspend.
>
> Signed-off-by: Kevin Lo
> Acked-by: Ping-Ke Shih
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/pwrseq.h
> b/drive
Ping-Ke Shih wrote:
> From: Ping-Ke Shih
>
> sparse reports some functions were not declared, so add 'static' as
> modifier. Remove an unused function btc8821a1ant_is_wifi_status_changed()
> exposed due to 'static'.
>
> Signed-off-by: Ping-Ke Shih
> Acked-by: Larry Finger
11 patches applied
On 27.03.2018 10:22, Ajay Singh wrote:
>
> Please let me know, in case I have to rework and resubmit this patch
> series to make them into staging branch.
>
As I suggested in patch 6, I prefer having the same format for
wilc_wfi_cfg_tx_vendor_spec() and wilc_wfi_cfg_parse_rx_vendor_spec(). I
t
Amitkumar Karwar wrote:
> From: Amitkumar Karwar
>
> We miss to release IRQ in certain error path in SDIO probe which
> causes following kernel panic. This patch corrects error path
> handling
>
> BUG: unable to handle kernel NULL pointer dereference at(null)
> IP: (null)
> P
Colin Ian King wrote:
> From: Colin Ian King
>
> Variable buffer_size is re-assigned the same value, this duplicated
> assignment is redundant and can be removed.
>
> Cleans up clang warning:
> drivers/net/wireless/rsi/rsi_91x_usb.c:140:4: warning: Value stored
> to 'buffer_size' is never read
Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
NoAck policy to per-station, with sta level NoAck policy configuration
userspace could selectively turn off/on Noack based on various connection
parameters of t
This enables per-peer NoAck handling in mac80211 when
the functionality is not offloaded to the drivers.
Signed-off-by: Vasanthakumar Thiagarajan
---
net/mac80211/main.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 78f2574..2b136fb 10064
Provides peer level NoAck policy configuration by extending
NL80211_CMD_SET_NOACK_MAP command with peer MAC address.
If user space does not give any peer mac address, the driver
should retain the existing functionality of applying the NoAck
policy for all the staions connected to the netdev. Peer s
On 26.03.2018 20:16, Colin King wrote:
> From: Colin Ian King
>
> Replace several allocation and memcpys with kmemdup and add in some
> missing memory allocation failure checks. Also fix an incorrect
> -EFAULT return with -ENOMEM.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/w
Use per-peer noack tid bitmap, if it is configured,
when setting up the qos header. If no per-peer configuration
is set, use the existing nedev wide noack policy configuration.
Also modifies callback set_noack_tid_bitmap() with the provision
to send per-peer NoAck policy configuration to the driver
Add infrastructure for drivers to implement NoAck policy functionlity.
Driver like ath10k does not use the per-packet TID NoAck policy
configuration. Instead NoAck map is sent to the firmware/hardware
in control path. Firmware takes care of setting up QOS header and
hw with NoAck policy based on t
"Tobin C. Harding" wrote:
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> (kernel Oops) or a security flaw (overwriting memory beyond the
> stack). Also, in general, as code evolves it is easy to lose
Ganapathi Bhat wrote:
> Fix the following sparse warning in mwifiex_cmd_append_11n_tlv:
>
> drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid
> assignment: &=
> drivers/net/wireless/marvell/mwifiex/11n.c:358:65:left side has type
> restricted __le16
> drivers/net/wireless
On 3/26/2018 7:52 PM, Denis Kenzior wrote:
The proposed patchset has been tested in a mac80211_hwsim based environment with
hostapd and iwd.
Hi Denis,
Looking pretty good. Do you also have hostapd and iwd patches available
somewhere. I would like to see if I can get brcmfmac using it.
Regar
Joe Perches wrote:
> Prefer the direct use of octal for permissions.
>
> Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
> and some typing.
>
> Miscellanea:
>
> o Whitespace neatening around these conversions.
>
> Signed-off-by: Joe Perches
Patch applied to wireless-drivers-nex
26.03.2018 12:35, Stanislaw Gruszka:
Hi Mathias
sorry for the delayed testing. I had to create a new test setup
first, fought with buggy hardware and was busy with other stuff.
Thanks for doing it.
The two attached patches are causing a performance regression for me again:
OpenWrt head (fo
writes:
> From: Ping-Ke Shih
>
> There are two or three physical antenna in 8822be WiFi modules, so btcoex
> introduce two coex files to handle these two cases.
>
> Signed-off-by: Ping-Ke Shih
> ---
> .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5327 +++
> .../realtek/
Please let me know, in case I have to rework and resubmit this patch
series to make them into staging branch.
Regards,
Ajay
Arnd Bergmann wrote:
> The linkage between the bluetooth driver and the wireless
> driver is not defined properly, leading to build problems
> such as:
>
> warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies
> (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)
70 matches
Mail list logo
