On Mon, 2016-11-28 at 21:07 +0100, Arend Van Spriel wrote:
>
> I was wondering about the meaning of the term "parent_bssid". Given
> your remark it means something else than my guess. I actually meant
> the distance to the AP indicated by this BSS. Our gscan code obtains
> the gscan results from f
On 30-11-2016 9:22, Johannes Berg wrote:
> On Mon, 2016-11-28 at 21:07 +0100, Arend Van Spriel wrote:
>>
>> I was wondering about the meaning of the term "parent_bssid". Given
>> your remark it means something else than my guess. I actually meant
>> the distance to the AP indicated by this BSS. O
From: Mohammed Shafi Shajakhan
With maximum number of vap's configured in a two radio supported
systems of ~256 Mb RAM, doing a continuous wifi down/up and
intermittent traffic streaming from the connected stations results
in failure to allocate contiguous memory for tx buffers. This results
in t
jes.soren...@redhat.com writes:
> From: Jes Sorensen
>
> Hi,
>
> This patch works around the issue with 8192eu and 8723bu devices not
> being able to reconnect. It is still not clear why this fails, and
> looking at rtlwifi it does issue the command for 8192ee and 8723be
> devices.
>
> Until we h
In the file drivers/net/wireless/ath/dfs_pattern_detector.c we can found the
ETSI pattern definition.
In this definition we can found 7 patterns (0 to 6).
The ETSI standard EN 301893 Annex D only specifies 6 patterns. Only the
pattern 1 to 6 defined in the ath dfs pattern match with the ETSI stan
On 11/30/2016 11:19 AM, voncken wrote:
> In the file drivers/net/wireless/ath/dfs_pattern_detector.c we can found the
> ETSI pattern definition.
>
> In this definition we can found 7 patterns (0 to 6).
>
> The ETSI standard EN 301893 Annex D only specifies 6 patterns. Only the
> pattern 1 to 6 de
Use a separate label per error condition in rfkill_init() to make it a
bit cleaner and easier to extend.
Signed-off-by: Michał Kępień
---
net/rfkill/core.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 88
This patch adds a new "global" (i.e. not per-rfkill device) LED trigger,
rfkill-any, which may be useful for laptops with a single "radio LED"
and multiple radio transmitters. The trigger is meant to turn a LED on
whenever there is at least one radio transmitter active and turn it off
otherwise.
Hi Brian,
> > > > *
> > > > @@ -2227,7 +2237,7 @@ static void mwifiex_recreate_adapter(struct
> > > sdio_mmc_card *card)
> > > > * discovered and initializes them from scratch.
> > > > */
> > > >
> > > > - mwifiex_sdio_remove(func);
> > > > + __mwifiex_sdio_remove(f
Hello Matt,
On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
wrote:
> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
[snip]
>
>
>>> +- pwndn-gpio: contains a power down GPIO specifier.
>>> +- reset-gpio: contains a reset GPIO specifier.
>>> +
>>
>> I wonder if we really need a custom
On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
> jes.soren...@redhat.com writes:
>
> > From: Jes Sorensen
> >
> > Hi,
> >
> > This patch works around the issue with 8192eu and 8723bu devices not
> > being able to reconnect. It is still not clear why this fails, and
> > looking at rtlwifi
On 30 November 2016 at 14:11, Javier Martinez Canillas
wrote:
> Hello Matt,
>
> On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
> wrote:
>> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
>
> [snip]
>
>>
>>
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: co
From: Xinming Hu
bus.remove() callback function is called when user removes this module
from kernel space or ejects the card from the slot. The driver handles
these 2 cases differently. Few commands (FUNC_SHUTDOWN etc.) are sent to
the firmware only for module unload case.
The variable 'user_rmm
From: Xinming Hu
Next patch in this series is going to use mwifiex_read_reg() in remove
handlers. The changes here are prerequisites to avoid forward
declarations.
Signed-off-by: Xinming Hu
Signed-off-by: Amitkumar Karwar
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 73 +++---
drivers/n
Luca Coelho writes:
> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
>> jes.soren...@redhat.com writes:
>>
>> > From: Jes Sorensen
>> >
>> > Hi,
>> >
>> > This patch works around the issue with 8192eu and 8723bu devices not
>> > being able to reconnect. It is still not clear why this fai
Jes Sorensen writes:
> Luca Coelho writes:
>> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
>>> jes.soren...@redhat.com writes:
>>>
>>> > From: Jes Sorensen
>>> >
>>> > Hi,
>>> >
>>> > This patch works around the issue with 8192eu and 8723bu devices not
>>> > being able to reconnect.
Kalle Valo writes:
> Jes Sorensen writes:
>
>> Luca Coelho writes:
>>> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
jes.soren...@redhat.com writes:
> From: Jes Sorensen
>
> Hi,
>
> This patch works around the issue with 8192eu and 8723bu devices not
Heh, I had to do something like this for freebsd too for my ath10k
port. So thanks. :)
Suggestion - take a look at where tasklets, completions, locks, etc
are all re-allocated multiple times, once upon initial VAP bringup. I
had to also undo this in FreeBSD, as we don't allow re-init of tasks,
com
On Wed, Nov 30, 2016 at 12:39:11PM +, Amitkumar Karwar wrote:
> > Ugh, yet another band-aid? You might do better to still cancel any
> > pending work, just don't do it synchronously. i.e., do cancel_work()
> > after you've removed the card. It doesn't make sense to do a FW dump on
> > the "new
Hi Amitkumar,
On Wed, Nov 30, 2016 at 08:22:17PM +0530, Amitkumar Karwar wrote:
> @@ -3177,9 +3184,6 @@ static int mwifiex_pcie_init_module(void)
>
> pr_debug("Marvell PCIe Driver\n");
>
> - /* Clear the flag in case user removes the card. */
> - user_rmmod = 0;
> -
> ret =
"Valo, Kalle" writes:
> Bjorn Andersson writes:
>
>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>
>>> Bjorn Andersson wrote:
>>> > The correct include file for getting errno constants and ERR_PTR() is
>>> > linux/err.h, rather than linux/errno.h, so fix the include.
>>> >
>>> > Fixes: e8
These lines were indented one tab extra.
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index f5dffdf..fdc6cc2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvel
From: Kalle Valo
Date: Tue, 29 Nov 2016 16:59:44 +0200
> if there's still time here's one more patch to 3.9. I think this is good
> to have in 3.9 as it fixes an issue where we were printing uninitialised
> memory in mwifiex. I had this in wireless-drivers already for some time
> as I was waiting
mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
framework ([1] 13.13.2 Extensible synchronization framework). It shall
not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
collision avoidance,
Your shipment(s) is scheduled for delivery
Scheduled Delivery Date: 12/02/2016
Shipper: Chambers Group.
Kindly view the attached document for shipment/delivery details and
tracking procedure. You can also request a delivery change (e.g.
reschedule or reroute) from the tracking detail.
Approxima
Kalle Valo writes:
> "Valo, Kalle" writes:
>
>> Bjorn Andersson writes:
>>
>>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>>
Bjorn Andersson wrote:
> The correct include file for getting errno constants and ERR_PTR() is
> linux/err.h, rather than linux/errno.h, so fix the
David Miller writes:
> From: Kalle Valo
> Date: Tue, 29 Nov 2016 16:59:44 +0200
>
>> if there's still time here's one more patch to 3.9. I think this is good
>> to have in 3.9 as it fixes an issue where we were printing uninitialised
>> memory in mwifiex. I had this in wireless-drivers already f
On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote:
> Is this something for stable? And if so, how far back should it be applied?
@Kalle,
[shafi] kindly suggest. If i am not wrong this is only needed for 4.9
>
> I'll add this patch to my 4.9 tree and test it...
>
[shafi] thanks a lot
Hi Adrian,
On Wed, Nov 30, 2016 at 10:27:25AM -0800, Adrian Chadd wrote:
> Heh, I had to do something like this for freebsd too for my ath10k
> port. So thanks. :)
[shafi] thanks :):)
>
> Suggestion - take a look at where tasklets, completions, locks, etc
> are all re-allocated multiple times,
Hi,
On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> When we try to transmit traffic (ping) between two meshed ath10k
> devices running latest lede we keep experiencing ath10k firmware
> crashes. This seems to only happen when running in 802.11n/ac mode
> but not in 802.11a/g mod
30 matches
Mail list logo