On 10/28/2017 01:57 AM, James Cameron wrote:
[snip]
Your dmesg shows the mouse is discovered, then disconnects, then
reconnects. I can't tell if your mouse normally does this. Can you
also test for the wireless problem without the USB mouse, or with a
different mouse?
a new dmesg below with a
On 27-10-17 22:10, Johannes Berg wrote:
Hi,
IIUC, mwifiex hasn't told the firmware to do anything at this point --
the -EALREADY check is practically the first thing it does within
connect(). So it just quits the connect() request and tries to carry on
as usual. It will only do something differ
On 10/28/2017 6:01 PM, Kalle Valo wrote:
> Maya Erez writes:
>
>> From: Lior David
>>
>> FW capabilities are currently retrieved only during module
>> initialization, but userspace can replace the firmware while
>> interface is down, so refresh the FW capabilities when
>> interface is up (afte
Maya Erez writes:
> From: Lazar Alexei
>
> Currently the statistics show how many successful/failed
> suspend/resume operations the system had.
> Update the statistics by splitting each successful/failed
> suspend/resume operations to radio on/off.
>
> Signed-off-by: Lazar Alexei
> Signed-off-b
Maya Erez writes:
> From: Lior David
>
> FW capabilities are currently retrieved only during module
> initialization, but userspace can replace the firmware while
> interface is down, so refresh the FW capabilities when
> interface is up (after FW is loaded) to ensure driver
> functionality matc
On Friday, October 27, 2017 9:26:05 AM CEST Jeffy Chen wrote:
>
> Currently we are handling wake irq in mrvl wifi driver. Move it into
> pci core.
>
> Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
>
>
> Changes in v10:
> Use device_set_wakeup_capable() instead of device_set_w
