Kalle Valo wrote:
> ath9k-devel list is now closed, only linux-wireless should be used.
>
> Reported-by: Michael Renzmann
> Signed-off-by: Kalle Valo
Patch applied to wireless-drivers.git, thanks.
2b1d530cb315 MAINTAINERS: ath9k-devel is closed
--
https://patchwork.kernel.org/patch/9541737/
Larry Finger wrote:
> From: Michael Schenk
>
> In the function rtl_usb_start we pre-allocate a certain number of urbs
> for RX path but they will not be freed when calling rtl_usb_stop. This
> results in leaking urbs when doing ifconfig up and down. Eventually,
> the system has no available urbs
Guy Mishol wrote:
> fix an issue where we printed the sdio buffer before
> actually read it.
>
> Signed-off-by: Guy Mishol
Patch applied to wireless-drivers-next.git, thanks.
64ad08605e84 wlcore: print the sdio buffer after reading it
--
https://patchwork.kernel.org/patch/9539423/
Documenta
Amitkumar Karwar wrote:
> Sleep confirm is a special command for which "adapter->cur_cmd" pointer
> is not set. When it's response is received, host writes SLEEP confirm done
> to a register. Firmware will perform DMA for writing sleep cookie signature
> on same buffer after this.
>
> Let's not i
Stanislaw Gruszka wrote:
> Since clk_get() is not trivial add copy of clk pointer to rt2x00dev
> for System On Chip devices and initialize it on probe routine.
>
> Signed-off-by: Stanislaw Gruszka
> Acked-by: Daniel Golle
3 patches applied to wireless-drivers-next.git, thanks.
34db70b92fae rt
Larry Finger writes:
> From: Ping-Ke Shih
>
> btcoex needs to sleep, thus it must run in thread context.
>
> Signed-off-by: Ping-Ke Shih
> Signed-off-by: Larry Finger
[...]
> +void rtl_c2hcmd_launcher(struct ieee80211_hw *hw, int exec)
> +{
> + struct rtl_priv *rtlpriv = rtl_priv(hw);
>
Larry Finger writes:
> This routine uses its own debugging macros These are changed to use the
> the recently rewritten RT_TRACE macro. There are also some renamed
> variables that were missed in the previous step.
>
> The only functional change is that some debugging statements have been
> dropp
Lior David writes:
> On 1/19/2017 3:14 PM, Arend Van Spriel wrote:
>> On 19-1-2017 13:36, Lior David wrote:
>>> On 1/19/2017 2:24 PM, Valo, Kalle wrote:
Maya Erez writes:
> From: Lior David
>
> In fine timing measurements, the calculation is affected by
> 2 parts: timi
Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> It was left after reworking PCIe reset in commit 07fe2e38c7fd
> ("brcmfmac: Reset PCIE devices after recognition.").
>
> Cc: Hante Meuleman
> Signed-off-by: Rafał Miłecki
> Acked-by: Arend van Spriel
Patch applied to wireless-drivers-next.git, t
Currently mesh moving fail average is calculated based on constant
weight factor. In worst case moving average reaches threshold by
considering 16 msdu tx ack status and deactivates mesh path. Having
a constant weight factor might not be suitable for all environments.
So make it tunable parameter a
Mesh moving average should be cleared, whenever mesh paths
to the given station are deactivated due to bad link. This will
give enough room to analysis more tx status than retaining the
current average.
Signed-off-by: Rajkumar Manoharan
---
net/mac80211/mesh_pathtbl.c | 4
1 file changed, 4
As moving average is not considering fractional part after
certain ratio, it will stuck at the same state. For example
with current values, moving average stuck at 96 and it will
not move forward. Fortunately current threshold is matching
against 95%. If thresold is increased more than 96, mesh pat
On Fri, 2017-01-27 at 22:00 +0100, Johannes Berg wrote:
> On Fri, 2017-01-27 at 22:26 +0300, Pichugin Dmitry wrote:
> > This fixes the checkpatch.pl warnings:
> > * Macros should not use a trailing semicolon.
> > * Spaces required around that '='.
> > * Symbolic permissions 'S_IRUGO' are not prefer
On Fri, 2017-01-27 at 22:26 +0300, Pichugin Dmitry wrote:
> This fixes the checkpatch.pl warnings:
> * Macros should not use a trailing semicolon.
> * Spaces required around that '='.
> * Symbolic permissions 'S_IRUGO' are not preferred.
> * Macro argument reuse 'buflen' - possible side-effects
I
On 27-1-2017 8:33, Kalle Valo wrote:
> Pali Rohár writes:
>
>> NVS calibration data for wl1251 are model specific. Every one device with
>> wl1251 chip has different and calibrated in factory.
>>
>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>> in that case there
Jens Axboe writes:
> On 01/21/2017 05:59 AM, Kalle Valo wrote:
>> Jens Axboe wrote:
>>> A recent firmware change seems to have enabled thermal zones on the
>>> iwlwifi driver. Unfortunately, my device fails when registering the
>>> thermal zone. This doesn't stop the driver from attempting to un
On 01/27/2017 12:54 PM, Kalle Valo wrote:
> Jens Axboe writes:
>
>> On 01/21/2017 05:59 AM, Kalle Valo wrote:
>>> Jens Axboe wrote:
A recent firmware change seems to have enabled thermal zones on the
iwlwifi driver. Unfortunately, my device fails when registering the
thermal zone.
On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> Pali Rohár writes:
>
> > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> >> Pali Rohár writes:
> >>
> >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> >> > for SSH connection. If real correct data are not avai
On Fri, 2017-01-27 at 22:26 +0300, Pichugin Dmitry wrote:
> This fixes the checkpatch.pl warnings:
> * Macros should not use a trailing semicolon.
> * Spaces required around that '='.
> * Symbolic permissions 'S_IRUGO' are not preferred.
OK
> * Macro argument reuse 'buflen' - possible side-effect
On 01/21/2017 05:59 AM, Kalle Valo wrote:
> Jens Axboe wrote:
>> A recent firmware change seems to have enabled thermal zones on the
>> iwlwifi driver. Unfortunately, my device fails when registering the
>> thermal zone. This doesn't stop the driver from attempting to unregister
>> the thermal zon
This fixes the checkpatch.pl warnings:
* Macros should not use a trailing semicolon.
* Spaces required around that '='.
* Symbolic permissions 'S_IRUGO' are not preferred.
* Macro argument reuse 'buflen' - possible side-effects
Signed-off-by: Pichugin Dmitry
---
net/wireless/debugfs.c | 15 +
Waldemar Rymarkiewicz wrote:
> Board Data File (BDF) is loaded upon driver boot-up procedure. The right
> board data file is identified, among others, by device and sybsystem ids.
>
> The problem, however, can occur when the (default) board data file cannot
> fulfill with the vendor requirements
Srinivas Kandagatla wrote:
> DIAG_TRANSFER_LIMIT is redefined with same value and comments
> just below this entry, remove this duplicate entry.
>
> Signed-off-by: Srinivas Kandagatla
3 patches applied to ath-next branch of ath.git, thanks.
dd51fa3d8a1d ath10k: remove multiple defines of DIAG_
Maya Erez wrote:
> From: Dedy Lansky
>
> By default, AP SME is handled by driver/FW.
> In case disable_ap_sme is true, driver doesn't turn-on
> WIPHY_FLAG_HAVE_AP_SME and the responsibility for
> AP SME is passed to user space.
>
> With AP SME disabled, driver reports assoc request frame
> to u
On Friday 27 January 2017 17:23:07 Kalle Valo wrote:
> Pali Rohár writes:
>
> > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> >> Pali Rohár writes:
> >>
> >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> >> > for SSH connection. If real correct data are n
Pali Rohár writes:
> On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
>> Pali Rohár writes:
>>
>> > 2) It was already tested that example NVS data can be used for N900 e.g.
>> > for SSH connection. If real correct data are not available it is better
>> > to use at least those example (and p
As reported by Felix:
Though protected by an ifdef, introducing an usb symbol dependency in
the rt2x00lib module is a major inconvenience for distributions that
package kernel modules split into individual packages.
Get rid of this unnecessary dependency by calling the usb related
function from a
From: Tamizh chelvam
Rx filter reset and the dynamic tx switch mode (EXT_RESOURCE_CFG)
configuration are causing the following errors when UTF firmware
is loaded to the target.
Error message 1:
[ 598.015629] ath10k_pci 0001:01:00.0: failed to ping firmware: -110
[ 598.020828] ath10k_pci 0001:01:
On Friday 27 January 2017 13:53:28 Arend Van Spriel wrote:
> On 27-1-2017 13:26, Kalle Valo wrote:
> > Pali Rohár writes:
> >
> >> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >>> Pali Rohár writes:
> >>>
> > So
> > for those other platforms there will be a delay waiting for us
On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> Pali Rohár writes:
>
> > On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >> Pali Rohár writes:
> >>
> >> >> So
> >> >> for those other platforms there will be a delay waiting for user-mode
> >> >> helper to fail, before trying to get
On 2017-01-25 17:36, Felix Fietkau wrote:
> The code currently relies on refcounting to disable IRQs from within the
> IRQ handler and re-enabling them again after the tasklet has run.
>
> However, due to race conditions sometimes the IRQ handler might be
> called twice, or the tasklet may not run
On Thu, Jan 26, 2017 at 10:49:05PM +, Hassell, William wrote:
> Hoping you can help.
> I installed SUSE SLES 12 SP1 on a Sony Vaio laptop.
> To my surprise, everything is working with the exception of the wireless
> device.
> It is an Intel WIFI 4965 AGN device and it works fine with Windows
On Fri, 2017-01-27 at 12:09 +, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as
On 27-1-2017 13:26, Kalle Valo wrote:
> Pali Rohár writes:
>
>> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>>> Pali Rohár writes:
>>>
> So
> for those other platforms there will be a delay waiting for user-mode
> helper to fail, before trying to get nvs file from /lib/firmw
Johannes Berg writes:
> And to make it show up in patchwork at the right place:
>
> Kalle, you can ignore patch 1, I'm handling it, but you need to apply
> these before I can, the patch series order was wrong.
Haha :) Thank you, this is the best way to remind me about something.
--
Kalle Valo
On 27-1-2017 13:09, Arend van Spriel wrote:
> The wowlan support is (partially) determined dynamic by checking the
> device/firmware capabilities. So they can differ per device. So it
> is not possible to use a static global. Instead use the global as a
> template and use kmemdup(). When kmemdup()
On Fri, 2017-01-27 at 13:38 +0100, Arend Van Spriel wrote:
>
> > IOW, I think Kalle can merge 2-5, and I can then pick up this one
> > when they hit net-next and I've synchronized, no?
>
> Agree.
Alright. I see you submitted another version, I'll assign 2-5 to Kalle,
and keep 1 for myself, and n
And to make it show up in patchwork at the right place:
Kalle, you can ignore patch 1, I'm handling it, but you need to apply
these before I can, the patch series order was wrong.
johannes
On 2017-01-27 13:10, Stanislaw Gruszka wrote:
> Hi
>
> On Fri, Jan 27, 2017 at 09:34:26AM +0100, Felix Fietkau wrote:
>> Though protected by an ifdef, introducing an usb symbol dependency in
>> the rt2x00lib module is a major inconvenience for distributions that
>> package kernel modules split int
On 27-1-2017 13:31, Johannes Berg wrote:
> On Fri, 2017-01-27 at 12:09 +, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_mat
Hi
On Fri, Jan 27, 2017 at 09:34:26AM +0100, Felix Fietkau wrote:
> Though protected by an ifdef, introducing an usb symbol dependency in
> the rt2x00lib module is a major inconvenience for distributions that
> package kernel modules split into individual packages.
>
> Get rid of this unnecessary
Kalle Valo writes:
> (dropping ath5k-devel and ath9k-devel, I assume they are closed now)
>
> "Michael Renzmann" writes:
>
>> Kalle Valo wrote:
>>> So feel free to close both of the lists and thanks for the heads up.
>>
>> Ok. I will send a shutdown notice to both lists during the next few days,
Add support for the .update_connect_params() callback for roaming
or subsequent (re)association.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 24 +
This series has a fix for nl80211 regarding validation of wowlan
netdetect. It has been discussed with Johannes to take this through
the wireless-drivers-next repository so here it is.
* fix validation of wowlan netdetect parameters in nl80211.
* fix wowlan netdetect support.
* add new cfg80211 ca
The wowlan support is (partially) determined dynamic by checking the
device/firmware capabilities. So they can differ per device. So it
is not possible to use a static global. Instead use the global as a
template and use kmemdup(). When kmemdup() fails the template is used
unmodified.
Reviewed-by:
For wowlan netdetect a separate limit is defined for the number of
matchsets. Currently, this limit is ignored and the regular limit
for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
used for the net-detect case as well.
Cc: Johannes Berg
Reviewed-by: Hante Meuleman
Reviewed-by:
The driver advertises support for WOWLAN_NETDETECT but did not specify
maximum amount of netdetect match sets. This was no issue due to a bug
in nl80211. As that has been fixed, brcmfmac also needs fixing.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Si
For wowl netdetect the event data changed for newer chips. This
was recently fixed for scheduled scan, but same change is needed
for wowl netdetect. Removing now pointles += operation from both
result handlers.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Li
Pali Rohár writes:
> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>> Pali Rohár writes:
>>
>> >> So
>> >> for those other platforms there will be a delay waiting for user-mode
>> >> helper to fail, before trying to get nvs file from /lib/firmware.
>> >
>> > Yes, there will be. But there
Add support for the .update_connect_params() callback for roaming
or subsequent (re)association.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 24 +
The wowlan support is (partially) determined dynamic by checking the
device/firmware capabilities. So they can differ per device. So it
is not possible to use a static global. Instead use the global as a
template and use kmemdup(). When kmemdup() fails the template is used
unmodified.
Reviewed-by:
ath9k-devel list is now closed, only linux-wireless should be used.
Reported-by: Michael Renzmann
Signed-off-by: Kalle Valo
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9e3d94..d7699d5b5863 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@
For wowlan netdetect a separate limit is defined for the number of
matchsets. Currently, this limit is ignored and the regular limit
for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
used for the net-detect case as well.
Cc: Johannes Berg
Reviewed-by: Hante Meuleman
Reviewed-by:
The driver advertises support for WOWLAN_NETDETECT but did not specify
maximum amount of netdetect match sets. This was no issue due to a bug
in nl80211. As that has been fixed, brcmfmac also needs fixing.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Si
This series has a fix for nl80211 regarding validation of wowlan
netdetect. It has been discussed with Johannes to take this through
the wireless-drivers-next repository so here it is.
* fix validation of wowlan netdetect parameters in nl80211.
* fix wowlan netdetect support.
* add new cfg80211 ca
For wowl netdetect the event data changed for newer chips. This
was recently fixed for scheduled scan, but same change is needed
for wowl netdetect. Removing now pointles += operation from both
result handlers.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Li
(dropping ath5k-devel and ath9k-devel, I assume they are closed now)
"Michael Renzmann" writes:
> Kalle Valo wrote:
>> So feel free to close both of the lists and thanks for the heads up.
>
> Ok. I will send a shutdown notice to both lists during the next few days,
> then unsubscribe all subscri
Hi!
> > You are probably saying that on your platform you can not remove
> > anything from /lib/firmware, right? I don't see how you come from "it is
> > part of firmware package" to "removing is not possible". Trying to
> > understand this and it makes no sense.
>
> It is already in linux distri
On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> Pali Rohár writes:
>
> >> So
> >> for those other platforms there will be a delay waiting for user-mode
> >> helper to fail, before trying to get nvs file from /lib/firmware.
> >
> > Yes, there will be. But there is no easy way to fix this pr
> I actually have two dependent brcmfmac patches. Do you expect
> conflict if Kalle takes all?
Not really, if that's somehow easier we can do that.
johannes
Pali Rohár writes:
>> So
>> for those other platforms there will be a delay waiting for user-mode
>> helper to fail, before trying to get nvs file from /lib/firmware.
>
> Yes, there will be. But there is no easy way to fix this problem that
> kernel is trying to use default/example NVS data...
K
Luca Coelho writes:
> Hi Kalle,
>
> Here's my first pull-request intended for v4.11. It has a bunch of
> fixes, cleanups and improvements here and there, as well as a few new
> features. More details in the tag description.
>
> I have sent this out before and kbuildbot didn't find any issues.
>
On 27-1-2017 12:27, Johannes Berg wrote:
>
>> I actually have two dependent brcmfmac patches. Do you expect
>> conflict if Kalle takes all?
>
> Not really, if that's somehow easier we can do that.
Will do. I checked the other drivers. All those supporting wowl
netdetect did provide max_nd_matchs
On 24-1-2017 12:28, Arend Van Spriel wrote:
> On 24-1-2017 9:57, Johannes Berg wrote:
>> On Thu, 2017-01-19 at 14:08 +0100, Arend Van Spriel wrote:
>>>
>>> On 19-1-2017 13:00, Luca Coelho wrote:
On Thu, 2017-01-19 at 10:01 +, Arend van Spriel wrote:
> For wowlan netdetect a separate
On Friday 27 January 2017 11:19:25 Arend Van Spriel wrote:
> On 27-1-2017 11:10, Pali Rohár wrote:
> > On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> >> On 27-1-2017 10:43, Pali Rohár wrote:
> >>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> Pali Rohár writes:
>
>
On 27-1-2017 11:10, Pali Rohár wrote:
> On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
>> On 27-1-2017 10:43, Pali Rohár wrote:
>>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
Pali Rohár writes:
> NVS calibration data for wl1251 are model specific. Every one devi
On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> On 27-1-2017 10:43, Pali Rohár wrote:
> > On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> >> Pali Rohár writes:
> >>
> >>> NVS calibration data for wl1251 are model specific. Every one device with
> >>> wl1251 chip has different a
On 27-1-2017 10:43, Pali Rohár wrote:
> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
>> Pali Rohár writes:
>>
>>> NVS calibration data for wl1251 are model specific. Every one device with
>>> wl1251 chip has different and calibrated in factory.
>>>
>>> Not all wl1251 chips have own EEPROM
On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
> Pali Rohár writes:
>
> > In case there is no valid MAC address kernel generates random one. This
> > patch propagate this generated MAC address back to NVS data which will be
> > uploaded to wl1251 chip. So HW would have same MAC address as l
On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> Pali Rohár writes:
>
> > NVS calibration data for wl1251 are model specific. Every one device with
> > wl1251 chip has different and calibrated in factory.
> >
> > Not all wl1251 chips have own EEPROM where are calibration data stored. And
>
Pali Rohár writes:
> On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
>> Pali Rohár writes:
>>
>> > In case there is no valid MAC address kernel generates random one. This
>> > patch propagate this generated MAC address back to NVS data which will be
>> > uploaded to wl1251 chip. So HW woul
Though protected by an ifdef, introducing an usb symbol dependency in
the rt2x00lib module is a major inconvenience for distributions that
package kernel modules split into individual packages.
Get rid of this unnecessary dependency by calling the usb related
function from a more suitable place
F
72 matches
Mail list logo
