>> I (naively) went through pci/pm git log and found the following was
>> applied on 4.7-rc2 (i.e. prior to 4.7 release):
>>
>> commit 006d44e49a259b39947366728d65a873a19aadc0
>> Author: Mika Westerberg
>> Date: Thu Jun 2 11:17:15 2016 +0300
>>
>> PCI: Add runtime PM support for PCIe
Hi Dave,
few fixes for 4.9. I tagged this on the plane over a slow mosh
connection while travelling to Plumbers so I might have done something
wrong, please check more carefully than usually. For example I had to
redo the signed tag because of some whitespace damage.
Please let me know if there a
With the current kernel release, wpa_supplicant results in authentication
failure
with a Cube i9 tablet (a Surface Pro like device):
Successfully initialized wpa_supplicant
wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78
(SSID='localre' freq=2417 MHz)
wlp0s20f0u7i2: SME: Trying
This fix enables the same sequence of init behaviour as the alternative
working driver for the wireless rtl8723bu IC at
https://github.com/lwfinger/rtl8723bu
For exampe rtl8xxxu_init_device is now called each time
userspace wpa_supplicant is executed instead of just once when
modprobe is executed.
Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set
macpower, is never 0xea. It is only ever 0x01 (first time after modprobe)
using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results
occurs with 'Fix for authentication failure' [PATCH 1/2] in place.
Whate
Hi !
in your commit f5b586909581 ("rtlwifi: btcoexist: Modify driver to support
BT coexistence in rtl8723be") you introduced a if/else where both branches
are the same but the comment in the else branch suggests that this might be
unintended.
from code review only I can´t say what the int
John Heenan writes:
> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set
> macpower, is never 0xea. It is only ever 0x01 (first time after modprobe)
> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results
> occurs with 'Fix for authentication failure'
Thanks for your reply.
The code was tested on a Cube i9 which has an internal rtl8723bu.
No other devices were tested.
I am happy to accept in an ideal context hard coding macpower is
undesirable, the comment is undesirable and it is wrong to assume the
issue is not unique to the rtl8723bu.
You
On Fri, Oct 21, 2016 at 02:21:09PM -0700, Rajat Jain wrote:
> From: Xinming Hu
>
> This patch derives device tree node from pcie bus layer framework, and
> fixes a minor memory leak in mwifiex_pcie_probe() (in failure path).
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> mar
I recently received my turris omnia and put it into operation yesterday.
(It is only doing wireless; I have a different box for my main router.)
All of the machines on the wlan show backwards transfer speeds; they
upload reasonable fast but downloads are in the kbit/s range.
That applies to the
John Heenan writes:
> Thanks for your reply.
>
> The code was tested on a Cube i9 which has an internal rtl8723bu.
>
> No other devices were tested.
>
> I am happy to accept in an ideal context hard coding macpower is
> undesirable, the comment is undesirable and it is wrong to assume the
> issue
ath10k cannot show tx rates right now in a easy way. since tx rate
handling is done by the cards own firmware and not by the mac80211
wireless stack
Sebastian
Am 30.10.2016 um 21:50 schrieb James Cloos:
I recently received my turris omnia and put it into operation yesterday.
(It is only doin
12 matches
Mail list logo
