Re: rtlwifi oops

[James Cameron]

On Fri, Oct 27, 2017 at 04:08:48AM +0300, nirinA raseliarison wrote:
> hi all,
> i applied the patch against 4.13.8. i still got some trouble, dmesg
> is below.

As this new event does not have "disabled by hub (EMI?)", it is a
different problem to your 19th October post, so I don't think the
patch is relevant.

> after i plugged the device, it seems to be detected and all modules
> loaded, but when i tried to connect to an access point, by using
> wicd, it halted after a while. at this point, all usb ports are
> broken, there was no more log in dmesg,

If the other USB ports are not responding, then your problem is
probably wider than the wireless device, and the wireless device
is acting as the "canary in the mine"; failing first because it is
the most active.

Can you test to exclude possibility of damaged USB host controller or
hub?

> lsusb still showed the device even after being unplugged. it got
> even worse as reboot failed.

Yes, once a USB host controller is failed, organised reboot can be
difficult.  lsusb not updated confirms host controller not responding.

> i cannot really trace the error as right now all thing works fine.

Your dmesg looks like you removed and reinserted the wireless device
several times.  Did you do that, or did the system do it without any
physical action?

A full dmesg from boot may be interesting, at least to better
understand the USB host controller.

-- 
James Cameron
http://quozl.netrek.org/

Re: pull-request: mac80211 2017-10-25

[David Miller]

From: Johannes Berg 
Date: Wed, 25 Oct 2017 16:03:42 +0200

> Here are a few more fixes for net, we started comprehensive testing
> for the security issues and found that the problem wasn't addressed
> in TKIP, so that's included, along with a handful other fixes.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: RTL usb adapter question

[James Cameron]

Interesting, thanks.  It should be a QFN 46 pin chip; you may have
counted 15 instead of 14 pins on the long edge.  Send me a photograph
of the inside, off-list?

There's a brief datasheet that I found, but no sign of firmware or
registers documentation, as usual;

http://www.cnping.com/wp-content/uploads/2015/09/RTL8188CUS_DataSheet_1.01.pdf

I've no direct experience with the rtl8188cus chip.  I can't prove it,
but my experience with other vendors suggests a small non-volatile
storage built into the chip for device configuration and firmware.
Device configuration often includes USB vendor:product.

I've read that Edimax uses rtl8188cus in a device programmed with
vendor:product 7392:7811, and the kernel handles this in

rtl8xxxu/rtl8xxxu_core.c
rtlwifi/rtl8192cu/sw.c

rtl8188cus has several configurable pins, so device configuration or
firmware would have been programmed to match the circuit layout.

As your kernel isn't providing firmware, yet the device works to an
extent, there is probably firmware already on the device.  I don't
know of a way to ask the device for a firmware version, or a firmware
dump.

You might sacrifice a sample to see if loading rtl8192cu firmware
changes behaviour at all.

You might also work with your device vendor to improve clarity.  ;-)

On Thu, Oct 26, 2017 at 08:28:00PM -0500, David Ashley wrote:
> I opened up the dongle, it has these things inside (aside from 2 coils
> and various resistors and capacitors)
> 1)
> 48 pin chip (9 pins, 15 pins, 9 pins, 15 pins)
> REALTEK
> RTL8188CUS
> F6J23P2
> GF27 TAIWAN
> 
> 6 pin chip (3 pins,3 pins)
> BZ5JA
> 
> 40.0 mhz crystal oscillator
> 
> I was thinking maybe some serial eeprom would be included, but there wasn't 
> one.
> 
> -Dave
> 
> 
> On 10/26/17, James Cameron  wrote:
> > Base on your evidence, I'd say the device is different to others and
> > has firmware included.
> >
> > On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote:
> >> OK I'm completely baffled.
> >>
> >> I have explicitly removed all rtlwifi/ firmware files from the root
> >> filesystem and yet the usb dongle still works, even after a power
> >> cycle. How can it possibly be getting its firmware file
> >>
> >> Here are the relevant kernel messages. There is no file
> >> rtl8192cufw.bin anywhere for the kernel to find...
> >> root@30046:~# ls -l /lib/firmware/rtlwifi/
> >> total 0
> >>
> >> I have ensured there is no *OTHER* route to the internet such that the
> >> driver (or udev) can magically get the firmware file from the
> >> internet...
> >>
> >> Here's other info that may be useful...
> >>
> >> root@30046:~# zcat /proc/config.gz | grep FIRM
> >> CONFIG_PREVENT_FIRMWARE_BUILD=y
> >> CONFIG_FIRMWARE_IN_KERNEL=y
> >> CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
> >> am335x-bone-scale-data.bin am335x-evm-scale-data.bin
> >> am43x-evm-scale-data.bin"
> >> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
> >> # CONFIG_LIBERTAS_THINFIRM is not set
> >> # CONFIG_FIRMWARE_MEMMAP is not set
> >> # CONFIG_TEST_FIRMWARE is not set
> >> root@30046:~# cat /proc/version
> >> Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
> >> 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
> >> 17:25:35 CDT 2017
> >> root@30046:~# lsusb
> >> Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
> >> 802.11n Wireless Adapter [Realtek RTL8188CUS]
> >>
> >> ... ifconfig
> >> wlan0 Link encap:Ethernet  HWaddr 74:da:38:61:f1:2c
> >>   inet addr:192.168.10.31  Bcast:192.168.10.255
> >> Mask:255.255.255.0
> >>   inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
> >>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>   RX packets:509 errors:0 dropped:0 overruns:0 frame:0
> >>   TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
> >>   collisions:0 txqueuelen:1000
> >>   RX bytes:60812 (59.3 KiB)  TX bytes:16365 (15.9 KiB)
> >>
> >>
> >>
> >>
> >> [9.663796] rtl8192cu: Chip version 0x10
> >> [9.745394] cfg80211: Calling CRDA to update world regulatory domain
> >> [9.844311] random: nonblocking pool is initialized
> >> [9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
> >> [9.877883] rtl8192cu: Board Type 0
> >> [9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> >> [9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> >> [9.878249] usb 1-1: Direct firmware load for
> >> rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
> >> [9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> >> [9.890862] usbcore: registered new interface driver rtl8192cu
> >> [9.897667] usb 1-1: Direct firmware load for
> >> rtlwifi/rtl8192cufw.bin failed with error -2
> >> [9.906030] rtlwifi: Loading alternative firmware
> >> rtlwifi/rtl8192cufw.bin
> >> [9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not
> >> available
> >> [   11.316476] rtl8192cu: MAC auto ON okay!
> 

[PATCH] ath10k: Fix data rx for CCMP-256, GCMP and GCMP-256 in raw mode

[Vasanthakumar Thiagarajan]

Make sure 16-byte mic is removed from the rx data packet
tail when CCMP-256, GCMP and GCMP-256 ciphers are used
in raw decap mode. This fixed rx traffic failures in those
ciphers in raw mode. Split the helper returning crypto
tail length into two, one to get the ICV length and other
to get the mic lengh for the cipher to make it clean.

Fixes: 2ea9f12cefe4 ("ath10k: add new cipher suite support")
Signed-off-by: Vasanthakumar Thiagarajan 
---

This patch depends on https://patchwork.kernel.org/patch/10028621/

 drivers/net/wireless/ath/ath10k/htt_rx.c | 51 
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 5beb6ee0f091..656385f80929 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -566,18 +566,16 @@ static int ath10k_htt_rx_crypto_param_len(struct ath10k 
*ar,
 
 #define MICHAEL_MIC_LEN 8
 
-static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
-enum htt_rx_mpdu_encrypt_type type)
+static int ath10k_htt_rx_crypto_mic_len(struct ath10k *ar,
+   enum htt_rx_mpdu_encrypt_type type)
 {
switch (type) {
case HTT_RX_MPDU_ENCRYPT_NONE:
-   return 0;
case HTT_RX_MPDU_ENCRYPT_WEP40:
case HTT_RX_MPDU_ENCRYPT_WEP104:
-   return IEEE80211_WEP_ICV_LEN;
case HTT_RX_MPDU_ENCRYPT_TKIP_WITHOUT_MIC:
case HTT_RX_MPDU_ENCRYPT_TKIP_WPA:
-   return IEEE80211_TKIP_ICV_LEN;
+   return 0;
case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
return IEEE80211_CCMP_MIC_LEN;
case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
@@ -594,6 +592,31 @@ static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
return 0;
 }
 
+static int ath10k_htt_rx_crypto_icv_len(struct ath10k *ar,
+   enum htt_rx_mpdu_encrypt_type type)
+{
+   switch (type) {
+   case HTT_RX_MPDU_ENCRYPT_NONE:
+   case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
+   case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
+   case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2:
+   case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2:
+   return 0;
+   case HTT_RX_MPDU_ENCRYPT_WEP40:
+   case HTT_RX_MPDU_ENCRYPT_WEP104:
+   return IEEE80211_WEP_ICV_LEN;
+   case HTT_RX_MPDU_ENCRYPT_TKIP_WITHOUT_MIC:
+   case HTT_RX_MPDU_ENCRYPT_TKIP_WPA:
+   return IEEE80211_TKIP_ICV_LEN;
+   case HTT_RX_MPDU_ENCRYPT_WEP128:
+   case HTT_RX_MPDU_ENCRYPT_WAPI:
+   break;
+   }
+
+   ath10k_warn(ar, "unsupported encryption type %d\n", type);
+   return 0;
+}
+
 struct amsdu_subframe_hdr {
u8 dst[ETH_ALEN];
u8 src[ETH_ALEN];
@@ -1063,25 +1086,27 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k 
*ar,
/* Tail */
if (status->flag & RX_FLAG_IV_STRIPPED) {
skb_trim(msdu, msdu->len -
-ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ath10k_htt_rx_crypto_mic_len(ar, enctype));
+
+   skb_trim(msdu, msdu->len -
+ath10k_htt_rx_crypto_icv_len(ar, enctype));
} else {
/* MIC */
-   if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
-   enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
-   skb_trim(msdu, msdu->len - 8);
+   if (status->flag & RX_FLAG_MIC_STRIPPED)
+   skb_trim(msdu, msdu->len -
+ath10k_htt_rx_crypto_mic_len(ar, enctype));
 
/* ICV */
-   if (status->flag & RX_FLAG_ICV_STRIPPED &&
-   enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   if (status->flag & RX_FLAG_ICV_STRIPPED)
skb_trim(msdu, msdu->len -
-ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ath10k_htt_rx_crypto_icv_len(ar, enctype));
}
 
/* MMIC */
if ((status->flag & RX_FLAG_MMIC_STRIPPED) &&
!ieee80211_has_morefrags(hdr->frame_control) &&
enctype == HTT_RX_MPDU_ENCRYPT_TKIP_WPA)
-   skb_trim(msdu, msdu->len - 8);
+   skb_trim(msdu, msdu->len - MICHAEL_MIC_LEN);
 
/* Head */
if (status->flag & RX_FLAG_IV_STRIPPED) {
-- 
1.9.1

Re: RTL usb adapter question

[David Ashley]

I opened up the dongle, it has these things inside (aside from 2 coils
and various resistors and capacitors)
1)
48 pin chip (9 pins, 15 pins, 9 pins, 15 pins)
REALTEK
RTL8188CUS
F6J23P2
GF27 TAIWAN

6 pin chip (3 pins,3 pins)
BZ5JA

40.0 mhz crystal oscillator

I was thinking maybe some serial eeprom would be included, but there wasn't one.

-Dave


On 10/26/17, James Cameron  wrote:
> Base on your evidence, I'd say the device is different to others and
> has firmware included.
>
> On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote:
>> OK I'm completely baffled.
>>
>> I have explicitly removed all rtlwifi/ firmware files from the root
>> filesystem and yet the usb dongle still works, even after a power
>> cycle. How can it possibly be getting its firmware file
>>
>> Here are the relevant kernel messages. There is no file
>> rtl8192cufw.bin anywhere for the kernel to find...
>> root@30046:~# ls -l /lib/firmware/rtlwifi/
>> total 0
>>
>> I have ensured there is no *OTHER* route to the internet such that the
>> driver (or udev) can magically get the firmware file from the
>> internet...
>>
>> Here's other info that may be useful...
>>
>> root@30046:~# zcat /proc/config.gz | grep FIRM
>> CONFIG_PREVENT_FIRMWARE_BUILD=y
>> CONFIG_FIRMWARE_IN_KERNEL=y
>> CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
>> am335x-bone-scale-data.bin am335x-evm-scale-data.bin
>> am43x-evm-scale-data.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
>> # CONFIG_LIBERTAS_THINFIRM is not set
>> # CONFIG_FIRMWARE_MEMMAP is not set
>> # CONFIG_TEST_FIRMWARE is not set
>> root@30046:~# cat /proc/version
>> Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
>> 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
>> 17:25:35 CDT 2017
>> root@30046:~# lsusb
>> Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
>> 802.11n Wireless Adapter [Realtek RTL8188CUS]
>>
>> ... ifconfig
>> wlan0 Link encap:Ethernet  HWaddr 74:da:38:61:f1:2c
>>   inet addr:192.168.10.31  Bcast:192.168.10.255
>> Mask:255.255.255.0
>>   inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:509 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:60812 (59.3 KiB)  TX bytes:16365 (15.9 KiB)
>>
>>
>>
>>
>> [9.663796] rtl8192cu: Chip version 0x10
>> [9.745394] cfg80211: Calling CRDA to update world regulatory domain
>> [9.844311] random: nonblocking pool is initialized
>> [9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
>> [9.877883] rtl8192cu: Board Type 0
>> [9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
>> [9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>> [9.878249] usb 1-1: Direct firmware load for
>> rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
>> [9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
>> [9.890862] usbcore: registered new interface driver rtl8192cu
>> [9.897667] usb 1-1: Direct firmware load for
>> rtlwifi/rtl8192cufw.bin failed with error -2
>> [9.906030] rtlwifi: Loading alternative firmware
>> rtlwifi/rtl8192cufw.bin
>> [9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not
>> available
>> [   11.316476] rtl8192cu: MAC auto ON okay!
>> [   11.333847] rtl8192cu: Tx queue select: 0x05
>> [   12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [   12.905367] cfg80211: Calling CRDA to update world regulatory domain
>> [   13.413043] rtl8192cu: MAC auto ON okay!
>> [   13.430371] rtl8192cu: Tx queue select: 0x05
>> [   15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [   16.065356] cfg80211: Calling CRDA to update world regulatory domain
>> [   19.225333] cfg80211: Calling CRDA to update world regulatory domain
>> [   21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
>> [   21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
>> [   21.605390] wlan0: authenticated
>> [   21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
>> [   21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
>> status=0 aid=5)
>> [   21.669000] wlan0: associated
>> [   21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> [   22.385320] cfg80211: Calling CRDA to update world regulatory domain
>> [   25.545336] cfg80211: Calling CRDA to update world regulatory domain
>> [   28.705312] cfg80211: Calling CRDA to update world regulatory domain
>> [   31.865335] cfg80211: Calling CRDA to update world regulatory domain
>> [   35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling
>> CRDA
>>
>>
>> Thanks!!
>> -Dave
>>
>> On 10/25/17, Larry Finger  wrote:
>> > On 10/25/2017 01:43 PM, David Ashley wrote:
>> >> I'm trying to understand how the linux kernel loads 

Re: rtlwifi oops

[nirinA raseliarison]

hi all,
i applied the patch against 4.13.8. i still got some trouble, dmesg is 
below.

after i plugged the device, it seems to be detected and all modules loaded,
but when i tried to connect to an access point, by using wicd, it halted 
after
a while. at this point, all usb ports are broken, there was no more log 
in dmesg,
lsusb still showed the device even after being unplugged. it got even 
worse as

reboot failed.
i cannot really trace the error as right now all thing works fine.

##

[101297.29] usb 2-1.4: new high-speed USB device number 6 using ehci-pci
[101297.290836] usb 2-1.4: New USB device found, idVendor=0bda, 
idProduct=8178
[101297.290839] usb 2-1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[101297.290840] usb 2-1.4: Product: 802.11n WLAN Adapter
[101297.290841] usb 2-1.4: Manufacturer: Realtek
[101297.290842] usb 2-1.4: SerialNumber: 00e04c01
[101297.841845] rtl8192cu: Chip version 0x11
[101297.97] rtl8192cu: Board Type 0
[101297.973581] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101297.973621] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101297.973743] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[101297.973923] usbcore: registered new interface driver rtl8192cu
[101298.013513] usbcore: registered new interface driver rtl8xxxu
[101298.113014] rtl8192cu 2-1.4:1.0 wlan125: renamed from wlan0
[101298.116255] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan125
[101298.319580] usb 2-1.4: USB disconnect, device number 6
[101298.508120] usb 2-1.4: new high-speed USB device number 7 using ehci-pci
[101298.748134] usb 2-1.4: new high-speed USB device number 8 using ehci-pci
[101298.827700] usb 2-1.4: New USB device found, idVendor=0bda, 
idProduct=8178
[101298.827702] usb 2-1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[101298.827703] usb 2-1.4: Product: 802.11n WLAN Adapter
[101298.827704] usb 2-1.4: Manufacturer: Realtek
[101298.827705] usb 2-1.4: SerialNumber: 00e04c01
[101298.828320] rtl8192cu: Chip version 0x11
[101298.907705] rtl8192cu: Board Type 0
[101298.907945] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101298.907976] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101298.908145] ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
[101298.922774] rtl8192cu 2-1.4:1.0 wlan124: renamed from wlan0
[101298.926242] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan124
[101312.904723] rtl8192cu: MAC auto ON okay!
[101312.939101] rtl8192cu: Tx queue select: 0x05
[101313.541630] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101322.297910] rtl8192cu: MAC auto ON okay!
[101322.331036] rtl8192cu: Tx queue select: 0x05
[101322.933065] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101323.089905] rtl8192cu: MAC auto ON okay!
[101323.122907] rtl8192cu: Tx queue select: 0x05
[101323.730181] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101325.455267] usb 2-1.4: USB disconnect, device number 8
[101325.460166] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! 
status:0xffed value=0xf9
[101325.460168] rtl_usb: reg 0x422, usbctrl_vendorreq TimeOut! 
status:0xffed value=0x100
[101325.460171] rtl_usb: reg 0x542, usbctrl_vendorreq TimeOut! 
status:0xffed value=0x3fd
[101325.460186] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! 
status:0xffed value=0xf9

[101325.655146] usb 2-1.4: new high-speed USB device number 9 using ehci-pci
[101325.734893] usb 2-1.4: New USB device found, idVendor=0bda, 
idProduct=8178
[101325.734897] usb 2-1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[101325.734898] usb 2-1.4: Product: 802.11n WLAN Adapter
[101325.734899] usb 2-1.4: Manufacturer: Realtek
[101325.734900] usb 2-1.4: SerialNumber: 00e04c01
[101325.735636] rtl8192cu: Chip version 0x11
[101325.812035] rtl8192cu: Board Type 0
[101325.812394] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101325.812470] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101325.812725] ieee80211 phy2: Selected rate control algorithm 'rtl_rc'
[101325.827120] rtl8192cu 2-1.4:1.0 wlan123: renamed from wlan0
[101325.832254] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan123
[101332.879463] usb 2-1.4: USB disconnect, device number 9
[101333.072149] usb 2-1.4: new high-speed USB device number 10 using 
ehci-pci
[101333.151841] usb 2-1.4: New USB device found, idVendor=0bda, 
idProduct=8178
[101333.151843] usb 2-1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[101333.151845] usb 2-1.4: Product: 802.11n WLAN Adapter
[101333.151846] usb 2-1.4: Manufacturer: Realtek
[101333.151847] usb 2-1.4: SerialNumber: 00e04c01
[101333.152585] rtl8192cu: Chip version 0x11
[101333.229738] rtl8192cu: Board Type 0
[101333.229963] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101333.230038] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101333.230298] ieee80211 phy3: Selected rate control algorithm 'rtl_rc'
[101333.49] rtl8192cu 2-1.4:1.0 wlan122: renamed 

Re: RTL usb adapter question

[James Cameron]

Base on your evidence, I'd say the device is different to others and
has firmware included.

On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote:
> OK I'm completely baffled.
> 
> I have explicitly removed all rtlwifi/ firmware files from the root
> filesystem and yet the usb dongle still works, even after a power
> cycle. How can it possibly be getting its firmware file
> 
> Here are the relevant kernel messages. There is no file
> rtl8192cufw.bin anywhere for the kernel to find...
> root@30046:~# ls -l /lib/firmware/rtlwifi/
> total 0
> 
> I have ensured there is no *OTHER* route to the internet such that the
> driver (or udev) can magically get the firmware file from the
> internet...
> 
> Here's other info that may be useful...
> 
> root@30046:~# zcat /proc/config.gz | grep FIRM
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FIRMWARE_IN_KERNEL=y
> CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
> am335x-bone-scale-data.bin am335x-evm-scale-data.bin
> am43x-evm-scale-data.bin"
> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
> # CONFIG_LIBERTAS_THINFIRM is not set
> # CONFIG_FIRMWARE_MEMMAP is not set
> # CONFIG_TEST_FIRMWARE is not set
> root@30046:~# cat /proc/version
> Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
> 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
> 17:25:35 CDT 2017
> root@30046:~# lsusb
> Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
> 802.11n Wireless Adapter [Realtek RTL8188CUS]
> 
> ... ifconfig
> wlan0 Link encap:Ethernet  HWaddr 74:da:38:61:f1:2c
>   inet addr:192.168.10.31  Bcast:192.168.10.255  Mask:255.255.255.0
>   inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:509 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:60812 (59.3 KiB)  TX bytes:16365 (15.9 KiB)
> 
> 
> 
> 
> [9.663796] rtl8192cu: Chip version 0x10
> [9.745394] cfg80211: Calling CRDA to update world regulatory domain
> [9.844311] random: nonblocking pool is initialized
> [9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
> [9.877883] rtl8192cu: Board Type 0
> [9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> [9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [9.878249] usb 1-1: Direct firmware load for
> rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
> [9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [9.890862] usbcore: registered new interface driver rtl8192cu
> [9.897667] usb 1-1: Direct firmware load for
> rtlwifi/rtl8192cufw.bin failed with error -2
> [9.906030] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
> [9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available
> [   11.316476] rtl8192cu: MAC auto ON okay!
> [   11.333847] rtl8192cu: Tx queue select: 0x05
> [   12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [   12.905367] cfg80211: Calling CRDA to update world regulatory domain
> [   13.413043] rtl8192cu: MAC auto ON okay!
> [   13.430371] rtl8192cu: Tx queue select: 0x05
> [   15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [   16.065356] cfg80211: Calling CRDA to update world regulatory domain
> [   19.225333] cfg80211: Calling CRDA to update world regulatory domain
> [   21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
> [   21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
> [   21.605390] wlan0: authenticated
> [   21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
> [   21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
> status=0 aid=5)
> [   21.669000] wlan0: associated
> [   21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [   22.385320] cfg80211: Calling CRDA to update world regulatory domain
> [   25.545336] cfg80211: Calling CRDA to update world regulatory domain
> [   28.705312] cfg80211: Calling CRDA to update world regulatory domain
> [   31.865335] cfg80211: Calling CRDA to update world regulatory domain
> [   35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
> 
> 
> Thanks!!
> -Dave
> 
> On 10/25/17, Larry Finger  wrote:
> > On 10/25/2017 01:43 PM, David Ashley wrote:
> >> I'm trying to understand how the linux kernel loads RTL8188CUS firmware
> >> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
> >> when that file isn't available anywhere in my embedded system's
> >> filesystem.
> >>
> >> Basically I'm trying to understand the theory. We have a product that
> >> is making use of the device
> >>
> >> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
> >> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
> >>
> >> It has not been especially reliable. I've never provided firmware
> >> files for 

Re: RTL usb adapter question

[David Ashley]

OK I'm completely baffled.

I have explicitly removed all rtlwifi/ firmware files from the root
filesystem and yet the usb dongle still works, even after a power
cycle. How can it possibly be getting its firmware file

Here are the relevant kernel messages. There is no file
rtl8192cufw.bin anywhere for the kernel to find...
root@30046:~# ls -l /lib/firmware/rtlwifi/
total 0

I have ensured there is no *OTHER* route to the internet such that the
driver (or udev) can magically get the firmware file from the
internet...

Here's other info that may be useful...

root@30046:~# zcat /proc/config.gz | grep FIRM
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
am335x-bone-scale-data.bin am335x-evm-scale-data.bin
am43x-evm-scale-data.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_FIRMWARE_MEMMAP is not set
# CONFIG_TEST_FIRMWARE is not set
root@30046:~# cat /proc/version
Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
17:25:35 CDT 2017
root@30046:~# lsusb
Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
802.11n Wireless Adapter [Realtek RTL8188CUS]

... ifconfig
wlan0 Link encap:Ethernet  HWaddr 74:da:38:61:f1:2c
  inet addr:192.168.10.31  Bcast:192.168.10.255  Mask:255.255.255.0
  inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:509 errors:0 dropped:0 overruns:0 frame:0
  TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:60812 (59.3 KiB)  TX bytes:16365 (15.9 KiB)




[9.663796] rtl8192cu: Chip version 0x10
[9.745394] cfg80211: Calling CRDA to update world regulatory domain
[9.844311] random: nonblocking pool is initialized
[9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
[9.877883] rtl8192cu: Board Type 0
[9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[9.878249] usb 1-1: Direct firmware load for
rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
[9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[9.890862] usbcore: registered new interface driver rtl8192cu
[9.897667] usb 1-1: Direct firmware load for
rtlwifi/rtl8192cufw.bin failed with error -2
[9.906030] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
[9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available
[   11.316476] rtl8192cu: MAC auto ON okay!
[   11.333847] rtl8192cu: Tx queue select: 0x05
[   12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   12.905367] cfg80211: Calling CRDA to update world regulatory domain
[   13.413043] rtl8192cu: MAC auto ON okay!
[   13.430371] rtl8192cu: Tx queue select: 0x05
[   15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   16.065356] cfg80211: Calling CRDA to update world regulatory domain
[   19.225333] cfg80211: Calling CRDA to update world regulatory domain
[   21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
[   21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
[   21.605390] wlan0: authenticated
[   21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
[   21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
status=0 aid=5)
[   21.669000] wlan0: associated
[   21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   22.385320] cfg80211: Calling CRDA to update world regulatory domain
[   25.545336] cfg80211: Calling CRDA to update world regulatory domain
[   28.705312] cfg80211: Calling CRDA to update world regulatory domain
[   31.865335] cfg80211: Calling CRDA to update world regulatory domain
[   35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA


Thanks!!
-Dave

On 10/25/17, Larry Finger  wrote:
> On 10/25/2017 01:43 PM, David Ashley wrote:
>> I'm trying to understand how the linux kernel loads RTL8188CUS firmware
>> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
>> when that file isn't available anywhere in my embedded system's
>> filesystem.
>>
>> Basically I'm trying to understand the theory. We have a product that
>> is making use of the device
>>
>> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
>> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
>>
>> It has not been especially reliable. I've never provided firmware
>> files for the device in the root filesystem. I've started to pay
>> attention to the kernel error messages. Now the kernel drivers seem to
>> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
>> understand if this is actually working, if it makes any difference in
>> reliability...
>>
>> It's like I can't figure out how the usb dongle even worked without

Re: Commit 0711d638 breaks mwifiex

[Brian Norris]

Hi,

I'm not sure I've followed all the problems here, but I wanted to point
some things out:

On Tue, Oct 17, 2017 at 12:48:18PM +0200, Johannes Berg wrote:
> On Tue, 2017-10-17 at 18:18 +0800, Jesse Sung wrote:
> 
> > > Does mwifiex treat this -EALREADY as *keeping* an old connection,
> > > or tearing it down entirely?
> > 
> > From the call trace:
> 
> Well, the call trace can't really answer that :-)
> Does mwifiex firmware stay connected?

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 different if the upper layers tell
it to do so afterward (e.g., calling disconnect()).

> > 139.451318: nl80211_get_valid_chan <-nl80211_connect
> > 139.451321: cfg80211_connect <-nl80211_connect
> > 139.451322: cfg80211_oper_and_ht_capa <-cfg80211_connect
> > 139.451323: mwifiex_cfg80211_connect <-cfg80211_connect
> > 139.451337: nl80211_post_doit <-genl_family_rcv_msg
> > 139.451423: nl80211_pre_doit <-genl_family_rcv_msg
> > 139.451425: nl80211_disconnect <-genl_family_rcv_msg
> > 139.451426: cfg80211_disconnect <-nl80211_disconnect
> > 139.451430: mwifiex_cfg80211_disconnect <-cfg80211_disconnect
> > 
> > mwifiex_cfg80211_disconnect() would be called after
> > mwifiex_cfg80211_connect(), though I'm not sure if it's triggered by
> > the error returned.
> 
> I think so - it's probably wpa_supplicant trying to get back to a well-
> known state (of being disconnected).

Yes, that's definitely what's happening. And it's explicitly called out
in the supplicant's nl80211 driver that this is intentional:

static int wpa_driver_nl80211_connect(
struct wpa_driver_nl80211_data *drv,
struct wpa_driver_associate_params *params)
{
...
ret = wpa_driver_nl80211_try_connect(drv, params);
if (ret == -EALREADY) {
/*
 * cfg80211 does not currently accept new connections if
 * we are already connected. As a workaround, force
 * disconnection and try again.
 */
wpa_printf(MSG_DEBUG, "nl80211: Explicitly "
   "disconnecting before reassociation "
   "attempt");
if (wpa_driver_nl80211_disconnect(
drv, WLAN_REASON_PREV_AUTH_NOT_VALID))
return -1;
ret = wpa_driver_nl80211_try_connect(drv, params);
}
return ret;
}

This is the main code path for supplicant commands like "Reattach",
which boil down to (for non SME drivers):

wpas_request_connection()
  ...
 -> wpa_supplicant_connect()
   -> wpa_supplicant_associate()
 -> wpas_start_assoc_cb()
   -> wpa_drv_associate()
 -> wpa_driver_nl80211_associate()
   -> wpa_driver_nl80211_connect()

Now for the part I'm not so familiar with: is this really the *expected*
flow for full-MAC drivers in reattach, reassociate, and roaming flows?
All of those seem to boil down to this same connect() (and fallback to
disconnect()+connect() if -EALREADY) flow.

But it doesn't seem like all full-MAC drivers do the same thing. Some
seem to just blaze ahead with a connect attempt (maybe some firmwares
automatically interpret this for us?) and never return -EALREADY at all.

Sorry if this is slightly off-topic, but I'm trying to understand what
the general expectations are here, based on my relatively narrow
experience with a few drivers.

Brian

Re: [linuxwifi] Support Help on WiFi driver

[Luciano Coelho]

BTW, all mailing lists @vger.kernel.org drop emails sent in HTML
format, so your original email didn't reach it.

--
Cheers,
Luca.

On Thu, 2017-10-26 at 22:18 +0300, Luciano Coelho wrote:
> Hi Edwin,
> 
> Please give us a bit more information. What is the kernel version
> that your distro uses? And what is the WiFi card that yo have in this
> machine?
> 
> Also, a dmesg output can help us start the investigation.
> 
> --
> Cheers,
> Luca.
> 
> On Thu, 2017-10-26 at 13:44 +, Edwin Amurao wrote:
> > Hi!
> > 
> > I have an INTEL NUC5CFYPH and have installed Linux Mint 17.3.  The
> > wifi cannot be detected by the system.  What driver should I
> > download and how to make it work?
> > 
> > Thank you,
> > Edwin Amurao

[PATCH v3] ath10k: rebuild crypto header in rx data frames

[Kalle Valo]

From: Vasanthakumar Thiagarajan 

Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.

Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers
in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.

Tested-by: Manikanta Pubbisetty 
Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Kalle Valo 
---

v3:

* Fix cipher header construction for CCMP-256, GCMP and GCMP-256
  ciphers.

* Fix bug in raw mode when RX_FLAG_IV_STRIPPED is set.

v2:

* Construct cipher header from rx_hdr_status tlv rather than from
  the msdu_start and mpdu_start tlvs. This fixes connection
  issues, also reduces the amount of code change.

* Make sure the frame is qos data before clearing AMSDU_PRESENT
  bit of qos control field.

* Fix traffic issue with QCA988X and QCA9887 hw by taking care of
  padding bytes added for 4-byte alignment before the cipher
  header.

 drivers/net/wireless/ath/ath10k/htt_rx.c  | 105 +-
 drivers/net/wireless/ath/ath10k/rx_desc.h |   3 +
 2 files changed, 92 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a3f5dc78353f..5beb6ee0f091 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -550,6 +550,11 @@ static int ath10k_htt_rx_crypto_param_len(struct ath10k 
*ar,
return IEEE80211_TKIP_IV_LEN;
case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
return IEEE80211_CCMP_HDR_LEN;
+   case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
+   return IEEE80211_CCMP_256_HDR_LEN;
+   case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2:
+   case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2:
+   return IEEE80211_GCMP_HDR_LEN;
case HTT_RX_MPDU_ENCRYPT_WEP128:
case HTT_RX_MPDU_ENCRYPT_WAPI:
break;
@@ -575,6 +580,11 @@ static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
return IEEE80211_TKIP_ICV_LEN;
case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
return IEEE80211_CCMP_MIC_LEN;
+   case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
+   return IEEE80211_CCMP_256_MIC_LEN;
+   case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2:
+   case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2:
+   return IEEE80211_GCMP_MIC_LEN;
case HTT_RX_MPDU_ENCRYPT_WEP128:
case HTT_RX_MPDU_ENCRYPT_WAPI:
break;
@@ -1051,9 +1061,21 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k 
*ar,
hdr = (void *)msdu->data;
 
/* Tail */
-   if (status->flag & RX_FLAG_IV_STRIPPED)
+   if (status->flag & RX_FLAG_IV_STRIPPED) {
skb_trim(msdu, msdu->len -
 ath10k_htt_rx_crypto_tail_len(ar, enctype));
+   } else {
+   /* MIC */
+   if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
+   enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len - 8);
+
+   /* ICV */
+   if (status->flag & RX_FLAG_ICV_STRIPPED &&
+   enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len -
+ath10k_htt_rx_crypto_tail_len(ar, enctype));
+   }
 
/* MMIC */
if ((status->flag & RX_FLAG_MMIC_STRIPPED) &&
@@ -1075,7 +1097,8 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k *ar,
 static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,
  struct sk_buff *msdu,
  struct ieee80211_rx_status *status,
- const u8 first_hdr[64])
+ const u8 first_hdr[64],
+ enum htt_rx_mpdu_encrypt_type enctype)
 {
struct ieee80211_hdr *hdr;
struct htt_rx_desc *rxd;
@@ -1083,6 +1106,7 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k 
*ar,
u8 da[ETH_ALEN];
u8 

Re: [PATCH v2] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

[WoWz89]

Здравствуйте, Seth.

Вы писали 20 октября 2017 г., 21:06:51:

> Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> based on the documents at [1] and [2].

> v2: Also add DFS region
Hello, you mean the patch for Kazakhstan is not forgotten ?
> [1]
> http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> [2] http://adilet.zan.kz/rus/docs/P01379_

> Signed-off-by: Seth Forshee 
> ---
>  db.txt | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

> diff --git a/db.txt b/db.txt
> index 9d129f2e542b..10c84ee1ca5d 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -691,8 +691,14 @@ country KY: DFS-FCC
> (5490 - 5730 @ 160), (24), DFS
> (5735 - 5835 @ 80), (30)
>  
> -country KZ:
> +# Source:
> +#
> http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> +# http://adilet.zan.kz/rus/docs/P01379_
> +country KZ: DFS-ETSI
> (2402 - 2482 @ 40), (20)
> +   (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
> +   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
> +   (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
>  
>  country LB: DFS-FCC
> (2402 - 2482 @ 40), (20)



-- 
С уважением,
 WoWz89  mailto:wow...@mail.ru

[RFC PATCH v8 0/7] PCI: rockchip: Move PCIe WAKE# handling into pci core

[Jeffy Chen]

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 v8:
Add optional "pci", and rewrite commit message.
Rewrite the commit message.
Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.

Changes in v7:
Move PCIE_WAKE handling into pci core.

Changes in v6:
Fix device_init_wake error handling, and add some comments.

Changes in v5:
Move to pci.txt
Use "wakeup" instead of "wake"
Rebase.

Changes in v3:
Fix error handling.

Changes in v2:
Use dev_pm_set_dedicated_wake_irq.

Jeffy Chen (7):
  dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
  mwifiex: Disable wakeup irq handling for pcie
  arm64: dts: rockchip: Handle PCIe WAKE# signal in pcie driver for Gru
  of/irq: Adjust of pci irq parsing for multiple interrupts
  PCI: Make pci_platform_pm_ops's callbacks optional
  PCI / PM: Move acpi wakeup code to pci core
  PCI / PM: Add support for the PCIe WAKE# signal for OF

 Documentation/devicetree/bindings/pci/pci.txt |   3 +
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi  |  15 +--
 drivers/net/wireless/marvell/mwifiex/main.c   |   4 +
 drivers/of/of_pci_irq.c   |  13 ++-
 drivers/pci/Makefile  |   2 +-
 drivers/pci/pci-acpi.c| 121 +++
 drivers/pci/pci-driver.c  |   9 ++
 drivers/pci/pci-of.c  | 136 ++
 drivers/pci/pci.c | 112 +
 drivers/pci/pci.h |  31 --
 drivers/pci/probe.c   |  12 ++-
 drivers/pci/remove.c  |   2 +
 include/linux/pci.h   |   2 +
 13 files changed, 365 insertions(+), 97 deletions(-)
 create mode 100644 drivers/pci/pci-of.c

-- 
2.11.0

[RFC PATCH v8 2/7] mwifiex: Disable wakeup irq handling for pcie

[Jeffy Chen]

We are going to handle the wakeup irq in the pci core.

Signed-off-by: Jeffy Chen 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v3: None
Changes in v2: None

 drivers/net/wireless/marvell/mwifiex/main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index ee40b739b289..ba081c16f85c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1568,6 +1568,10 @@ static void mwifiex_probe_of(struct mwifiex_adapter 
*adapter)
goto err_exit;
 
adapter->dt_node = dev->of_node;
+
+   if (adapter->iface_type != MWIFIEX_PCIE)
+   goto err_exit;
+
adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
if (!adapter->irq_wakeup) {
dev_dbg(dev, "fail to parse irq_wakeup from device tree\n");
-- 
2.11.0

Activity LED does not work on TL-WN823N 2.0 WLAN dongle

[sonofagun]

The TL-WN823N USB 2.0 WLAN dongle based on RTL8192EU has its green LED turned 
off always. Tried various distributions(debian, ubuntu) but none worked :(

On windows 7 SP1 its LED works fine and it is much faster.

Is it possible to make it work under linux?

[PATCH] cfg80211: initialize regulatory keys/database later

[Johannes Berg]

From: Johannes Berg 

When cfg80211 is built as a module, everything is fine, and we
can keep the code as is; in fact, we have to, because there can
only be a single module_init().

When cfg80211 is built-in, however, it needs to initialize
before drivers (device_initcall/module_init), and thus used to
be at subsys_initcall(). I'd moved it to fs_initcall() earlier,
where it can remain. However, this is still too early because at
that point the key infrastructure hasn't been initialized yet,
so X.509 certificates can't be parsed yet.

To work around this problem, load the regdb keys only later in
a late_initcall(), at which point the necessary infrastructure
has been initialized.

Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
Reported-by: Xiaolong Ye 
Signed-off-by: Johannes Berg 
---
 net/wireless/reg.c | 42 +++---
 1 file changed, 27 insertions(+), 15 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 3871998059de..78e71b0390be 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3644,27 +3644,14 @@ void regulatory_propagate_dfs_state(struct wiphy *wiphy,
}
 }
 
-int __init regulatory_init(void)
+static int __init regulatory_init_db(void)
 {
-   int err = 0;
+   int err;
 
err = load_builtin_regdb_keys();
if (err)
return err;
 
-   reg_pdev = platform_device_register_simple("regulatory", 0, NULL, 0);
-   if (IS_ERR(reg_pdev))
-   return PTR_ERR(reg_pdev);
-
-   spin_lock_init(_requests_lock);
-   spin_lock_init(_pending_beacons_lock);
-   spin_lock_init(_indoor_lock);
-
-   rcu_assign_pointer(cfg80211_regdomain, cfg80211_world_regdom);
-
-   user_alpha2[0] = '9';
-   user_alpha2[1] = '7';
-
/* We always try to get an update for the static regdomain */
err = regulatory_hint_core(cfg80211_world_regdom->alpha2);
if (err) {
@@ -3692,6 +3679,31 @@ int __init regulatory_init(void)
 
return 0;
 }
+#ifndef MODULE
+late_initcall(regulatory_init_db);
+#endif
+
+int __init regulatory_init(void)
+{
+   reg_pdev = platform_device_register_simple("regulatory", 0, NULL, 0);
+   if (IS_ERR(reg_pdev))
+   return PTR_ERR(reg_pdev);
+
+   spin_lock_init(_requests_lock);
+   spin_lock_init(_pending_beacons_lock);
+   spin_lock_init(_indoor_lock);
+
+   rcu_assign_pointer(cfg80211_regdomain, cfg80211_world_regdom);
+
+   user_alpha2[0] = '9';
+   user_alpha2[1] = '7';
+
+#ifdef MODULE
+   return regulatory_init_db();
+#else
+   return 0;
+#endif
+}
 
 void regulatory_exit(void)
 {
-- 
2.14.2