Re: Linux wireless times out at Google Starbucks location

[David Ho]

On Thu, Oct 10, 2019 at 12:09 PM Krishna Chaitanya
 wrote:
>
> Did you also updated to corresponding linux-firmware, that might have
> solved the problem?

Nothing else was changed other than the kernel being booted from grub;
 I would have said that otherwise.

Re: Linux wireless times out at Google Starbucks location

[Krishna Chaitanya]

On Thu, Oct 10, 2019 at 11:14 PM David Ho  wrote:
>
> Hi Dan, Steve,
>
> The issue was fixed by booting the latest 5.0.x upstream kernel !!!  I
> guess this has something to do with 5.0.0 and seems to have been fixed
> since then.   It appears I put too much faith in an LTS kernel...
>
> $ uname -a
> Linux mumble15 5.0.21-050021-generic #201906040731 SMP Tue Jun 4
> 07:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Did you also updated to corresponding linux-firmware, that might have
solved the problem?

Re: Linux wireless times out at Google Starbucks location

[David Ho]

Hi Dan, Steve,

The issue was fixed by booting the latest 5.0.x upstream kernel !!!  I
guess this has something to do with 5.0.0 and seems to have been fixed
since then.   It appears I put too much faith in an LTS kernel...

$ uname -a
Linux mumble15 5.0.21-050021-generic #201906040731 SMP Tue Jun 4
07:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

On Tue, Oct 8, 2019 at 5:33 PM David Ho  wrote:
>
> Hi Dan, Steve,
>
> The issue was fixed by booting the latest 5.0.x upstream kernel !!!  I guess 
> this has something to do with 5.0.0 and seems to have been fixed since then.  
>  It appears I put too much faith in an LTS kernel...
>
> $ uname -a
> Linux mumble15 5.0.21-050021-generic #201906040731 SMP Tue Jun 4 07:33:07 UTC 
> 2019 x86_64 x86_64 x86_64 GNU/Linux
>
> On Wed, Sep 25, 2019 at 3:01 PM David Ho  wrote:
>>
>> Hi Steve, Dan,
>>
>> I have scouted the neighborhood (San Diego, CA) and visited 6
>> Starbucks.  I found another one with the same issue, so 2/6.  This
>> appears to be a systemic issue (Not one-off).
>>
>> I'm wondering if there is anything that you believe I can try at this
>> point.  There is nothing unusual about these stores.  Everyone is
>> happily connected on their Macs, and Windows notebooks.
>>
>> Can you offer any advice or point me to an expert who can help?
>>
>> Regards,
>> David
>>
>>
>> On Tue, Sep 17, 2019 at 2:01 PM Dan Williams  wrote:
>> >
>> > On Tue, 2019-09-17 at 13:25 -0700, David Ho wrote:
>> > > On Tue, Sep 17, 2019 at 12:07 PM Steve deRosier 
>> > > wrote:
>> > > > I will tell you I did go look and you don't have sufficient and
>> > > > useful
>> > > > information for us to help you. We need to know the wifi chipset
>> > > > you're using, the drivers involved, what network subsystems you're
>> > > > using, the methodology of your connection, and the kernel logs
>> > > > themselves would all be helpful.
>> > > >
>> > >
>> > > Hi Steve, pls let me know if you need anything else, David.
>> >
>> > If you're able to get the wpa_supplicant logs, that would be useful as
>> > well.
>> >
>> > sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
>> > /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
>> > string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true
>> >
>> > sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
>> > /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
>> > string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump"
>> >
>> > will start spewing out tons of information to wherever the supplicant
>> > sends log information on Ubuntu (systemd, syslog, etc).
>> >
>> > Dan
>> >
>> > > High level: Google Starbucks Wifi connection, Unencrypted AP (see AP
>> > > info below)
>> > > Connection method: NetworkManager, wpa_applicant (see exerpt from
>> > > /var/log/syslog below)
>> > >(see also iw event -f below)
>> > > Linux kernel: 5.0.0-27
>> > > Network subsystem: mac80211, cfg80211 (not sure)
>> > > Wifi chipset: RTL8822BE 802.11a/b/g/n/ac (see below)
>> > > Kernel driver in use: rtw_pci (see below)
>> > > Kernel modules: rtwpci, r8822be (see below)
>> > > Kernel log: see /var/log/kern.log exerpt below
>> > >
>> > > Problem detail
>> > > --
>> > >
>> > > I had trouble connecting my Ubuntu 18.04.3 LTS laptop to one specific
>> > > Starbucks location in my neighborhood, (Note that it works for 2/3
>> > > Starbucks and another public wifi location so this is an outlier;
>> > > However, I have been coming to this Starbucks at least 30 times in
>> > > the
>> > > past and it worked 100% for my Windows laptop and Andriod phone, and
>> > > I
>> > > have never seen customers with iPhones/MacBooks complaining, thus it
>> > > is being handled routinely by other major OS's)
>> > >
>> > > I have been tracking down this problem for three days and I believe I
>> > > have a good handle on what the problem may be.
>> > >
>> > > The event log below shows that after successfully authenticated,
>> > > association timed-out after 3 tries (seen in the kernel log in
>> > > /var/log/syslog). The next attempt 

Re: Linux wireless times out at Google Starbucks location

[David Ho]

Hi Steve, Dan,

I have scouted the neighborhood (San Diego, CA) and visited 6
Starbucks.  I found another one with the same issue, so 2/6.  This
appears to be a systemic issue (Not one-off).

I'm wondering if there is anything that you believe I can try at this
point.  There is nothing unusual about these stores.  Everyone is
happily connected on their Macs, and Windows notebooks.

Can you offer any advice or point me to an expert who can help?

Regards,
David


On Tue, Sep 17, 2019 at 2:01 PM Dan Williams  wrote:
>
> On Tue, 2019-09-17 at 13:25 -0700, David Ho wrote:
> > On Tue, Sep 17, 2019 at 12:07 PM Steve deRosier 
> > wrote:
> > > I will tell you I did go look and you don't have sufficient and
> > > useful
> > > information for us to help you. We need to know the wifi chipset
> > > you're using, the drivers involved, what network subsystems you're
> > > using, the methodology of your connection, and the kernel logs
> > > themselves would all be helpful.
> > >
> >
> > Hi Steve, pls let me know if you need anything else, David.
>
> If you're able to get the wpa_supplicant logs, that would be useful as
> well.
>
> sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
> /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
> string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true
>
> sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
> /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
> string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump"
>
> will start spewing out tons of information to wherever the supplicant
> sends log information on Ubuntu (systemd, syslog, etc).
>
> Dan
>
> > High level: Google Starbucks Wifi connection, Unencrypted AP (see AP
> > info below)
> > Connection method: NetworkManager, wpa_applicant (see exerpt from
> > /var/log/syslog below)
> >(see also iw event -f below)
> > Linux kernel: 5.0.0-27
> > Network subsystem: mac80211, cfg80211 (not sure)
> > Wifi chipset: RTL8822BE 802.11a/b/g/n/ac (see below)
> > Kernel driver in use: rtw_pci (see below)
> > Kernel modules: rtwpci, r8822be (see below)
> > Kernel log: see /var/log/kern.log exerpt below
> >
> > Problem detail
> > --
> >
> > I had trouble connecting my Ubuntu 18.04.3 LTS laptop to one specific
> > Starbucks location in my neighborhood, (Note that it works for 2/3
> > Starbucks and another public wifi location so this is an outlier;
> > However, I have been coming to this Starbucks at least 30 times in
> > the
> > past and it worked 100% for my Windows laptop and Andriod phone, and
> > I
> > have never seen customers with iPhones/MacBooks complaining, thus it
> > is being handled routinely by other major OS's)
> >
> > I have been tracking down this problem for three days and I believe I
> > have a good handle on what the problem may be.
> >
> > The event log below shows that after successfully authenticated,
> > association timed-out after 3 tries (seen in the kernel log in
> > /var/log/syslog). The next attempt to associate with the AP was
> > denied
> > because the WTA (my laptop) has been associated according to the AP.
> > Thus I believe the client timed out before the association response
> > from the AP reaches the WTA.
> >
> > I looked over the Linux wireless user's doc, but I didn't find a way
> > to tweak the configuration to test my hypothesis. Perhaps the
> > wireless
> > subsystem folks can shed some lights on this problem to help with
> > this?
> >
> > davidkwho@mumble15:~$ iw event -f
> > wlo1 (phy #0): scan started
> > wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
> > 2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
> > 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
> > 5805 5825, ""
> > wlo1 (phy #0): scan started
> > wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
> > 2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
> > 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
> > 5805 5825, "Google Starbucks" ""
> > wlo1: new station 24:de:c6:cb:2a:d8
> > wlo1 (phy #0): auth 24:de:c6:cb:2a:d8 -> 48:5f:99:bc:ab:b9 status: 0:
> > Successful [frame: b0 00 3c 00 48 5f 99 bc ab b9 24 de c6 cb 2a d8 24
> > de c6 cb 2a d8 10 c5 00 00 02 00 00 00]
> > wlo1: del station 24:de:c6:cb:2a:d8
> > wlo1 (phy #0): asso

Re: Linux wireless times out at Google Starbucks location

[David Ho]

7
 width: 64 bits
 clock: 33MHz
 capabilities: pciexpress msi pm vga_controller bus_master
cap_list rom
 configuration: driver=i915 latency=0
 resources: irq:128 memory:b000-b0ff
memory:a000-afff ioport:5000(size=64) memory:c-d
*-generic:0
 description: Signal processing controller
 product: Xeon E3-1200 v5/E3-1500 v5/6th Gen Core
Processor Thermal Subsystem
 vendor: Intel Corporation
 physical id: 4
 bus info: pci@:00:04.0
 version: 08
 width: 64 bits
 clock: 33MHz
 capabilities: msi pm cap_list
 configuration: driver=proc_thermal latency=0
 resources: irq:16 memory:b122-b1227fff
*-generic:1 UNCLAIMED
 description: System peripheral
 product: Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen
Core Processor Gaussian Mixture Model
 vendor: Intel Corporation
 physical id: 8
 bus info: pci@:00:08.0
 version: 00
 width: 64 bits
 clock: 33MHz
 capabilities: msi pm bus_master cap_list
 configuration: latency=0
 resources: memory:b1232000-b1232fff
*-usb
 description: USB controller
 product: Sunrise Point-LP USB 3.0 xHCI Controller
 vendor: Intel Corporation
 physical id: 14
 bus info: pci@:00:14.0
 version: 21
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi xhci bus_master cap_list
 configuration: driver=xhci_hcd latency=0
 resources: irq:124 memory:b121-b121
   *-usbhost:0
product: xHCI Host Controller
vendor: Linux 5.0.0-27-generic xhci-hcd
physical id: 0
bus info: usb@1
logical name: usb1
version: 5.00
capabilities: usb-2.00
configuration: driver=hub slots=12 speed=480Mbit/s
  *-usb:0
   description: USB hub
   product: USB 2.0 Hub
   vendor: Terminus Technology Inc.
   physical id: 1
   bus info: usb@1:1
   version: 1.11
   capabilities: usb-2.00
   configuration: driver=hub maxpower=100mA slots=4
speed=480Mbit/s
 *-usb
  description: Keyboard
  product: USB Receiver
  vendor: Logitech
  physical id: 2
  bus info: usb@1:1.2
  version: 12.01
  capabilities: usb-2.00
  configuration: driver=usbhid maxpower=98mA speed=12Mbit/s
  *-usb:1
   description: Keyboard
   product: USB Receiver
   vendor: Logitech
   physical id: 2
   bus info: usb@1:2
   version: 12.01
   capabilities: usb-2.00
   configuration: driver=usbhid maxpower=98mA speed=12Mbit/s
  *-usb:2
   description: Video
   product: HP TrueVision HD Camera
   vendor: SunplusIT Inc
   physical id: 5
   bus info: usb@1:5
   version: 0.02
   capabilities: usb-2.00
   configuration: driver=uvcvideo maxpower=500mA speed=480Mbit/s
  *-usb:3
   description: Bluetooth wireless interface
   product: Bluetooth Radio
   vendor: Realtek
   physical id: 6
   bus info: usb@1:6
   version: 1.10
   serial: 00e04c01
   capabilities: bluetooth usb-1.10
   configuration: driver=btusb maxpower=500mA speed=12Mbit/s
   *-usbhost:1
product: xHCI Host Controller
vendor: Linux 5.0.0-27-generic xhci-hcd
physical id: 1
bus info: usb@2
logical name: usb2
version: 5.00
capabilities: usb-3.00
configuration: driver=hub slots=6 speed=5000Mbit/s
*-generic:2
 description: Signal processing controller
 product: Sunrise Point-LP Thermal subsystem
 vendor: Intel Corporation
 physical id: 14.2
 bus info: pci@:00:14.2
 version: 21
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi bus_master cap_list
 configuration: driver=intel_pch_thermal latency=0
 resources: irq:18 memory:b1233000-b1233fff
*-communication

Re: Linux wireless times out at Google Starbucks location

[Krishna Chaitanya]

On Wed, Sep 18, 2019 at 6:22 AM David Ho  wrote:
>
> On Tue, Sep 17, 2019 at 2:01 PM Dan Williams  wrote:
> >
> > If you're able to get the wpa_supplicant logs, that would be useful as
> > well.
> >
>
> I captured 2 minutes of log in /var/log/syslog, based on my crude
> judgment of where the connection request began.
>
> I appreciate if someone can update me on this issue; I hope my effort
> is not going to waste (I'm just an ML researcher trying to make Ubuntu
> work at my favorite coffee shop =)
Is this a new issue probably after some update? The only thing we can
see from the
kernel logs are that Auth/Assoc are getting timed-out, no info as to why?

You can probably try disabling the powersave using below command or
using `iw` utils.
sudo sed -i "s/wifi.powersave = 3/wifi.powersave = 2/g"
/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

Re: Linux wireless times out at Google Starbucks location

[David Ho]

On Tue, Sep 17, 2019 at 2:01 PM Dan Williams  wrote:
>
> If you're able to get the wpa_supplicant logs, that would be useful as
> well.
>

I captured 2 minutes of log in /var/log/syslog, based on my crude
judgment of where the connection request began.

I appreciate if someone can update me on this issue; I hope my effort
is not going to waste (I'm just an ML researcher trying to make Ubuntu
work at my favorite coffee shop =)

Thanks, David

Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: Already scanning -
Reschedule the incoming scan req
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: Setting scan
request: 1.00 sec
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: RTM_NEWLINK: ifi_index=3
ifname=wlo1 wext ifi_family=0 ifi_flags=0x1003 ([UP])
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: nl80211: Event message available
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: nl80211: Drv Event 34
(NL80211_CMD_NEW_SCAN_RESULTS) received for wlo1
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: nl80211: New scan
results available
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: nl80211: Scan probed for SSID ''
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: nl80211: Scan included
frequencies: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462
2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540
5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785 5805 5825
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: Event SCAN_RESULTS
(3) received
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: Scan completed in
3.488974 seconds
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: nl80211: Received scan
results (15 BSSes)
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Start scan
result update 7
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Add new id 43
BSSID 9c:3d:cf:16:4c:1f SSID 'Nova nails' freq 2412
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus: Register BSS
object '/fi/w1/wpa_supplicant1/Interfaces/9/BSSs/43'
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Add new id 44
BSSID 38:2c:4a:5d:32:90 SSID 'Best_2-4' freq 2437
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus: Register BSS
object '/fi/w1/wpa_supplicant1/Interfaces/9/BSSs/44'
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Add new id 45
BSSID 8a:15:04:3d:a6:d3 SSID
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' freq 2457
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus: Register BSS
object '/fi/w1/wpa_supplicant1/Interfaces/9/BSSs/45'
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Add new id 46
BSSID 6c:ca:08:0e:c9:90 SSID 'ATT6N5A5d2' freq 2412
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus: Register BSS
object '/fi/w1/wpa_supplicant1/Interfaces/9/BSSs/46'
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: BSS: 60:fe:20:7d:fd:46
changed freq 2412 --> 2437
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Remove id 36
BSSID f8:f5:32:35:cb:80 SSID 'VTA' due to no match in scan
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus: Unregister BSS
object '/fi/w1/wpa_supplicant1/Interfaces/9/BSSs/36'
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Remove id 8
BSSID 10:93:97:58:5c:b0 SSID 'ATTpdSDEa2' due to no match in scan
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus: Unregister BSS
object '/fi/w1/wpa_supplicant1/Interfaces/9/BSSs/8'
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: BSS: Remove id 10
BSSID 10:93:97:4f:c0:33 SSID '' due to no match in scan
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus: Unregister BSS
object '/fi/w1/wpa_supplicant1/Interfaces/9/BSSs/10'
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: BSS: last_scan_res_used=15/32
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: Scan-only results received
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: WPS: Unsupported
attribute type 0x1058 len=24
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: message repeated 5
times: [ WPS: Unsupported attribute type 0x1058 len=24]
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1: Radio work
'scan'@0x55b76d514430 done in 3.988132 seconds
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: wlo1:
radio_work_free('scan'@0x55b76d514430: num_active_works --> 0
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus:
flush_object_timeout_handler: Timeout - sending changed properties of
object /fi/w1/wpa_supplicant1/Interfaces/9
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus:
flush_object_timeout_handler: Timeout - sending changed properties of
object /fi/w1/wpa_supplicant1/Interfaces/9/BSSs/0
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus:
flush_object_timeout_handler: Timeout - sending changed properties of
object /fi/w1/wpa_supplicant1/Interfaces/9/BSSs/1
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus:
flush_object_timeout_handler: Timeout - sending changed properties of
object /fi/w1/wpa_supplicant1/Interfaces/9/BSSs/6
Sep 17 16:40:53 mumble15 wpa_supplicant[892]: dbus:
flush_object_timeout_handler: Timeout - sending changed properties of
object /fi/w1/wpa_supplican

Re: Linux wireless times out at Google Starbucks location

[Dan Williams]

On Tue, 2019-09-17 at 13:25 -0700, David Ho wrote:
> On Tue, Sep 17, 2019 at 12:07 PM Steve deRosier 
> wrote:
> > I will tell you I did go look and you don't have sufficient and
> > useful
> > information for us to help you. We need to know the wifi chipset
> > you're using, the drivers involved, what network subsystems you're
> > using, the methodology of your connection, and the kernel logs
> > themselves would all be helpful.
> > 
> 
> Hi Steve, pls let me know if you need anything else, David.

If you're able to get the wpa_supplicant logs, that would be useful as
well.

sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
/fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true

sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
/fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump"

will start spewing out tons of information to wherever the supplicant
sends log information on Ubuntu (systemd, syslog, etc).

Dan

> High level: Google Starbucks Wifi connection, Unencrypted AP (see AP
> info below)
> Connection method: NetworkManager, wpa_applicant (see exerpt from
> /var/log/syslog below)
>(see also iw event -f below)
> Linux kernel: 5.0.0-27
> Network subsystem: mac80211, cfg80211 (not sure)
> Wifi chipset: RTL8822BE 802.11a/b/g/n/ac (see below)
> Kernel driver in use: rtw_pci (see below)
> Kernel modules: rtwpci, r8822be (see below)
> Kernel log: see /var/log/kern.log exerpt below
> 
> Problem detail
> --
> 
> I had trouble connecting my Ubuntu 18.04.3 LTS laptop to one specific
> Starbucks location in my neighborhood, (Note that it works for 2/3
> Starbucks and another public wifi location so this is an outlier;
> However, I have been coming to this Starbucks at least 30 times in
> the
> past and it worked 100% for my Windows laptop and Andriod phone, and
> I
> have never seen customers with iPhones/MacBooks complaining, thus it
> is being handled routinely by other major OS's)
> 
> I have been tracking down this problem for three days and I believe I
> have a good handle on what the problem may be.
> 
> The event log below shows that after successfully authenticated,
> association timed-out after 3 tries (seen in the kernel log in
> /var/log/syslog). The next attempt to associate with the AP was
> denied
> because the WTA (my laptop) has been associated according to the AP.
> Thus I believe the client timed out before the association response
> from the AP reaches the WTA.
> 
> I looked over the Linux wireless user's doc, but I didn't find a way
> to tweak the configuration to test my hypothesis. Perhaps the
> wireless
> subsystem folks can shed some lights on this problem to help with
> this?
> 
> davidkwho@mumble15:~$ iw event -f
> wlo1 (phy #0): scan started
> wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
> 2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
> 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
> 5805 5825, ""
> wlo1 (phy #0): scan started
> wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
> 2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
> 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
> 5805 5825, "Google Starbucks" ""
> wlo1: new station 24:de:c6:cb:2a:d8
> wlo1 (phy #0): auth 24:de:c6:cb:2a:d8 -> 48:5f:99:bc:ab:b9 status: 0:
> Successful [frame: b0 00 3c 00 48 5f 99 bc ab b9 24 de c6 cb 2a d8 24
> de c6 cb 2a d8 10 c5 00 00 02 00 00 00]
> wlo1: del station 24:de:c6:cb:2a:d8
> wlo1 (phy #0): assoc: timed out
> wlo1 (phy #0): scan started
> wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
> 2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
> 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
> 5805 5825, "Google Starbucks" ""
> wlo1: new station 24:de:c6:cb:2a:d0
> wlo1: del station 24:de:c6:cb:2a:d0
> wlo1 (phy #0): auth 24:de:c6:cb:2a:d0 -> 48:5f:99:bc:ab:b9 status:
> 17:
> Association denied because AP is unable to handle additional
> associated STA [frame: b0 00 3c 00 48 5f 99 bc ab b9 24 de c6 cb 2a
> d0
> 24 de c6 cb 2a d0 20 0b 00 00 02 00 11 00]
> wlo1 (phy #0): scan started
> wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
> 2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
> 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
> 580

Re: Linux wireless times out at Google Starbucks location

[David Ho]

On Tue, Sep 17, 2019 at 12:07 PM Steve deRosier  wrote:
>
> I will tell you I did go look and you don't have sufficient and useful
> information for us to help you. We need to know the wifi chipset
> you're using, the drivers involved, what network subsystems you're
> using, the methodology of your connection, and the kernel logs
> themselves would all be helpful.
>

Hi Steve, pls let me know if you need anything else, David.

High level: Google Starbucks Wifi connection, Unencrypted AP (see AP info below)
Connection method: NetworkManager, wpa_applicant (see exerpt from
/var/log/syslog below)
   (see also iw event -f below)
Linux kernel: 5.0.0-27
Network subsystem: mac80211, cfg80211 (not sure)
Wifi chipset: RTL8822BE 802.11a/b/g/n/ac (see below)
Kernel driver in use: rtw_pci (see below)
Kernel modules: rtwpci, r8822be (see below)
Kernel log: see /var/log/kern.log exerpt below

Problem detail
--

I had trouble connecting my Ubuntu 18.04.3 LTS laptop to one specific
Starbucks location in my neighborhood, (Note that it works for 2/3
Starbucks and another public wifi location so this is an outlier;
However, I have been coming to this Starbucks at least 30 times in the
past and it worked 100% for my Windows laptop and Andriod phone, and I
have never seen customers with iPhones/MacBooks complaining, thus it
is being handled routinely by other major OS's)

I have been tracking down this problem for three days and I believe I
have a good handle on what the problem may be.

The event log below shows that after successfully authenticated,
association timed-out after 3 tries (seen in the kernel log in
/var/log/syslog). The next attempt to associate with the AP was denied
because the WTA (my laptop) has been associated according to the AP.
Thus I believe the client timed out before the association response
from the AP reaches the WTA.

I looked over the Linux wireless user's doc, but I didn't find a way
to tweak the configuration to test my hypothesis. Perhaps the wireless
subsystem folks can shed some lights on this problem to help with
this?

davidkwho@mumble15:~$ iw event -f
wlo1 (phy #0): scan started
wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
5805 5825, ""
wlo1 (phy #0): scan started
wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
5805 5825, "Google Starbucks" ""
wlo1: new station 24:de:c6:cb:2a:d8
wlo1 (phy #0): auth 24:de:c6:cb:2a:d8 -> 48:5f:99:bc:ab:b9 status: 0:
Successful [frame: b0 00 3c 00 48 5f 99 bc ab b9 24 de c6 cb 2a d8 24
de c6 cb 2a d8 10 c5 00 00 02 00 00 00]
wlo1: del station 24:de:c6:cb:2a:d8
wlo1 (phy #0): assoc: timed out
wlo1 (phy #0): scan started
wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
5805 5825, "Google Starbucks" ""
wlo1: new station 24:de:c6:cb:2a:d0
wlo1: del station 24:de:c6:cb:2a:d0
wlo1 (phy #0): auth 24:de:c6:cb:2a:d0 -> 48:5f:99:bc:ab:b9 status: 17:
Association denied because AP is unable to handle additional
associated STA [frame: b0 00 3c 00 48 5f 99 bc ab b9 24 de c6 cb 2a d0
24 de c6 cb 2a d0 20 0b 00 00 02 00 11 00]
wlo1 (phy #0): scan started
wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
5805 5825, ""
wlo1 (phy #0): scan started
wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
5805 5825, ""
wlo1 (phy #0): scan started
wlo1 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447
2452 2457 2462 2467 2472 2484 5180 5200 5220 5240 5260 5280 5300 5320
5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785
5805 5825, ""

Wireless AP info
$ iw dev wlo1 scan
BSS 24:de:c6:cb:2a:d8(on wlo1)
TSF: 2927364433352 usec (33d, 21:09:24)
freq: 5765
beacon interval: 100 TUs
capability: ESS SpectrumMgmt ShortSlotTime (0x0501)
signal: -41.00 dBm
last seen: 320 ms ago
Information elements from Probe Response frame:
SSID: Google Starbucks
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
DS Parameter set: channel 153
Country: US Environment: Indoor/Outdoor
Channels [36 - 64] @ 36 dBm
Channels [100 - 140] @ 30 dBm
Channels [149 - 165] @ 36 dBm
Power constraint: 0 dB
TPC report: TX power: 23 

Re: Linux wireless times out at Google Starbucks location

[Steve deRosier]

On Tue, Sep 17, 2019 at 11:53 AM David Ho  wrote:
>
> Hi there,
>
> I found this issue with my Ubuntu 18.04.3 LTS setup at a Starbucks
> location I regularly visit.  I have tracked down the problem and at
> this point, I think I will need the wireless subsystem folks' input
> before I can proceed.  Can you folks help me with this?  See my Reddit
> post below for details.
>
> https://www.reddit.com/r/Ubuntu/comments/d5l79f/linux_wireless_times_out_at_google_starbucks/
>

Hi David,

If you have an issue to report and want help with, please put the
details in your email instead of pointing to external posts. This way
it can be discussed here and you enable maintainers to help you. If
I'm not mistaken, there's a very clear process and location to get
help as mentioned on the wiki:
https://wireless.wiki.kernel.org/en/users/support

I will tell you I did go look and you don't have sufficient and useful
information for us to help you. We need to know the wifi chipset
you're using, the drivers involved, what network subsystems you're
using, the methodology of your connection, and the kernel logs
themselves would all be helpful.

Thanks for your cooperation.

- Steve

Linux wireless times out at Google Starbucks location

[David Ho]

Hi there,

I found this issue with my Ubuntu 18.04.3 LTS setup at a Starbucks
location I regularly visit.  I have tracked down the problem and at
this point, I think I will need the wireless subsystem folks' input
before I can proceed.  Can you folks help me with this?  See my Reddit
post below for details.

https://www.reddit.com/r/Ubuntu/comments/d5l79f/linux_wireless_times_out_at_google_starbucks/

Thanks very much,
David

[PATCH] wireless-regdb: Create entry for united European region

[Emil Petersky]

Create entry for united European region, as usage of frequency bands
is harmonized over EU and almost all CEPT countries as well.

All EU countries and almost all CEPT countries accepted decisions
2005/513/EC (5GHz RLAN, EN 301 893)
and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
 EU decision 2005/513/EC:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
 EU decision 2006/771/EC:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
Harmonized CEPT countries:
https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
Such decision make sense to create united European region (EU) in regdb

United region for EU in regdb will enable much easier handling of proper
wlan parameters on embedded devices sold across the Europe.

Following 40 EU/CEPT countries are fully harmonized:
AD    Andorra
AL     Albania
AT     Austria
BA     Bosnia and Herzegovina
BE     Belgium
BG     Bulgaria
CH     Switzerland
CY     Cyprus
CZ     Czechia
DE     Germany
DK     Denmark
EE     Estonia
ES     Spain
FI     Finland
FR     France
GB     United Kingdom of Great Britain and Northern Ireland
GR     Greece
HR     Croatia
HU     Hungary
IE     Ireland
IS     Iceland
IT     Italy
LI     Liechtenstein
LT     Lithuania
LU     Luxembourg
LV     Latvia
MC     Monaco
MD     Moldova
ME     Montenegro
MK     Macedonia
MT     Malta
NL     Netherlands
NO     Norway
PL     Poland
PT     Portugal
RO     Romania
RS     Serbia
SE     Sweden
SI     Slovenia
SK     Slovakia

Best regards,

Emil

-- 

Emil Petersky



StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Office: +43 1 667 2002 4679 Fax: +43 1 667 2002 4401
Mail to: emil.peter...@streamunlimited.com
Visit us: www.streamunlimited.com

Meet us at:
IFA - Berlin, 6-11 September, hall 1.2/booth 224
CEDIA - Denver, 12-14 September
Hong Kong Electronics show - Hong Kong, 13 - 16 October

From b0500d84ea0c247f71ecbed90d38ce68cd2af8b8 Mon Sep 17 00:00:00 2001
From: Emil Petersky 
Date: Tue, 17 Sep 2019 11:45:04 +0200
Subject: [PATCH] wireless-regdb: Create entry for united European region

Signed-off-by: Emil Petersky 

Create entry for united European region, as usage of frequency bands
is harmonized over EU and almost all CEPT countries as well.

All EU countries and almost all CEPT countries accepted decisions 2005/513/EC 
(5GHz RLAN, EN 301 893)
and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
 EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
 EU decision 2006/771/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
Harmonized CEPT countries: 
https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
Such decision make sense to create united European region (EU) in regdb

United region for EU in regdb will enable much easier handling of proper
wlan parameters on embedded devices sold across the Europe.
---
 db.txt | 13 +
 1 file changed, 13 insertions(+)

diff --git a/db.txt b/db.txt
index 30b9318..8964573 100644
--- a/db.txt
+++ b/db.txt
@@ -26,6 +26,19 @@ country 00:
# IEEE 802.11ad (60GHz), channels 1..3
(57240 - 63720 @ 2160), (0)
 
+# All EU countries and almost all CEPT countries accepted decisions 
2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+#  EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+#  EU decision 2006/771/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# Harmonized CEPT countries: 
https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
+country EU: DFS-ETSI
+   (2400 - 2483.5 @ 40), (100 mW)
+   (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+   # short range devices (ETSI EN 300 440-1)
+   (5725 - 5875 @ 80), (25 mW)
+
 # AD as part of CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
 # and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
 #  EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
-- 
2.23.0.windows.1

[PATCH] wireless-regdb: Harmonize ranges of CEPT countries (stand of July 2019)

[Emil Petersky]

This patch unites entries for CEPT countries according
https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
(CEPT ERC Recommendation70-03, Edition of June 2019) which lists all
CEPT countries, who has harmonized those standards.

The most important (definition) entries are:
  Table 1 / rows i and j (SRDs for 2.4 and 5GHz bands)
  Table 3 / row b (2.4 GHz band)
  Table 14 / rows e1, e2 and f (5GHz bands)

and Appendix 1 - National implementation
with sub-tables and rows representing implementation of above standards:
  ANNEX 1: NON-SPECIFIC SHORT RANGE DEVICES
    Annex i: 2400-2483.5 MHz
    Annex j: 5725-5875 MHz
  ANNEX 3: WIDEBAND DATA TRANSMISSION SYSTEMS
    Annex b: 2400-2483.5 MHz
  ANNEX A: INFORMATIVE ANNEX COVERING THE APPLICATIONS OPERATING UNDER
GENERAL AUTHORISATION...
    Annex e1: 5150-5350 MHz    ECC/DEC/(04)08
    Annex e2: 5470-5725 MHz    ECC/DEC/(04)08
    Annex f: 5875-5905 MHz    ECC/DEC/(08)01

-- 
Emil Petersky



StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Office: +43 1 667 2002 4679 Fax: +43 1 667 2002 4401
Mail to: emil.peter...@streamunlimited.com
Visit us: www.streamunlimited.com

Meet us at:
IFA - Berlin, 6-11 September, hall 1.2/booth 224
CEDIA - Denver, 12-14 September
Hong Kong Electronics show - Hong Kong, 13 - 16 October

From 954f4ac85682e51945d7d40f8e90b5c0329cb546 Mon Sep 17 00:00:00 2001
From: Emil Petersky 
Date: Tue, 17 Sep 2019 10:47:15 +0200
Subject: [PATCH] wireless-regdb: Harmonize ranges of CEPT countries (stand of
 July 2019)

This patch unites entries for CEPT countries according
https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
(CEPT ERC Recommendation70-03, Edition of June 2019) which lists all
CEPT countries, who has harmonized those standards.

The most important (definition) entries are:
  Table 1 / rows i and j (SRDs for 2.4 and 5GHz bands)
  Table 3 / row b (2.4 GHz band)
  Table 14 / rows e1, e2 and f (5GHz bands)

and Appendix 1 - National implementation
with sub-tables and rows representing implementation of above standards:
  ANNEX 1: NON-SPECIFIC SHORT RANGE DEVICES
Annex i: 2400-2483.5 MHz
Annex j: 5725-5875 MHz
  ANNEX 3: WIDEBAND DATA TRANSMISSION SYSTEMS
Annex b: 2400-2483.5 MHz
  ANNEX A: INFORMATIVE ANNEX COVERING THE APPLICATIONS OPERATING UNDER
GENERAL AUTHORISATION...
Annex e1: 5150-5350 MHzECC/DEC/(04)08
Annex e2: 5470-5725 MHzECC/DEC/(04)08
Annex f: 5875-5905 MHzECC/DEC/(08)01

Signed-off-by: Emil Petersky 
---
 db.txt | 155 +
 1 file changed, 122 insertions(+), 33 deletions(-)

diff --git a/db.txt b/db.txt
index b08935e..30b9318 100644
--- a/db.txt
+++ b/db.txt
@@ -26,12 +26,18 @@ country 00:
# IEEE 802.11ad (60GHz), channels 1..3
(57240 - 63720 @ 2160), (0)
 
-
-country AD:
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), wmmrule=ETSI
-   (5250 - 5330 @ 80), (20), DFS, wmmrule=ETSI
-   (5490 - 5710 @ 80), (27), DFS, wmmrule=ETSI
+# AD as part of CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+#  EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+#  EU decision 2006/771/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# Harmonized CEPT countries: 
https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
+country AD: DFS-ETSI
+   (2400 - 2483.5 @ 40), (100 mW)
+   (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+   # short range devices (ETSI EN 300 440-1)
+   (5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
@@ -56,11 +62,18 @@ country AI: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
 
+# AL as part of CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+#  EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+#  EU decision 2006/771/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# Harmonized CEPT countries (July 2019): 
https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
 country AL: DFS-ETSI
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20.00), AUTO-BW
-   (5250 - 5330 @ 80), (20.00), DFS, AUTO-BW
-   (5490 - 5710 @ 160), (27.00), DFS
+   (2400 - 2483.5 @ 40), (100 mW)
+   (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250

Re: [PATCH] wireless-regdb: Fix ranges of EU countries as they are harmonized since 2014...

[Emil Petersky]

Dear Seth,
here you are, hopefully now it will work as it should.
Best regards,
Emil

On 08/09/2019 01:56, Seth Forshee wrote:
> On Mon, Aug 05, 2019 at 04:19:16PM +0200, Emil Petersky wrote:
>> This patch unites entries for EU countries, as they have been harmonized
>> latest by July 2014...
>> EU decision 2005/513/EC:
>> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
>> EU decision 2006/771/EC:
>> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
>>
>> Signed-off-by: Emil Petersky 
> Thanks for this patch, and especially for all the references you
> provided. Sorry it's taken a while to get back -- I've been checking the
> changes against the links which took quite some time, and I have pretty
> limited time for reviewing these patches.
>
> Overall this looks good, however when I try to apply it I get an error
> that the patch is corrupt. Can you try resending?
>
> I also get warnings from git about trailing whitespace, and I've noted a
> couple other trivial whitespace issues below, if you wouldn't mind
> fixing those up before resending.
>
>> @@ -167,23 +185,30 @@ country BF: DFS-FCC
>>  #
>>  # Note: The transmit power limits in the 5250-5350 MHz and 5470-5725 MHz 
>> bands
>>  # can be raised by 3 dBm if TPC is enabled. Refer to BDS EN 301 893 for 
>> details.
>> +#
>> +# BG as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 
>> 893) 
>> +# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
>> +#  EU decision 2005/513/EC: 
>> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
>> +#  EU decision 2006/771/EC: 
>> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
>> +# BG: https://crc.bg/files/_en/Electronic_Communications_Revised_EN1.pdf
>> +# BG: acceptance of 2006/771/EC https://crc.bg/files/Pravila_06_12_2018.pdf
>> +
>>  country BG: DFS-ETSI
> This is the only place where you added a blank line between the comment
> and the country. Let's remove that for consistency.
>
>>  # Wideband data transmission systems (WDTS) in the 2.4GHz ISM band, ref:
>>  # I.22 of the List, BDS EN 300 328
>> -(2402 - 2482 @ 40), (20)
>> +(2400 - 2483.5 @ 40), (100 mW)
>>  # 5 GHz Radio Local Area Networks (RLANs), ref:
>>  # II.H01 of the List, BDS EN 301 893
>> -(5170 - 5250 @ 80), (23), AUTO-BW, wmmrule=ETSI
>> -(5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
>> +(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
>> +(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
>>  # II.H01 of the List, I.54 from the List, BDS EN 301 893
>> -(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
>> -# Short range devices (SRDs) in the 5725-5875 MHz frequency range, ref:
>> +(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
>> +# short range devices (ETSI EN 300 440-1)
>>  # I.43 of the List, BDS EN 300 440-2, BDS EN 300 440-1
>> -(5725 - 5875 @ 80), (14)
>> -# 60 GHz Multiple-Gigabit RLAN Systems, ref:
>> +(5725 - 5875 @ 80), (25 mW)
>> +# 60 GHz band channels 1-4 (ETSI EN 302 567)
>>  # II.H03 of the List, BDS EN 302 567-2
>> -(57000 - 66000 @ 2160), (40), NO-OUTDOOR
>> -
>> +(57000 - 66000 @ 2160), (40)
>>  country BH: DFS-JP
> You removed the blank line between the BG rules and BH here.
>
> Thanks,
> Seth


-- 
Emil Petersky



StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Office: +43 1 667 2002 4679 Fax: +43 1 667 2002 4401
Mail to: emil.peter...@streamunlimited.com
Visit us: www.streamunlimited.com

Meet us at:
IFA - Berlin, 6-11 September, hall 1.2/booth 224
CEDIA - Denver, 12-14 September
Hong Kong Electronics show - Hong Kong, 13 - 16 October

From 347a96cd9d28f89b42ed5bf9a902a3b11a95cb41 Mon Sep 17 00:00:00 2001
From: Emil Petersky 
Date: Tue, 17 Sep 2019 09:49:19 +0200
Subject: [PATCH] wireless-regdb: Fix ranges of EU countries as they are
 harmonized since 2014

This patch unites entries for EU countries, as they have been harmonized
latest by July 2014...

EU decision 2005/513/EC:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
EU decision 2006/771/EC:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611

Signed-off-by: Emil Petersky 
---
 db.txt | 578 +++--
 1 file changed, 381 insertions(+), 197 deletions(-)

diff -

Wireless-regdb: Update regulatory rules for Finland (FI) on 5GHz

[Olli Niemikorpi]

Hi,

Based on https://w.wol.ph/2015/08/28/maximum-wifi-transmission-power-country/
, maximum output power for 5Ghz is 30 dBm from channel 100 and above.
However, only 27 dBm is maximum in wireless-regdb. Could you please
fix it?

BR Olli Niemikorpi

Re: [PATCH] wireless-regdb: Fix ranges of EU countries as they are harmonized since 2014...

[Seth Forshee]

On Mon, Aug 05, 2019 at 04:19:16PM +0200, Emil Petersky wrote:
> This patch unites entries for EU countries, as they have been harmonized
> latest by July 2014...
> EU decision 2005/513/EC:
> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
> EU decision 2006/771/EC:
> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
> 
> Signed-off-by: Emil Petersky 

Thanks for this patch, and especially for all the references you
provided. Sorry it's taken a while to get back -- I've been checking the
changes against the links which took quite some time, and I have pretty
limited time for reviewing these patches.

Overall this looks good, however when I try to apply it I get an error
that the patch is corrupt. Can you try resending?

I also get warnings from git about trailing whitespace, and I've noted a
couple other trivial whitespace issues below, if you wouldn't mind
fixing those up before resending.

> @@ -167,23 +185,30 @@ country BF: DFS-FCC
>  #
>  # Note: The transmit power limits in the 5250-5350 MHz and 5470-5725 MHz 
> bands
>  # can be raised by 3 dBm if TPC is enabled. Refer to BDS EN 301 893 for 
> details.
> +#
> +# BG as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 
> 893) 
> +# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
> +#  EU decision 2005/513/EC: 
> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
> +#  EU decision 2006/771/EC: 
> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
> +# BG: https://crc.bg/files/_en/Electronic_Communications_Revised_EN1.pdf
> +# BG: acceptance of 2006/771/EC https://crc.bg/files/Pravila_06_12_2018.pdf
> +
>  country BG: DFS-ETSI

This is the only place where you added a blank line between the comment
and the country. Let's remove that for consistency.

>   # Wideband data transmission systems (WDTS) in the 2.4GHz ISM band, ref:
>   # I.22 of the List, BDS EN 300 328
> - (2402 - 2482 @ 40), (20)
> + (2400 - 2483.5 @ 40), (100 mW)
>   # 5 GHz Radio Local Area Networks (RLANs), ref:
>   # II.H01 of the List, BDS EN 301 893
> - (5170 - 5250 @ 80), (23), AUTO-BW, wmmrule=ETSI
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> + (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
> + (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
>   # II.H01 of the List, I.54 from the List, BDS EN 301 893
> - (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
> - # Short range devices (SRDs) in the 5725-5875 MHz frequency range, ref:
> + (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
> + # short range devices (ETSI EN 300 440-1)
>   # I.43 of the List, BDS EN 300 440-2, BDS EN 300 440-1
> - (5725 - 5875 @ 80), (14)
> - # 60 GHz Multiple-Gigabit RLAN Systems, ref:
> + (5725 - 5875 @ 80), (25 mW)
> + # 60 GHz band channels 1-4 (ETSI EN 302 567)
>   # II.H03 of the List, BDS EN 302 567-2
> - (57000 - 66000 @ 2160), (40), NO-OUTDOOR
> -
> + (57000 - 66000 @ 2160), (40)
>  country BH: DFS-JP

You removed the blank line between the BG rules and BH here.

Thanks,
Seth

Re: [linuxwifi] Issue with Intel(R) Wireless-AC 9260 in wifi direct in 5GHz

[Luciano Coelho]

Hi,

Sorry for the delay.  This bug was already reported[1] and fixed[2]. 
But it seems that you are unfortunately using an old kernel (v4.18)
that hasn't been maintained for about 10 months... Please update your
kernel or try to cherry-pick the patch on top of your tree.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=201105
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=82715ac71e6b94a2c2136

HTH.

--
Cheers,
Luca.


On Wed, 2019-09-04 at 09:20 +0200, Equipe Soft wrote:
> Hello, do you have any news about the issue?
> 
> Le mer. 28 août 2019 à 19:17, Equipe Soft
>  a écrit :
> > Hello,
> > I'm trying to set up a wifi direct group between my AC9260 wifi board and a 
> > android tablet supporting WifiDirect.
> > 
> > I tried several configurations and I faced some issues.
> > Here follow the testing sequence. All the following command are sent 
> > through wpa_cli:
> > 
> > > p2p_find
> > P2P-DEVICE-FOUND f2:ee:10:c2:ce:68 p2p_dev_addr=f2:ee:10:c2:ce:68 
> > pri_dev_type=10-0050F204-5 name='[Tablet] Galaxy Tab S3' 
> > config_methods=0x188 dev_capab=0x25 group_capab=0x0 vendor_elems=1 new=1
> > 
> > > p2p_connect f2:ee:10:c2:ce:68 pin 1234 go_intent=1
> > 74493685
> > 
> > PIN is set on the tablet then, on my terminal I see:
> > 
> > P2P-GO-NEG-SUCCESS role=GO freq=5785 ht40=0 peer_dev=f2:ee:10:c2:ce:68 
> > peer_iface=f2:ee:10:c2:4e:68 wps_method=Display
> > P2P-GROUP-FORMATION-FAILURE
> > P2P-GROUP-REMOVED p2p-wlan0-0 GO reason=FORMATION_FAILED
> > 
> > dmesg :
> > 
> > [ 1875.593069] IPv6: ADDRCONF(NETDEV_UP): p2p-wlan0-0: link is not ready
> > [ 1875.659199] iwlwifi :01:00.0: Microcode SW error detected.  
> > Restarting 0x200.
> > [ 1875.667246] iwlwifi :01:00.0: Start IWL Error Log Dump:
> > [ 1875.672851] iwlwifi :01:00.0: Status: 0x0100, count: 6
> > [ 1875.678718] iwlwifi :01:00.0: Loaded firmware version: 38.755cfdd8.0
> > [ 1875.685466] iwlwifi :01:00.0: 0x14FC | ADVANCED_SYSASSERT
> > [ 1875.692498] iwlwifi :01:00.0: 0x00A0A200 | trm_hw_status0
> > [ 1875.698270] iwlwifi :01:00.0: 0x | trm_hw_status1
> > [ 1875.704048] iwlwifi :01:00.0: 0x00454EF6 | branchlink2
> > [ 1875.709561] iwlwifi :01:00.0: 0x0045E90E | interruptlink1
> > [ 1875.715330] iwlwifi :01:00.0: 0x | interruptlink2
> > [ 1875.721096] iwlwifi :01:00.0: 0x9D00 | data1
> > [ 1875.726084] iwlwifi :01:00.0: 0x0741 | data2
> > [ 1875.731070] iwlwifi :01:00.0: 0x00090010 | data3
> > [ 1875.736076] iwlwifi :01:00.0: 0x | beacon time
> > [ 1875.741589] iwlwifi :01:00.0: 0x6F091C80 | tsf low
> > [ 1875.746757] iwlwifi :01:00.0: 0x | tsf hi
> > [ 1875.751833] iwlwifi :01:00.0: 0x | time gp1
> > [ 1875.757081] iwlwifi :01:00.0: 0x6F091C81 | time gp2
> > [ 1875.762325] iwlwifi :01:00.0: 0x0001 | uCode revision type
> > [ 1875.768529] iwlwifi :01:00.0: 0x0026 | uCode version major
> > [ 1875.774731] iwlwifi :01:00.0: 0x755CFDD8 | uCode version minor
> > [ 1875.780934] iwlwifi :01:00.0: 0x0321 | hw version
> > [ 1875.786352] iwlwifi :01:00.0: 0x00C89004 | board version
> > [ 1875.792044] iwlwifi :01:00.0: 0x801BF402 | hcmd
> > [ 1875.796951] iwlwifi :01:00.0: 0x24022000 | isr0
> > [ 1875.801853] iwlwifi :01:00.0: 0x0100 | isr1
> > [ 1875.806751] iwlwifi :01:00.0: 0x08301802 | isr2
> > [ 1875.811653] iwlwifi :01:00.0: 0x00415CC0 | isr3
> > [ 1875.816559] iwlwifi :01:00.0: 0x | isr4
> > [ 1875.821462] iwlwifi :01:00.0: 0x000501D1 | last cmd Id
> > [ 1875.826975] iwlwifi :01:00.0: 0x | wait_event
> > [ 1875.832399] iwlwifi :01:00.0: 0x00D0 | l2p_control
> > [ 1875.837928] iwlwifi :01:00.0: 0x00018014 | l2p_duration
> > [ 1875.843527] iwlwifi :01:00.0: 0x003F | l2p_mhvalid
> > [ 1875.849040] iwlwifi :01:00.0: 0x | l2p_addr_match
> > [ 1875.854811] iwlwifi :01:00.0: 0x000D | lmpm_pmg_sel
> > [ 1875.860412] iwlwifi :01:00.0: 0x04071046 | timestamp
> > [ 1875.865758] iwlwifi :01:00.0: 0xC0E4 | flow_handler
> > [ 1875.871405] iwlwifi :01:00.0: Start IWL Error Log Dump:
> > [ 1875.877037] iwlwifi :01:00.0: Status: 0x0100, count: 7
> > [ 1875.882889] iwlwifi :01:00.0: 0x0070 | ADVANCED_SYSASSERT
> > [ 1875.889020] iwlwifi :01:00.0: 0x | umac branchlink1
> > [ 1875.894959] iwlwifi :01:00.0: 0xC0087CB8 | umac branchlink2
> > [ 1875.900904] iwlwifi :01:00.0: 0xC0084264 | umac interruptlink1
> > [ 1875.907134] iwlwifi :01:00.0: 0xC00847C8 | umac interruptlink2
> > [ 1875.913344] iwlwifi :01:00.0: 0x0800 | umac data1
> > [ 1875.918764] iwlwifi :01:00.0: 0xC00847C8 | umac data2
> > [ 1875.924184] iwlwifi :01:00.0: 0xDEADBEEF | umac data3
> > [ 1875.929606] iwlwifi :01:00.0: 0x0026 | umac major
> > [ 1875.935026] iwlwifi :01:00.0: 0x755CFDD8 | umac minor
> > [ 1875.940448] iwlwifi :01:0

Re: Issue with Intel(R) Wireless-AC 9260 in wifi direct in 5GHz

[Equipe Soft]

Hello, do you have any news about the issue?

Le mer. 28 août 2019 à 19:17, Equipe Soft
 a écrit :
>
> Hello,
> I'm trying to set up a wifi direct group between my AC9260 wifi board and a 
> android tablet supporting WifiDirect.
>
> I tried several configurations and I faced some issues.
> Here follow the testing sequence. All the following command are sent through 
> wpa_cli:
>
> > p2p_find
> P2P-DEVICE-FOUND f2:ee:10:c2:ce:68 p2p_dev_addr=f2:ee:10:c2:ce:68 
> pri_dev_type=10-0050F204-5 name='[Tablet] Galaxy Tab S3' config_methods=0x188 
> dev_capab=0x25 group_capab=0x0 vendor_elems=1 new=1
>
> >p2p_connect f2:ee:10:c2:ce:68 pin 1234 go_intent=1
> 74493685
>
> PIN is set on the tablet then, on my terminal I see:
>
> P2P-GO-NEG-SUCCESS role=GO freq=5785 ht40=0 peer_dev=f2:ee:10:c2:ce:68 
> peer_iface=f2:ee:10:c2:4e:68 wps_method=Display
> P2P-GROUP-FORMATION-FAILURE
> P2P-GROUP-REMOVED p2p-wlan0-0 GO reason=FORMATION_FAILED
>
> dmesg :
>
> [ 1875.593069] IPv6: ADDRCONF(NETDEV_UP): p2p-wlan0-0: link is not ready
> [ 1875.659199] iwlwifi :01:00.0: Microcode SW error detected.  Restarting 
> 0x200.
> [ 1875.667246] iwlwifi :01:00.0: Start IWL Error Log Dump:
> [ 1875.672851] iwlwifi :01:00.0: Status: 0x0100, count: 6
> [ 1875.678718] iwlwifi :01:00.0: Loaded firmware version: 38.755cfdd8.0
> [ 1875.685466] iwlwifi :01:00.0: 0x14FC | ADVANCED_SYSASSERT
> [ 1875.692498] iwlwifi :01:00.0: 0x00A0A200 | trm_hw_status0
> [ 1875.698270] iwlwifi :01:00.0: 0x | trm_hw_status1
> [ 1875.704048] iwlwifi :01:00.0: 0x00454EF6 | branchlink2
> [ 1875.709561] iwlwifi :01:00.0: 0x0045E90E | interruptlink1
> [ 1875.715330] iwlwifi :01:00.0: 0x | interruptlink2
> [ 1875.721096] iwlwifi :01:00.0: 0x9D00 | data1
> [ 1875.726084] iwlwifi :01:00.0: 0x0741 | data2
> [ 1875.731070] iwlwifi :01:00.0: 0x00090010 | data3
> [ 1875.736076] iwlwifi :01:00.0: 0x | beacon time
> [ 1875.741589] iwlwifi :01:00.0: 0x6F091C80 | tsf low
> [ 1875.746757] iwlwifi :01:00.0: 0x | tsf hi
> [ 1875.751833] iwlwifi :01:00.0: 0x | time gp1
> [ 1875.757081] iwlwifi :01:00.0: 0x6F091C81 | time gp2
> [ 1875.762325] iwlwifi :01:00.0: 0x0001 | uCode revision type
> [ 1875.768529] iwlwifi :01:00.0: 0x0026 | uCode version major
> [ 1875.774731] iwlwifi :01:00.0: 0x755CFDD8 | uCode version minor
> [ 1875.780934] iwlwifi :01:00.0: 0x0321 | hw version
> [ 1875.786352] iwlwifi :01:00.0: 0x00C89004 | board version
> [ 1875.792044] iwlwifi :01:00.0: 0x801BF402 | hcmd
> [ 1875.796951] iwlwifi :01:00.0: 0x24022000 | isr0
> [ 1875.801853] iwlwifi :01:00.0: 0x0100 | isr1
> [ 1875.806751] iwlwifi :01:00.0: 0x08301802 | isr2
> [ 1875.811653] iwlwifi :01:00.0: 0x00415CC0 | isr3
> [ 1875.816559] iwlwifi :01:00.0: 0x | isr4
> [ 1875.821462] iwlwifi :01:00.0: 0x000501D1 | last cmd Id
> [ 1875.826975] iwlwifi :01:00.0: 0x | wait_event
> [ 1875.832399] iwlwifi :01:00.0: 0x00D0 | l2p_control
> [ 1875.837928] iwlwifi :01:00.0: 0x00018014 | l2p_duration
> [ 1875.843527] iwlwifi :01:00.0: 0x003F | l2p_mhvalid
> [ 1875.849040] iwlwifi :01:00.0: 0x | l2p_addr_match
> [ 1875.854811] iwlwifi :01:00.0: 0x000D | lmpm_pmg_sel
> [ 1875.860412] iwlwifi :01:00.0: 0x04071046 | timestamp
> [ 1875.865758] iwlwifi :01:00.0: 0xC0E4 | flow_handler
> [ 1875.871405] iwlwifi :01:00.0: Start IWL Error Log Dump:
> [ 1875.877037] iwlwifi :01:00.0: Status: 0x0100, count: 7
> [ 1875.882889] iwlwifi :01:00.0: 0x0070 | ADVANCED_SYSASSERT
> [ 1875.889020] iwlwifi :01:00.0: 0x | umac branchlink1
> [ 1875.894959] iwlwifi :01:00.0: 0xC0087CB8 | umac branchlink2
> [ 1875.900904] iwlwifi :01:00.0: 0xC0084264 | umac interruptlink1
> [ 1875.907134] iwlwifi :01:00.0: 0xC00847C8 | umac interruptlink2
> [ 1875.913344] iwlwifi :01:00.0: 0x0800 | umac data1
> [ 1875.918764] iwlwifi :01:00.0: 0xC00847C8 | umac data2
> [ 1875.924184] iwlwifi :01:00.0: 0xDEADBEEF | umac data3
> [ 1875.929606] iwlwifi :01:00.0: 0x0026 | umac major
> [ 1875.935026] iwlwifi :01:00.0: 0x755CFDD8 | umac minor
> [ 1875.940448] iwlwifi :01:00.0: 0xC0887F30 | frame pointer
> [ 1875.946128] iwlwifi :01:00.0: 0xC0887F30 | stack pointer
> [ 1875.951810] iwlwifi :01:00.0: 0x0006012B | last host cmd
> [ 1875.957488] iwlwifi :01:00.0: 0x | isr status reg
> [ 1875.963268] ieee80211 phy0: Hardware restart was requested
> [ 1875.968932] iwlwifi :01:00.0: iwlwifi transaction failed, dumping 
> registers
> [ 1875.976275] iwlwifi :01:00.0: iwlwifi device config registers:
> [ 1875.983647] iwlwifi :01:00.0: : 25268086 00100406 02800029 
>  e004   
> [ 1875.994312] iwlwifi :01:00.0: 0020:    
> 00148086  00c8

Re: Issue with intel wireless-AC 9260 in wifi direct in 5Ghz

[Equipe Soft]

Hello, Did you have any news about the issue?
Regards.

Le mer. 28 août 2019 à 19:21, Equipe Soft
 a écrit :
>
> Hello,
> I'm trying to set up a wifi direct group between my AC9260 wifi board
> and a android tablet supporting WifiDirect.
>
> I tried several configurations and I faced some issues.
> Here follow the testing sequence. All the following command are sent
> through wpa_cli:
>
> > p2p_find
> P2P-DEVICE-FOUND f2:ee:10:c2:ce:68 p2p_dev_addr=f2:ee:10:c2:ce:68
> pri_dev_type=10-0050F204-5 name='[Tablet] Galaxy Tab S3'
> config_methods=0x188 dev_capab=0x25 group_capab=0x0 vendor_elems=1
> new=1
>
> >p2p_connect f2:ee:10:c2:ce:68 pin 1234 go_intent=1
> 74493685
>
> PIN is set on the tablet then, on my terminal I see:
>
> P2P-GO-NEG-SUCCESS role=GO freq=5785 ht40=0 peer_dev=f2:ee:10:c2:ce:68
> peer_iface=f2:ee:10:c2:4e:68 wps_method=Display
> P2P-GROUP-FORMATION-FAILURE
> P2P-GROUP-REMOVED p2p-wlan0-0 GO reason=FORMATION_FAILED
>
> dmesg :
>
> [ 1875.593069] IPv6: ADDRCONF(NETDEV_UP): p2p-wlan0-0: link is not ready
> [ 1875.659199] iwlwifi :01:00.0: Microcode SW error detected.
> Restarting 0x200.
> [ 1875.667246] iwlwifi :01:00.0: Start IWL Error Log Dump:
> [ 1875.672851] iwlwifi :01:00.0: Status: 0x0100, count: 6
> [ 1875.678718] iwlwifi :01:00.0: Loaded firmware version: 38.755cfdd8.0
> [ 1875.685466] iwlwifi :01:00.0: 0x14FC | ADVANCED_SYSASSERT
> [ 1875.692498] iwlwifi :01:00.0: 0x00A0A200 | trm_hw_status0
> [ 1875.698270] iwlwifi :01:00.0: 0x | trm_hw_status1
> [ 1875.704048] iwlwifi :01:00.0: 0x00454EF6 | branchlink2
> [ 1875.709561] iwlwifi :01:00.0: 0x0045E90E | interruptlink1
> [ 1875.715330] iwlwifi :01:00.0: 0x | interruptlink2
> [ 1875.721096] iwlwifi :01:00.0: 0x9D00 | data1
> [ 1875.726084] iwlwifi :01:00.0: 0x0741 | data2
> [ 1875.731070] iwlwifi :01:00.0: 0x00090010 | data3
> [ 1875.736076] iwlwifi :01:00.0: 0x | beacon time
> [ 1875.741589] iwlwifi :01:00.0: 0x6F091C80 | tsf low
> [ 1875.746757] iwlwifi :01:00.0: 0x | tsf hi
> [ 1875.751833] iwlwifi :01:00.0: 0x | time gp1
> [ 1875.757081] iwlwifi :01:00.0: 0x6F091C81 | time gp2
> [ 1875.762325] iwlwifi :01:00.0: 0x0001 | uCode revision type
> [ 1875.768529] iwlwifi :01:00.0: 0x0026 | uCode version major
> [ 1875.774731] iwlwifi :01:00.0: 0x755CFDD8 | uCode version minor
> [ 1875.780934] iwlwifi :01:00.0: 0x0321 | hw version
> [ 1875.786352] iwlwifi :01:00.0: 0x00C89004 | board version
> [ 1875.792044] iwlwifi :01:00.0: 0x801BF402 | hcmd
> [ 1875.796951] iwlwifi :01:00.0: 0x24022000 | isr0
> [ 1875.801853] iwlwifi :01:00.0: 0x0100 | isr1
> [ 1875.806751] iwlwifi :01:00.0: 0x08301802 | isr2
> [ 1875.811653] iwlwifi :01:00.0: 0x00415CC0 | isr3
> [ 1875.816559] iwlwifi :01:00.0: 0x | isr4
> [ 1875.821462] iwlwifi :01:00.0: 0x000501D1 | last cmd Id
> [ 1875.826975] iwlwifi :01:00.0: 0x | wait_event
> [ 1875.832399] iwlwifi :01:00.0: 0x00D0 | l2p_control
> [ 1875.837928] iwlwifi :01:00.0: 0x00018014 | l2p_duration
> [ 1875.843527] iwlwifi :01:00.0: 0x003F | l2p_mhvalid
> [ 1875.849040] iwlwifi :01:00.0: 0x | l2p_addr_match
> [ 1875.854811] iwlwifi :01:00.0: 0x000D | lmpm_pmg_sel
> [ 1875.860412] iwlwifi :01:00.0: 0x04071046 | timestamp
> [ 1875.865758] iwlwifi :01:00.0: 0xC0E4 | flow_handler
> [ 1875.871405] iwlwifi :01:00.0: Start IWL Error Log Dump:
> [ 1875.877037] iwlwifi :01:00.0: Status: 0x0100, count: 7
> [ 1875.882889] iwlwifi :01:00.0: 0x0070 | ADVANCED_SYSASSERT
> [ 1875.889020] iwlwifi :01:00.0: 0x | umac branchlink1
> [ 1875.894959] iwlwifi :01:00.0: 0xC0087CB8 | umac branchlink2
> [ 1875.900904] iwlwifi :01:00.0: 0xC0084264 | umac interruptlink1
> [ 1875.907134] iwlwifi :01:00.0: 0xC00847C8 | umac interruptlink2
> [ 1875.913344] iwlwifi :01:00.0: 0x0800 | umac data1
> [ 1875.918764] iwlwifi :01:00.0: 0xC00847C8 | umac data2
> [ 1875.924184] iwlwifi :01:00.0: 0xDEADBEEF | umac data3
> [ 1875.929606] iwlwifi :01:00.0: 0x0026 | umac major
> [ 1875.935026] iwlwifi :01:00.0: 0x755CFDD8 | umac minor
> [ 1875.940448] iwlwifi :01:00.0: 0xC0887F30 | frame pointer
> [ 1875.946128] iwlwifi :01:00.0: 0xC0887F30 | stack pointer
> [ 1875.951810] iwlwifi :01:00.0: 0x0006012B | last host cmd
> [ 1875.957488] iwlwifi :01:00.0: 0x | isr status reg
> [ 1875.963268] ieee80211 phy0: Hardware restart was requested
> [ 1875.968932] iwlwifi :01:00.0: iwlwifi transaction failed,
> dumping registers
> [ 1875.976275] iwlwifi :01:00.0: iwlwifi device config registers:
> [ 1875.983647] iwlwifi :01:00.0: : 25268086 00100406
> 02800029  e004   
> [ 1875.994312] iwlwifi :01:00.0: 0020:  
>  00148086  00

[PATCH v2] wireless-regdb: update regulatory rules for Kazakhstan (KZ)

[Dmitry Tunin]

Update according to the regulatory rule of January 21, 2015

http://egov.kz/cms/ru/law/list/V1500010730
https://tengrinews.kz/zakon/pravitelstvo_respubliki_kazahstan_premer_ministr_rk/svyaz/id-V1500010730/

No DFS or TPC is mentioned in the document. Neither is 80 MHz channel width.

Signed-off-by: Dmitry Tunin 
---
 db.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/db.txt b/db.txt
index 37393e6..491598e 100644
--- a/db.txt
+++ b/db.txt
@@ -717,13 +717,13 @@ country KY: DFS-FCC
(5735 - 5835 @ 80), (30)
 
 # 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
+# http://egov.kz/cms/ru/law/list/V1500010730
+# 
https://tengrinews.kz/zakon/pravitelstvo_respubliki_kazahstan_premer_ministr_rk/svyaz/id-V1500010730/
+country KZ:
+   (2400 - 2483.5 @ 40), (20)
+   (5150 - 5350 @ 160), (23), NO-OUTDOOR
+   (5470 - 5850 @ 160), (20), NO-OUTDOOR
+   (57000 - 66000 @ 2160), (40), NO-OUTDOOR
 
 country LB: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.7.4

[PATCH] wireless-regdb: update regulatory rulez for Kazakрstan (KZ)

[Dmitry Tunin]

Update according to the regulatory rule of January 21, 2015

http://egov.kz/cms/ru/law/list/V1500010730
https://tengrinews.kz/zakon/pravitelstvo_respubliki_kazahstan_premer_ministr_rk/svyaz/id-V1500010730/

No DFS or TPC is mentioned in the document. Neither is 80 MHz channel width.

Signed-off-by: Dmitry Tunin 
---
 db.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/db.txt b/db.txt
index 37393e6..491598e 100644
--- a/db.txt
+++ b/db.txt
@@ -717,13 +717,13 @@ country KY: DFS-FCC
(5735 - 5835 @ 80), (30)
 
 # 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
+# http://egov.kz/cms/ru/law/list/V1500010730
+# 
https://tengrinews.kz/zakon/pravitelstvo_respubliki_kazahstan_premer_ministr_rk/svyaz/id-V1500010730/
+country KZ:
+   (2400 - 2483.5 @ 40), (20)
+   (5150 - 5350 @ 160), (23), NO-OUTDOOR
+   (5470 - 5850 @ 160), (20), NO-OUTDOOR
+   (57000 - 66000 @ 2160), (40), NO-OUTDOOR
 
 country LB: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.7.4

Issue with intel wireless-AC 9260 in wifi direct in 5Ghz

[Equipe Soft]

Hello,
I'm trying to set up a wifi direct group between my AC9260 wifi board
and a android tablet supporting WifiDirect.

I tried several configurations and I faced some issues.
Here follow the testing sequence. All the following command are sent
through wpa_cli:

> p2p_find
P2P-DEVICE-FOUND f2:ee:10:c2:ce:68 p2p_dev_addr=f2:ee:10:c2:ce:68
pri_dev_type=10-0050F204-5 name='[Tablet] Galaxy Tab S3'
config_methods=0x188 dev_capab=0x25 group_capab=0x0 vendor_elems=1
new=1

>p2p_connect f2:ee:10:c2:ce:68 pin 1234 go_intent=1
74493685

PIN is set on the tablet then, on my terminal I see:

P2P-GO-NEG-SUCCESS role=GO freq=5785 ht40=0 peer_dev=f2:ee:10:c2:ce:68
peer_iface=f2:ee:10:c2:4e:68 wps_method=Display
P2P-GROUP-FORMATION-FAILURE
P2P-GROUP-REMOVED p2p-wlan0-0 GO reason=FORMATION_FAILED

dmesg :

[ 1875.593069] IPv6: ADDRCONF(NETDEV_UP): p2p-wlan0-0: link is not ready
[ 1875.659199] iwlwifi :01:00.0: Microcode SW error detected.
Restarting 0x200.
[ 1875.667246] iwlwifi :01:00.0: Start IWL Error Log Dump:
[ 1875.672851] iwlwifi :01:00.0: Status: 0x0100, count: 6
[ 1875.678718] iwlwifi :01:00.0: Loaded firmware version: 38.755cfdd8.0
[ 1875.685466] iwlwifi :01:00.0: 0x14FC | ADVANCED_SYSASSERT
[ 1875.692498] iwlwifi :01:00.0: 0x00A0A200 | trm_hw_status0
[ 1875.698270] iwlwifi :01:00.0: 0x | trm_hw_status1
[ 1875.704048] iwlwifi :01:00.0: 0x00454EF6 | branchlink2
[ 1875.709561] iwlwifi :01:00.0: 0x0045E90E | interruptlink1
[ 1875.715330] iwlwifi :01:00.0: 0x | interruptlink2
[ 1875.721096] iwlwifi :01:00.0: 0x9D00 | data1
[ 1875.726084] iwlwifi :01:00.0: 0x0741 | data2
[ 1875.731070] iwlwifi :01:00.0: 0x00090010 | data3
[ 1875.736076] iwlwifi :01:00.0: 0x | beacon time
[ 1875.741589] iwlwifi :01:00.0: 0x6F091C80 | tsf low
[ 1875.746757] iwlwifi :01:00.0: 0x | tsf hi
[ 1875.751833] iwlwifi :01:00.0: 0x | time gp1
[ 1875.757081] iwlwifi :01:00.0: 0x6F091C81 | time gp2
[ 1875.762325] iwlwifi :01:00.0: 0x0001 | uCode revision type
[ 1875.768529] iwlwifi :01:00.0: 0x0026 | uCode version major
[ 1875.774731] iwlwifi :01:00.0: 0x755CFDD8 | uCode version minor
[ 1875.780934] iwlwifi :01:00.0: 0x0321 | hw version
[ 1875.786352] iwlwifi :01:00.0: 0x00C89004 | board version
[ 1875.792044] iwlwifi :01:00.0: 0x801BF402 | hcmd
[ 1875.796951] iwlwifi :01:00.0: 0x24022000 | isr0
[ 1875.801853] iwlwifi :01:00.0: 0x0100 | isr1
[ 1875.806751] iwlwifi :01:00.0: 0x08301802 | isr2
[ 1875.811653] iwlwifi :01:00.0: 0x00415CC0 | isr3
[ 1875.816559] iwlwifi :01:00.0: 0x | isr4
[ 1875.821462] iwlwifi :01:00.0: 0x000501D1 | last cmd Id
[ 1875.826975] iwlwifi :01:00.0: 0x | wait_event
[ 1875.832399] iwlwifi :01:00.0: 0x00D0 | l2p_control
[ 1875.837928] iwlwifi :01:00.0: 0x00018014 | l2p_duration
[ 1875.843527] iwlwifi :01:00.0: 0x003F | l2p_mhvalid
[ 1875.849040] iwlwifi :01:00.0: 0x | l2p_addr_match
[ 1875.854811] iwlwifi :01:00.0: 0x000D | lmpm_pmg_sel
[ 1875.860412] iwlwifi :01:00.0: 0x04071046 | timestamp
[ 1875.865758] iwlwifi :01:00.0: 0xC0E4 | flow_handler
[ 1875.871405] iwlwifi :01:00.0: Start IWL Error Log Dump:
[ 1875.877037] iwlwifi :01:00.0: Status: 0x0100, count: 7
[ 1875.882889] iwlwifi :01:00.0: 0x0070 | ADVANCED_SYSASSERT
[ 1875.889020] iwlwifi :01:00.0: 0x | umac branchlink1
[ 1875.894959] iwlwifi :01:00.0: 0xC0087CB8 | umac branchlink2
[ 1875.900904] iwlwifi :01:00.0: 0xC0084264 | umac interruptlink1
[ 1875.907134] iwlwifi :01:00.0: 0xC00847C8 | umac interruptlink2
[ 1875.913344] iwlwifi :01:00.0: 0x0800 | umac data1
[ 1875.918764] iwlwifi :01:00.0: 0xC00847C8 | umac data2
[ 1875.924184] iwlwifi :01:00.0: 0xDEADBEEF | umac data3
[ 1875.929606] iwlwifi :01:00.0: 0x0026 | umac major
[ 1875.935026] iwlwifi :01:00.0: 0x755CFDD8 | umac minor
[ 1875.940448] iwlwifi :01:00.0: 0xC0887F30 | frame pointer
[ 1875.946128] iwlwifi :01:00.0: 0xC0887F30 | stack pointer
[ 1875.951810] iwlwifi :01:00.0: 0x0006012B | last host cmd
[ 1875.957488] iwlwifi :01:00.0: 0x | isr status reg
[ 1875.963268] ieee80211 phy0: Hardware restart was requested
[ 1875.968932] iwlwifi :01:00.0: iwlwifi transaction failed,
dumping registers
[ 1875.976275] iwlwifi :01:00.0: iwlwifi device config registers:
[ 1875.983647] iwlwifi :01:00.0: : 25268086 00100406
02800029  e004   
[ 1875.994312] iwlwifi :01:00.0: 0020:  
 00148086  00c8  012b
[ 1876.004835] iwlwifi :01:00.0: iwlwifi device memory mapped registers:
[ 1876.011780] iwlwifi :01:00.0: : 00c89004 0040
 ba8b   00027e1f 
[ 1876.022251] iwlwifi :01:00.0: 0020:  0c040005
00

Re: [PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

> It's not specifically 20 dBm, it's halving the power limit (i.e.
> reducing it by 3 dBm).

I suggest to leave it on 23dBm. It is low enough especially for 5650 - 5850.
I am sure that a lot of Linux devices are certified that have this limit.

The TPC mentioned in the reg doc doesn't explain what it means.

Re: [PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz

[Seth Forshee]

On Fri, Aug 23, 2019 at 10:08:39PM +0300, Dmitry Tunin wrote:
> пт, 23 авг. 2019 г. в 22:00, Seth Forshee :
> >
> > On Mon, Jul 29, 2019 at 10:07:26PM +0300, Dmitry Tunin wrote:
> > > Russian entry is incorrect. According to the last regulations document of 
> > > Feb 29, 2016,
> > > 160 MHz channels and 802.11ad are allowed.
> > >
> > > http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
> > >
> > > Note that there was never a DFS requirement in Russia, but always was
> > > NO-OUTDOOR on 5GHz.
> > > Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> > > Also Russia has never been regulated by ETSI.
> > >
> > > Signed-off-by: Dmitry Tunin 
> > > ---
> > >  db.txt | 10 --
> > >  1 file changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/db.txt b/db.txt
> > > index 37393e6..d95ed5e 100644
> > > --- a/db.txt
> > > +++ b/db.txt
> > > @@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
> > >   # 60 GHz band channels 1-4, ref: Etsi En 302 567
> > >   (57000 - 66000 @ 2160), (40)
> > >
> > > -country RU: DFS-ETSI
> > > +country RU:
> > >   (2402 - 2482 @ 40), (20)
> > > - (5170 - 5250 @ 80), (20), AUTO-BW
> > > - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > > - (5650 - 5730 @ 80), (30), DFS
> > > - (5735 - 5835 @ 80), (30)
> > > + (5170 - 5350 @ 160), (23), NO-OUTDOOR
> > > + (5650 - 5850 @ 160), (23), NO-OUTDOOR
> >
> > Based on the translation I've read of the document you've linked to as
> > well as a couple of others, it sounds like the use of these ranges
> > requires TPC. Since TPC is not supported in Linux, we need to reduce the
> > max EIRP for these ranges to 20 dBm.
> >
> > While modifying them, let's also update the 5170-5350 range to 5150-5350
> > to match the regulations.
> 
> 
> It is not very clearly stated, but I agree that it looks like TPC.
> Where is it stated that we need 20 dBm on these ranges if they require
> TPC?
> Unfortunately I don't have devices with OEM software certified in
> Russia to see what is the limit.

It's not specifically 20 dBm, it's halving the power limit (i.e.
reducing it by 3 dBm).

Seth

Re: [PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

пт, 23 авг. 2019 г. в 22:00, Seth Forshee :
>
> On Mon, Jul 29, 2019 at 10:07:26PM +0300, Dmitry Tunin wrote:
> > Russian entry is incorrect. According to the last regulations document of 
> > Feb 29, 2016,
> > 160 MHz channels and 802.11ad are allowed.
> >
> > http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
> >
> > Note that there was never a DFS requirement in Russia, but always was
> > NO-OUTDOOR on 5GHz.
> > Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> > Also Russia has never been regulated by ETSI.
> >
> > Signed-off-by: Dmitry Tunin 
> > ---
> >  db.txt | 10 --
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/db.txt b/db.txt
> > index 37393e6..d95ed5e 100644
> > --- a/db.txt
> > +++ b/db.txt
> > @@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
> >   # 60 GHz band channels 1-4, ref: Etsi En 302 567
> >   (57000 - 66000 @ 2160), (40)
> >
> > -country RU: DFS-ETSI
> > +country RU:
> >   (2402 - 2482 @ 40), (20)
> > - (5170 - 5250 @ 80), (20), AUTO-BW
> > - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > - (5650 - 5730 @ 80), (30), DFS
> > - (5735 - 5835 @ 80), (30)
> > + (5170 - 5350 @ 160), (23), NO-OUTDOOR
> > + (5650 - 5850 @ 160), (23), NO-OUTDOOR
>
> Based on the translation I've read of the document you've linked to as
> well as a couple of others, it sounds like the use of these ranges
> requires TPC. Since TPC is not supported in Linux, we need to reduce the
> max EIRP for these ranges to 20 dBm.
>
> While modifying them, let's also update the 5170-5350 range to 5150-5350
> to match the regulations.


It is not very clearly stated, but I agree that it looks like TPC.
Where is it stated that we need 20 dBm on these ranges if they require
TPC?
Unfortunately I don't have devices with OEM software certified in
Russia to see what is the limit.

Re: [PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz

[Seth Forshee]

On Mon, Jul 29, 2019 at 10:07:26PM +0300, Dmitry Tunin wrote:
> Russian entry is incorrect. According to the last regulations document of Feb 
> 29, 2016,
> 160 MHz channels and 802.11ad are allowed.
> 
> http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
> 
> Note that there was never a DFS requirement in Russia, but always was
> NO-OUTDOOR on 5GHz.
> Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> Also Russia has never been regulated by ETSI.
> 
> Signed-off-by: Dmitry Tunin 
> ---
>  db.txt | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index 37393e6..d95ed5e 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
>   # 60 GHz band channels 1-4, ref: Etsi En 302 567
>   (57000 - 66000 @ 2160), (40)
>  
> -country RU: DFS-ETSI
> +country RU:
>   (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (20), AUTO-BW
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> - (5650 - 5730 @ 80), (30), DFS
> - (5735 - 5835 @ 80), (30)
> + (5170 - 5350 @ 160), (23), NO-OUTDOOR
> + (5650 - 5850 @ 160), (23), NO-OUTDOOR

Based on the translation I've read of the document you've linked to as
well as a couple of others, it sounds like the use of these ranges
requires TPC. Since TPC is not supported in Linux, we need to reduce the
max EIRP for these ranges to 20 dBm.

While modifying them, let's also update the 5170-5350 range to 5150-5350
to match the regulations.

Thanks,
Seth

>   # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order 
> №129_22042015.pdf
> - (57000 - 66000 @ 2160), (40)
> + (57000 - 66000 @ 2160), (40), NO-OUTDOOR
>  
>  country RW: DFS-FCC
>   (2402 - 2482 @ 40), (20)
> -- 
> 2.7.4
> 

Re: [PATCH] wireless-regdb: Extend 5470-5725 MHz range to 5730 MHz for Taiwan (TW)

[Seth Forshee]

On Fri, Jul 26, 2019 at 11:05:38AM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai 
> 
> This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
> The Linux kernel however does not seem capable of considering them
> most restrictive subset of multiple rules.
> 
> Since 5725 ~ 5730 MHz belongs to the next range which has looser
> requirements, we can do this manually and extend the range by 5 MHz
> to make the kernel happy and be able to use channel 144.
> 
> Also, looking at the US regulations, which the TW ones are based on,
> The DFS range ends at 5730 MHz, while the next range starts at 5735
> MHz. This doesn't match the actual regulations, but is skewed to meet
> wireless channel boundaries. I prefer the database match the law,
> and be adjuested only if necessary.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
> 
> I have a vague impression that you asked about the range boundaries
> when I first updated the rules for Taiwan. And here we are again.

I don't recall, but I too prefer that we keep the boundaries mostly in
line with the regulations, not the wireless channel boundaries. Here it
does seem appropriate though to borrow the extra 5MHz into a more
rescrictive rule.

I wasn't sure about having rules with overlapping ranges. I've been
looking at the code though, and I don't see that it will be an issue. I
may give a few more days though to see if anyone else knows some reason
I missed that it could be a problem.

Thanks,
Seth

> 
> ---
>  db.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/db.txt b/db.txt
> index 37393e6..2e149b6 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -1249,7 +1249,11 @@ country TW: DFS-FCC
>   # 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
>   (5150 - 5250 @ 80), (23), AUTO-BW
>   (5250 - 5350 @ 80), (23), DFS, AUTO-BW
> - (5470 - 5725 @ 160), (23), DFS
> + # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
> + # Since 5725 ~ 5730 MHz belongs to the next range which has looser
> + # requirements, we can extend the range by 5 MHz to make the kernel
> + # happy and be able to use channel 144.
> + (5470 - 5730 @ 160), (23), DFS
>   (5725 - 5850 @ 80), (30)
>   # 60g band, LP0002 section 3.13.1.1 (3)(C), EIRP=40dBm(43dBm peak)
>   (57000 - 66000 @ 2160), (40)
> -- 
> 2.20.1
> 

[PATCH-v2 1/2] wireless: Support assoc-at timer in sta-info

[greearb]

From: Ben Greear 

Report time stamp of when sta became associated.

This is the boottime clock, units are nano-seconds.

Signed-off-by: Ben Greear 
---

v2:  I had forgotten to refresh the 2/2 patch.

 include/net/cfg80211.h   | 2 ++
 include/uapi/linux/nl80211.h | 2 ++
 net/wireless/nl80211.c   | 1 +
 3 files changed, 5 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef510c916635..19c200b917eb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1306,6 +1306,7 @@ struct cfg80211_tid_stats {
  * indicate the relevant values in this struct for them
  * @connected_time: time(in secs) since a station is last connected
  * @inactive_time: time since last station activity (tx/rx) in milliseconds
+ * @assoc_at: bootime (ns) of the last association
  * @rx_bytes: bytes (size of MPDUs) received from this station
  * @tx_bytes: bytes (size of MPDUs) transmitted to this station
  * @llid: mesh local link id
@@ -1366,6 +1367,7 @@ struct station_info {
u64 filled;
u32 connected_time;
u32 inactive_time;
+   u64 assoc_at;
u64 rx_bytes;
u64 tx_bytes;
u16 llid;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 76d5811193be..3796e1e06665 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3175,6 +3175,7 @@ enum nl80211_sta_bss_param {
  * sent to the station (u64, usec)
  * @NL80211_STA_INFO_AIRTIME_WEIGHT: current airtime weight for station (u16)
  * @NL80211_STA_INFO_AIRTIME_LINK_METRIC: airtime link metric for mesh station
+ * @NL80211_STA_INFO_ASSOC_AT_BOOTTIME: Timestamp of last association
  * @__NL80211_STA_INFO_AFTER_LAST: internal
  * @NL80211_STA_INFO_MAX: highest possible station info attribute
  */
@@ -3221,6 +3222,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_TX_DURATION,
NL80211_STA_INFO_AIRTIME_WEIGHT,
NL80211_STA_INFO_AIRTIME_LINK_METRIC,
+   NL80211_STA_INFO_ASSOC_AT_BOOTTIME,
 
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 789cd98f02f5..b61a59b9d78b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5028,6 +5028,7 @@ static int nl80211_send_station(struct sk_buff *msg, u32 
cmd, u32 portid,
 
PUT_SINFO(CONNECTED_TIME, connected_time, u32);
PUT_SINFO(INACTIVE_TIME, inactive_time, u32);
+   PUT_SINFO_U64(ASSOC_AT_BOOTTIME, assoc_at);
 
if (sinfo->filled & (BIT_ULL(NL80211_STA_INFO_RX_BYTES) |
 BIT_ULL(NL80211_STA_INFO_RX_BYTES64)) &&
-- 
2.20.1

[PATCH 1/2] wireless: Support assoc-at timer in sta-info

[greearb]

From: Ben Greear 

Report time stamp of when sta became associated.

This is the boottime clock, units are nano-seconds.

Signed-off-by: Ben Greear 
---

This attempts to implement the associated-at timestamp reporting
with boottime stamp instead of wall-clock, as suggested.

 include/net/cfg80211.h   | 2 ++
 include/uapi/linux/nl80211.h | 2 ++
 net/wireless/nl80211.c   | 1 +
 3 files changed, 5 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef510c916635..19c200b917eb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1306,6 +1306,7 @@ struct cfg80211_tid_stats {
  * indicate the relevant values in this struct for them
  * @connected_time: time(in secs) since a station is last connected
  * @inactive_time: time since last station activity (tx/rx) in milliseconds
+ * @assoc_at: bootime (ns) of the last association
  * @rx_bytes: bytes (size of MPDUs) received from this station
  * @tx_bytes: bytes (size of MPDUs) transmitted to this station
  * @llid: mesh local link id
@@ -1366,6 +1367,7 @@ struct station_info {
u64 filled;
u32 connected_time;
u32 inactive_time;
+   u64 assoc_at;
u64 rx_bytes;
u64 tx_bytes;
u16 llid;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 76d5811193be..3796e1e06665 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3175,6 +3175,7 @@ enum nl80211_sta_bss_param {
  * sent to the station (u64, usec)
  * @NL80211_STA_INFO_AIRTIME_WEIGHT: current airtime weight for station (u16)
  * @NL80211_STA_INFO_AIRTIME_LINK_METRIC: airtime link metric for mesh station
+ * @NL80211_STA_INFO_ASSOC_AT_BOOTTIME: Timestamp of last association
  * @__NL80211_STA_INFO_AFTER_LAST: internal
  * @NL80211_STA_INFO_MAX: highest possible station info attribute
  */
@@ -3221,6 +3222,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_TX_DURATION,
NL80211_STA_INFO_AIRTIME_WEIGHT,
NL80211_STA_INFO_AIRTIME_LINK_METRIC,
+   NL80211_STA_INFO_ASSOC_AT_BOOTTIME,
 
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 789cd98f02f5..b61a59b9d78b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5028,6 +5028,7 @@ static int nl80211_send_station(struct sk_buff *msg, u32 
cmd, u32 portid,
 
PUT_SINFO(CONNECTED_TIME, connected_time, u32);
PUT_SINFO(INACTIVE_TIME, inactive_time, u32);
+   PUT_SINFO_U64(ASSOC_AT_BOOTTIME, assoc_at);
 
if (sinfo->filled & (BIT_ULL(NL80211_STA_INFO_RX_BYTES) |
 BIT_ULL(NL80211_STA_INFO_RX_BYTES64)) &&
-- 
2.20.1

Re: [PATCH] wireless: fix netlink vendor commands

[kbuild test robot]

Hi Johannes,

I love your patch! Yet something to improve:

[auto build test ERROR on wireless-drivers-next/master]
[cannot apply to v5.3-rc3 next-20190808]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Johannes-Berg/wireless-fix-netlink-vendor-commands/20190625-220203
base:   
https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
 master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

>> drivers/net//wireless/ti/wlcore/vendor_cmd.c:169:4: error: 'const struct 
>> wiphy_vendor_command' has no member named 'policy'
  .policy = wlcore_vendor_attr_policy,
   ^~
>> drivers/net//wireless/ti/wlcore/vendor_cmd.c:169:13: error: initialization 
>> from incompatible pointer type [-Werror=incompatible-pointer-types]
  .policy = wlcore_vendor_attr_policy,
^
   drivers/net//wireless/ti/wlcore/vendor_cmd.c:169:13: note: (near 
initialization for 'wlcore_vendor_commands[0].dumpit')
   drivers/net//wireless/ti/wlcore/vendor_cmd.c:179:4: error: 'const struct 
wiphy_vendor_command' has no member named 'policy'
  .policy = wlcore_vendor_attr_policy,
   ^~
   drivers/net//wireless/ti/wlcore/vendor_cmd.c:179:13: error: initialization 
from incompatible pointer type [-Werror=incompatible-pointer-types]
  .policy = wlcore_vendor_attr_policy,
^
   drivers/net//wireless/ti/wlcore/vendor_cmd.c:179:13: note: (near 
initialization for 'wlcore_vendor_commands[1].dumpit')
   drivers/net//wireless/ti/wlcore/vendor_cmd.c:189:4: error: 'const struct 
wiphy_vendor_command' has no member named 'policy'
  .policy = wlcore_vendor_attr_policy,
   ^~
   drivers/net//wireless/ti/wlcore/vendor_cmd.c:189:13: error: initialization 
from incompatible pointer type [-Werror=incompatible-pointer-types]
  .policy = wlcore_vendor_attr_policy,
^
   drivers/net//wireless/ti/wlcore/vendor_cmd.c:189:13: note: (near 
initialization for 'wlcore_vendor_commands[2].dumpit')
   cc1: some warnings being treated as errors

vim +169 drivers/net//wireless/ti/wlcore/vendor_cmd.c

   159  
   160  static const struct wiphy_vendor_command wlcore_vendor_commands[] = {
   161  {
   162  .info = {
   163  .vendor_id = TI_OUI,
   164  .subcmd = WLCORE_VENDOR_CMD_SMART_CONFIG_START,
   165  },
   166  .flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
   167   WIPHY_VENDOR_CMD_NEED_RUNNING,
   168  .doit = wlcore_vendor_cmd_smart_config_start,
 > 169  .policy = wlcore_vendor_attr_policy,
   170  },
   171  {
   172  .info = {
   173  .vendor_id = TI_OUI,
   174  .subcmd = WLCORE_VENDOR_CMD_SMART_CONFIG_STOP,
   175  },
   176  .flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
   177   WIPHY_VENDOR_CMD_NEED_RUNNING,
   178  .doit = wlcore_vendor_cmd_smart_config_stop,
   179  .policy = wlcore_vendor_attr_policy,
   180  },
   181  {
   182  .info = {
   183  .vendor_id = TI_OUI,
   184  .subcmd = 
WLCORE_VENDOR_CMD_SMART_CONFIG_SET_GROUP_KEY,
   185  },
   186  .flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
   187   WIPHY_VENDOR_CMD_NEED_RUNNING,
   188  .doit = wlcore_vendor_cmd_smart_config_set_group_key,
   189  .policy = wlcore_vendor_attr_policy,
   190  },
   191  };
   192  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] wireless-regdb: Fix ranges of EU countries as they are harmonized since 2014...

[Emil Petersky]

://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+#
 # Allocation for the 2.4 GHz band (Vfg 10 / 2013, Allgemeinzuteilung von
 # Frequenzen für die Nutzung in lokalen Netzwerken; Wireless Local Area
 # Networks (WLAN-Funkanwendungen).
@@ -368,7 +417,6 @@ country CZ: DFS-ETSI
 # Bereich 57 GHz - 66 GHz für Funkanwendungen für weitbandige
 # Datenübertragungssysteme; „Multiple Gigabit WAS/RLAN Systems (MGWS)“).
 # 
https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2011_08_MGWS_pdf.pdf
-
 country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
@@ -379,16 +427,22 @@ country DE: DFS-ETSI
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
 
-# Sources:
+# DK as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893) 
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+#  EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+#  EU decision 2006/771/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# DK: https://ens.dk/sites/ens.dk/files/Tele/frekvensplan_0.pdf
 # 5GHz: 
https://erhvervsstyrelsen.dk/sites/default/files/007_interface-datanet_5-6_ghz.pdf.pdf
 # 60GHz: 
https://erhvervsstyrelsen.dk/sites/default/files/radiograenseflader-63.pdf
 country DK: DFS-ETSI
-   (2400 - 2483.5 @ 40), (20)
-   (5150 - 5250 @ 80), (23), AUTO-BW, wmmrule=ETSI
-   (5250 - 5350 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
-   (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
+   (2400 - 2483.5 @ 40), (100 mW)
+   (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+   # short range devices (ETSI EN 300 440-1)
+   (5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4 (ETSI EN 302 567)
-   (57000 - 66000 @ 2160), (40), NO-OUTDOOR
+   (57000 - 66000 @ 2160), (40)
 
 # Source:
 # 
http://www.ntrcdom.org/index.php?option=com_content&view=category&layout=blog&id=10&Itemid=55
@@ -417,12 +471,20 @@ country EC: DFS-FCC
(5490 - 5730 @ 20), (24), DFS
(5735 - 5835 @ 20), (30)
 
+# EE as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893) 
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+#  EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+#  EU decision 2006/771/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# EE: 
https://www.ttja.ee/et/ettevottele-organisatsioonile/sideteenused/raadioseadmed/wifi-seade
+# EE: 
https://www.itu.int/ITU-D/study_groups/SGP_1998-2002/JGRES09/pdf/estonia.pdf
 country EE: DFS-ETSI
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
-   (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
-   # 60 GHz band channels 1-4, ref: Etsi En 302 567
+   (2400 - 2483.5 @ 40), (100 mW)
+   (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
+   # short range devices (ETSI EN 300 440-1)
+   (5725 - 5875 @ 80), (25 mW)
+   # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
 
 country EG: DFS-ETSI
@@ -430,17 +492,19 @@ country EG: DFS-ETSI
(5170 - 5250 @ 40), (20)
(5250 - 5330 @ 40), (20), DFS
 
-# Source:
-# Cuadro nacional de atribución de frecuencias (CNAF)
-# https://avancedigital.gob.es/espectro/Paginas/cnaf.aspx
+# ES as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893) 
+# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
+#  EU decision 2005/513/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+#  EU decision 2006/771/EC: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+# ES: https://avancedigital.gob.es/espectro/Paginas/cnaf.aspx
 country ES: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
-   # Short Range Devices (SRD) (ETSI EN 300 440)
+   # short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
-   # 60 GHz band channels 1-4, ref: Etsi En 302 567
+   # 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
 
 country ET: DFS-ETSI
@@

[PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

Russian entry is incorrect. According to the last regulations document of Feb 
29, 2016,
160 MHz channels and 802.11ad are allowed.

http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf

Note that there was never a DFS requirement in Russia, but always was
NO-OUTDOOR on 5GHz.
Maximum power is 200mW that is ~23dBm on all 5GHz channels.
Also Russia has never been regulated by ETSI.

Signed-off-by: Dmitry Tunin 
---
 db.txt | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/db.txt b/db.txt
index 37393e6..d95ed5e 100644
--- a/db.txt
+++ b/db.txt
@@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
-country RU: DFS-ETSI
+country RU:
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), AUTO-BW
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
-   (5650 - 5730 @ 80), (30), DFS
-   (5735 - 5835 @ 80), (30)
+   (5170 - 5350 @ 160), (23), NO-OUTDOOR
+   (5650 - 5850 @ 160), (23), NO-OUTDOOR
# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order 
???129_22042015.pdf
-   (57000 - 66000 @ 2160), (40)
+   (57000 - 66000 @ 2160), (40), NO-OUTDOOR
 
 country RW: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.7.4

[PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

Russian entry is incorrect. According to the last regulations document of Feb 
29, 2016,
160 MHz channels and 802.11ad are allowed.

http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf

Note that there was never a DFS requirement in Russia, but always was
NO-OUTDOOR on 5GHz.
Maximum power is 200mW that is ~23dBm on all 5GHz channels.
Also Russia has never been regulated by ETSI.

Signed-off-by: Dmitry Tunin 
---
 db.txt | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/db.txt b/db.txt
index 37393e6..068fb5a 100644
--- a/db.txt
+++ b/db.txt
@@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
-country RU: DFS-ETSI
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), AUTO-BW
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
-   (5650 - 5730 @ 80), (30), DFS
-   (5735 - 5835 @ 80), (30)
-   # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order 
???129_22042015.pdf
-   (57000 - 66000 @ 2160), (40)
+country RU:
+(2402 - 2482 @ 40), (20)
+(5170 - 5350 @ 160), (23), NO-OUTDOOR
+(5650 - 5850 @ 160), (23), NO-OUTDOOR
+# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order ???129_22042015.pdf
+(57000 - 66000 @ 2160), (40), NO-OUTDOOR
 
 country RW: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.7.4

[PATCH] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

Russian entry is incorrect. According to the last regulations document of Feb 
29, 2016,
160 MHz channels and 802.11ad are allowed.

http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf

Note that there was never a DFS requirement in Russia, but always was
NO-OUTDOOR on 5GHz.
Maximum power is 200mW that is ~23dBm on all 5GHz channels.
Also Russia has never been regulated by ETSI.

Signed-off-by: Dmitry Tunin 
---
 db.txt | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/db.txt b/db.txt
index 37393e6..068fb5a 100644
--- a/db.txt
+++ b/db.txt
@@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
-country RU: DFS-ETSI
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), AUTO-BW
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
-   (5650 - 5730 @ 80), (30), DFS
-   (5735 - 5835 @ 80), (30)
-   # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order 
???129_22042015.pdf
-   (57000 - 66000 @ 2160), (40)
+country RU:
+(2402 - 2482 @ 40), (20)
+(5170 - 5350 @ 160), (23), NO-OUTDOOR
+(5650 - 5850 @ 160), (23), NO-OUTDOOR
+# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order ???129_22042015.pdf
+(57000 - 66000 @ 2160), (40), NO-OUTDOOR
 
 country RW: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.7.4

Re: wireless-regdb: Update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

It is not easy to find and understand these Russian regulatory docs.
There is also another link with the master doc with both attachments.
http://rfs-rf.ru/grfc/norm_doc/detail/?ID=41839

I'll make a patch.

пн, 29 июл. 2019 г. в 21:30, Seth Forshee :
>
> On Mon, Jul 29, 2019 at 09:05:06PM +0300, Dmitry Tunin wrote:
> > I made an error while editing. The correct section is
> >
> > country RU:
> > (2402 - 2482 @ 40), (20)
> > (5170 - 5350 @ 160), (23), NO-OUTDOOR
> > (5650 - 5850 @ 160), (23), NO-OUTDOOR
> > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > (57000 - 66000 @ 2160), (40), NO-OUTDOOR
>
> Thanks. I haven't had time to look over the document to verify your
> proposed changes, but I would encourage you to go ahead and send a
> patch. I will try to look this over soon.
>
> Thanks,
> Seth
>
> >
> > вт, 23 июл. 2019 г. в 00:53, Dmitry Tunin :
> > >
> > > The db entry looks like this now
> > >
> > > country RU: DFS-ETSI
> > > (2402 - 2482 @ 40), (20)
> > > (5170 - 5250 @ 80), (20), AUTO-BW
> > > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > > (5650 - 5730 @ 80), (30), DFS
> > > (5735 - 5835 @ 80), (30)
> > > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order 
> > > №129_22042015.pdf
> > > (57000 - 66000 @ 2160), (40)
> > >
> > >
> > > This doesn't look correct. The regulation document is here
> > > http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
> > >
> > > According to the regulation document issued Feb 29 2016, there
> > > frequencies should look like this:
> > >
> > > country RU:
> > > (2402 - 2482 @ 40), (20)
> > > (5170 - 5330 @ 160), (23), NO-OUTDOOR
> > > (5650 - 5835 @ 160), (23), NO-OUTDOOR
> > > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order 
> > > №129_22042015.pdf
> > > (57000 - 66000 @ 2160), (40), NO-OUTDOOR
> > >
> > > Note that there was never a DFS requirement in Russia, but always was
> > > NO-OUTDOOR on 5GHz.
> > > Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> > > Also Russia has never been regulated by ETSI.
> > >
> > > If this looks good, I can send a patch if needed.

Re: wireless-regdb: Update regulatory rules for Russia (RU) on 5GHz

[Seth Forshee]

On Mon, Jul 29, 2019 at 09:05:06PM +0300, Dmitry Tunin wrote:
> I made an error while editing. The correct section is
> 
> country RU:
> (2402 - 2482 @ 40), (20)
> (5170 - 5350 @ 160), (23), NO-OUTDOOR
> (5650 - 5850 @ 160), (23), NO-OUTDOOR
> # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> (57000 - 66000 @ 2160), (40), NO-OUTDOOR

Thanks. I haven't had time to look over the document to verify your
proposed changes, but I would encourage you to go ahead and send a
patch. I will try to look this over soon.

Thanks,
Seth

> 
> вт, 23 июл. 2019 г. в 00:53, Dmitry Tunin :
> >
> > The db entry looks like this now
> >
> > country RU: DFS-ETSI
> > (2402 - 2482 @ 40), (20)
> > (5170 - 5250 @ 80), (20), AUTO-BW
> > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > (5650 - 5730 @ 80), (30), DFS
> > (5735 - 5835 @ 80), (30)
> > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > (57000 - 66000 @ 2160), (40)
> >
> >
> > This doesn't look correct. The regulation document is here
> > http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
> >
> > According to the regulation document issued Feb 29 2016, there
> > frequencies should look like this:
> >
> > country RU:
> > (2402 - 2482 @ 40), (20)
> > (5170 - 5330 @ 160), (23), NO-OUTDOOR
> > (5650 - 5835 @ 160), (23), NO-OUTDOOR
> > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > (57000 - 66000 @ 2160), (40), NO-OUTDOOR
> >
> > Note that there was never a DFS requirement in Russia, but always was
> > NO-OUTDOOR on 5GHz.
> > Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> > Also Russia has never been regulated by ETSI.
> >
> > If this looks good, I can send a patch if needed.

Re: wireless-regdb: Update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

I made an error while editing. The correct section is

country RU:
(2402 - 2482 @ 40), (20)
(5170 - 5350 @ 160), (23), NO-OUTDOOR
(5650 - 5850 @ 160), (23), NO-OUTDOOR
# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
(57000 - 66000 @ 2160), (40), NO-OUTDOOR

вт, 23 июл. 2019 г. в 00:53, Dmitry Tunin :
>
> The db entry looks like this now
>
> country RU: DFS-ETSI
> (2402 - 2482 @ 40), (20)
> (5170 - 5250 @ 80), (20), AUTO-BW
> (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> (5650 - 5730 @ 80), (30), DFS
> (5735 - 5835 @ 80), (30)
> # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> (57000 - 66000 @ 2160), (40)
>
>
> This doesn't look correct. The regulation document is here
> http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
>
> According to the regulation document issued Feb 29 2016, there
> frequencies should look like this:
>
> country RU:
> (2402 - 2482 @ 40), (20)
> (5170 - 5330 @ 160), (23), NO-OUTDOOR
> (5650 - 5835 @ 160), (23), NO-OUTDOOR
> # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> (57000 - 66000 @ 2160), (40), NO-OUTDOOR
>
> Note that there was never a DFS requirement in Russia, but always was
> NO-OUTDOOR on 5GHz.
> Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> Also Russia has never been regulated by ETSI.
>
> If this looks good, I can send a patch if needed.

[PATCH] wireless-regdb: Extend 5470-5725 MHz range to 5730 MHz for Taiwan (TW)

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
The Linux kernel however does not seem capable of considering them
most restrictive subset of multiple rules.

Since 5725 ~ 5730 MHz belongs to the next range which has looser
requirements, we can do this manually and extend the range by 5 MHz
to make the kernel happy and be able to use channel 144.

Also, looking at the US regulations, which the TW ones are based on,
The DFS range ends at 5730 MHz, while the next range starts at 5735
MHz. This doesn't match the actual regulations, but is skewed to meet
wireless channel boundaries. I prefer the database match the law,
and be adjuested only if necessary.

Signed-off-by: Chen-Yu Tsai 
---

I have a vague impression that you asked about the range boundaries
when I first updated the rules for Taiwan. And here we are again.

---
 db.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index 37393e6..2e149b6 100644
--- a/db.txt
+++ b/db.txt
@@ -1249,7 +1249,11 @@ country TW: DFS-FCC
# 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
(5150 - 5250 @ 80), (23), AUTO-BW
(5250 - 5350 @ 80), (23), DFS, AUTO-BW
-   (5470 - 5725 @ 160), (23), DFS
+   # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
+   # Since 5725 ~ 5730 MHz belongs to the next range which has looser
+   # requirements, we can extend the range by 5 MHz to make the kernel
+   # happy and be able to use channel 144.
+   (5470 - 5730 @ 160), (23), DFS
(5725 - 5850 @ 80), (30)
# 60g band, LP0002 section 3.13.1.1 (3)(C), EIRP=40dBm(43dBm peak)
(57000 - 66000 @ 2160), (40)
-- 
2.20.1

Re: [PATCH wireless-drivers-next v2] mwifiex: use eth_broadcast_addr() to assign broadcast address

[Kalle Valo]

Mao Wenan  wrote:

> This patch is to use eth_broadcast_addr() to assign broadcast address
> insetad of memcpy().
> 
> Signed-off-by: Mao Wenan 

Patch applied to wireless-drivers-next.git, thanks.

15e830e90fde mwifiex: use eth_broadcast_addr() to assign broadcast address

-- 
https://patchwork.kernel.org/patch/11056129/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH wireless-drivers-next v2] mwifiex: use eth_broadcast_addr() to assign broadcast address

[Mao Wenan]

This patch is to use eth_broadcast_addr() to assign broadcast address
insetad of memcpy().

Signed-off-by: Mao Wenan 
---
 v1->v2: change subject from net-next to wireless-drivers-next.
 
 drivers/net/wireless/marvell/mwifiex/tdls.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/tdls.c 
b/drivers/net/wireless/marvell/mwifiex/tdls.c
index 18e654d..0931304 100644
--- a/drivers/net/wireless/marvell/mwifiex/tdls.c
+++ b/drivers/net/wireless/marvell/mwifiex/tdls.c
@@ -731,7 +731,6 @@ mwifiex_construct_tdls_action_frame(struct mwifiex_private 
*priv,
u16 status_code, struct sk_buff *skb)
 {
struct ieee80211_mgmt *mgmt;
-   u8 bc_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
int ret;
u16 capab;
struct ieee80211_ht_cap *ht_cap;
@@ -765,7 +764,7 @@ mwifiex_construct_tdls_action_frame(struct mwifiex_private 
*priv,
memmove(pos + ETH_ALEN, &mgmt->u.action.category,
sizeof(mgmt->u.action.u.tdls_discover_resp));
/* init address 4 */
-   memcpy(pos, bc_addr, ETH_ALEN);
+   eth_broadcast_addr(pos);
 
ret = mwifiex_tdls_append_rates_ie(priv, skb);
if (ret) {
-- 
2.7.4

wireless-regdb: Update regulatory rules for Russia (RU) on 5GHz

[Dmitry Tunin]

The db entry looks like this now

country RU: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5650 - 5730 @ 80), (30), DFS
(5735 - 5835 @ 80), (30)
# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
(57000 - 66000 @ 2160), (40)


This doesn't look correct. The regulation document is here
http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf

According to the regulation document issued Feb 29 2016, there
frequencies should look like this:

country RU:
(2402 - 2482 @ 40), (20)
(5170 - 5330 @ 160), (23), NO-OUTDOOR
(5650 - 5835 @ 160), (23), NO-OUTDOOR
# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
(57000 - 66000 @ 2160), (40), NO-OUTDOOR

Note that there was never a DFS requirement in Russia, but always was
NO-OUTDOOR on 5GHz.
Maximum power is 200mW that is ~23dBm on all 5GHz channels.
Also Russia has never been regulated by ETSI.

If this looks good, I can send a patch if needed.

Re: [wireless-regdb] Update to wireless-regdb about Italy

[Seth Forshee]

On Sat, Jul 13, 2019 at 07:10:37PM +0200, g...@inrete.it wrote:
> Hi
> 
> I'm Italian and I work in Italy, I realize that nowadays the regdb entry for
> Italy is as follows:
> 
> country IT: DFS-ETSI
>     (2402 - 2482 @ 40), (20)
>     (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
>     (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
>     (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
>     # 60 GHz band channels 1-4, ref: Etsi En 302 567
>     (57000 - 66000 @ 2160), (40)
> 
> And it misses the lines:
> 
>     # Short Range Devices (SRD) (ETSI EN 300 440)
>     (5725 - 5875 @ 80), (25 mW)
> 
> Common to may European Countries.
> 
> I dug a bit in the current Italian regulation that is online on the website
> of the
> Ministry of Economic Development: https://www.mise.gov.it/index.php/en/
> 
> In the section about the "National Plan of Frequencies" (only in Italian) at
> the URL:
> 
> https://www.mise.gov.it/index.php/it/comunicazioni/radio/pnrf-piano-nazionale-di-ripartizione-delle-frequenze
> 
> 
> Two PDF files are linked:
> 
> --Tabelle di attribuzione Tabella B (27,50 MHz – 10.000 MHz) (pdf)
> https://www.mise.gov.it/images/stories/documenti/Tabella_B_2750_MHz-1_Mhz.pdf
> 
> Which at page 28 allows the use for ISM according to the general European
> legislation: 2006/771/CE ERC/REC 70-03
> 
> --Note (esplicative, di carattere tecnico e con attribuzioni in deroga al
> piano) (pdf)
> https://www.mise.gov.it/images/stories/documenti/NOTE-pnrf.pdf
> Which at page 334, in the paragraph 3.2.3 states in a explicit way the
> permit to operate the in the band 5.725 ÷ 5.875 MHz,
> with SRD and max power at 25 mW.
> 
> According to this regulation there's no reason not to have the:
>  (5725 - 5875 @ 80), (25 mW)
> Inserted for Italy in the regdb
> 
> Who can do it ?

The page/section numbers you gave for the second document don't
correspond to what I'm seeing, but it does look like you are right that
the entry can be added to the regdb. Anyone can send patches for the
regdb, so if you know how to do that please feel free to do so.
Otherwise let me know and I can prepare a patch.

Thanks,
Seth

Re: [PATCH v3 20/24] wireless: Remove call to memset after dma_alloc_coherent

[Kalle Valo]

(adding back linux-wireless, please don't drop CC)

> Kalle Valo  於 2019年7月15日週一 下午5:07寫道：
>>
>> Fuqian Huang  writes:
>>
>> > In commit 518a2f1925c3
>> > ("dma-mapping: zero memory returned from dma_alloc_*"),
>> > dma_alloc_coherent has already zeroed the memory.
>> > So memset is not needed.
>> >
>> > Signed-off-by: Fuqian Huang 
>> > ---
>> > Changes in v3:
>> >   - Use actual commit rather than the merge commit in the commit message
>> >
>> >  drivers/net/wireless/ath/ath10k/ce.c | 5 -
>> >  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c  | 2 --
>> >  drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 2 --
>> >  drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c | 2 --
>> >  4 files changed, 11 deletions(-)
>>
>> Via which tree is this supposed to go? Can I take this to
>> wireless-drivers-next?
>
> I think the wireless-drivers-next is fine.

Good, I'll then take these to my queue.

> The four file have similar changes. And they are both under wireless
> subsystem. How should i indicate which tree the patch should go to?
> Should I mark them in [patch v3 wireless] or after the Changes in v3?
> I should avoid this mistake next time.

As there's no dependency between patches to me the easiest is that you
send the wireless patches separately, that way I can take them directly
without asking anything, and not worry about dependencies or if someone
else is going to apply them. For example Colin King does that his
cleanup patches and I like it a lot.

But if I see patch 20/24 (and only that, no cover letter or over
patches) I have no clue what the plan is and need extra effort to
understand what I should do.

-- 
Kalle Valo

Update to wireless-regdb about Italy

[gb]

Hi

I'm Italian and I work in Italy, I realize that nowadays the regdb entry 
for Italy is as follows:


country IT: DFS-ETSI
    (2402 - 2482 @ 40), (20)
    (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
    (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
    (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
    # 60 GHz band channels 1-4, ref: Etsi En 302 567
    (57000 - 66000 @ 2160), (40)

And it misses the lines:

    # Short Range Devices (SRD) (ETSI EN 300 440)
    (5725 - 5875 @ 80), (25 mW)

Common to may European Countries.

I dug a bit in the current Italian regulation that is online on the 
website of the

Ministry of Economic Development: https://www.mise.gov.it/index.php/en/

In the section about the "National Plan of Frequencies" (only in 
Italian) at the URL:


https://www.mise.gov.it/index.php/it/comunicazioni/radio/pnrf-piano-nazionale-di-ripartizione-delle-frequenze 



Two PDF files are linked:

--Tabelle di attribuzione Tabella B (27,50 MHz – 10.000 MHz) (pdf)
https://www.mise.gov.it/images/stories/documenti/Tabella_B_2750_MHz-1_Mhz.pdf 

Which at page 28 allows the use for ISM according to the general 
European legislation: 2006/771/CE ERC/REC 70-03


--Note (esplicative, di carattere tecnico e con attribuzioni in deroga 
al piano) (pdf)

https://www.mise.gov.it/images/stories/documenti/NOTE-pnrf.pdf
Which at page 334, in the paragraph 3.2.3 states in a explicit way the 
permit to operate the in the band 5.725 ÷ 5.875 MHz,

with SRD and max power at 25 mW.

According to this regulation there's no reason not to have the:
 (5725 - 5875 @ 80), (25 mW)
Inserted for Italy in the regdb

Who can do it ?

--

Giorgio Bernardi

Re: [PATCH] wireless-regdb: Fix overlapping ranges for Switzerland and Liechtenstein

[Seth Forshee]

On Tue, Jul 02, 2019 at 04:19:44PM +0200, Martin Willi wrote:
> The commit referenced below changes the 5GHz frequency range 5250-5330
> to 5150-5330, making that range overlapping with the existing range
> 5170-5250. This imposes DFS limitations and a reduced maximum power
> level for the range 5170-5250.
> 
> The change of the frequency range seems not intentional. Instead the
> commit should have changed the 5170-5250 range to 5150-5250, and the
> 5250-5330 range to 5250-5350 (see [1]).
> 
> [1] https://www.ofcomnet.ch/api/rir/1010/05
> 
> Fixes: 957a7cff72a3 ("wireless-regdb: update regulatory rules for Switzerland 
> (CH), and Liechtenstein (LI) on 5GHz")
> Signed-off-by: Martin Willi 

Applied, thanks!

[PATCH] wireless: core: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Johannes Berg 
Cc: "David S. Miller" 
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
---
 net/wireless/core.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 037816163e70..339b0ccb3241 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -142,12 +142,10 @@ int cfg80211_dev_rename(struct cfg80211_registered_device 
*rdev,
if (result)
return result;
 
-   if (rdev->wiphy.debugfsdir &&
-   !debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
-   rdev->wiphy.debugfsdir,
-   rdev->wiphy.debugfsdir->d_parent,
-   newname))
-   pr_err("failed to rename debugfs dir to %s!\n", newname);
+   if (rdev->wiphy.debugfsdir)
+   debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
+  rdev->wiphy.debugfsdir,
+  rdev->wiphy.debugfsdir->d_parent, newname);
 
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
 
@@ -886,11 +884,8 @@ int wiphy_register(struct wiphy *wiphy)
cfg80211_rdev_list_generation++;
 
/* add to debugfs */
-   rdev->wiphy.debugfsdir =
-   debugfs_create_dir(wiphy_name(&rdev->wiphy),
-  ieee80211_debugfs_dir);
-   if (IS_ERR(rdev->wiphy.debugfsdir))
-   rdev->wiphy.debugfsdir = NULL;
+   rdev->wiphy.debugfsdir = debugfs_create_dir(wiphy_name(&rdev->wiphy),
+   ieee80211_debugfs_dir);
 
cfg80211_debugfs_rdev_add(rdev);
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
-- 
2.22.0

[PATCH] wireless-regdb: Fix overlapping ranges for Switzerland and Liechtenstein

[Martin Willi]

The commit referenced below changes the 5GHz frequency range 5250-5330
to 5150-5330, making that range overlapping with the existing range
5170-5250. This imposes DFS limitations and a reduced maximum power
level for the range 5170-5250.

The change of the frequency range seems not intentional. Instead the
commit should have changed the 5170-5250 range to 5150-5250, and the
5250-5330 range to 5250-5350 (see [1]).

[1] https://www.ofcomnet.ch/api/rir/1010/05

Fixes: 957a7cff72a3 ("wireless-regdb: update regulatory rules for Switzerland 
(CH), and Liechtenstein (LI) on 5GHz")
Signed-off-by: Martin Willi 
---
 db.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/db.txt b/db.txt
index d47ab94c3aa5..37393e6a793e 100644
--- a/db.txt
+++ b/db.txt
@@ -271,8 +271,8 @@ country CF: DFS-FCC
 # transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
 country CH: DFS-ETSI
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
-   (5150 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -747,8 +747,8 @@ country LC: DFS-ETSI
 # transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
 country LI: DFS-ETSI
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
-   (5150 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
-- 
2.17.1

Re: [PATCH] wireless: wil6210: no need to check return value of debugfs_create functions

[Kalle Valo]

Greg Kroah-Hartman  wrote:

> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
> 
> Cc: Maya Erez 
> Cc: Kalle Valo 
> Cc: "David S. Miller" 
> Cc: linux-wireless@vger.kernel.org
> Cc: wil6...@qti.qualcomm.com
> Signed-off-by: Greg Kroah-Hartman 
> Reviewed-by: Maya Erez 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

ce564170dfe5 wil6210: no need to check return value of debugfs_create functions

-- 
https://patchwork.kernel.org/patch/10988197/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v4 wireless-drivers] mt76: usb: fix rx A-MSDU support

[Kalle Valo]

Lorenzo Bianconi  wrote:

> Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> receive frames up to q->buf_size but they will be discarded in
> mt76u_process_rx_entry since there is no enough room for
> skb_shared_info. Fix the issue reallocating the skb and copying in the
> linear area the first 128B of the received frames and in the frag_list
> the remaining part
> 
> Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for 
> rx")
> Signed-off-by: Lorenzo Bianconi 

Patch applied to wireless-drivers.git, thanks.

2a92b08b1855 mt76: usb: fix rx A-MSDU support

-- 
https://patchwork.kernel.org/patch/10997119/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH] wireless: fix netlink vendor commands

[Johannes Berg]

From: Johannes Berg 

In my previous commit to validate a policy I neglected to
actually add one to the few drivers using vendor commands,
fix that now.

Reported-by: Tony Lindgren 
Tested-by: Tony Lindgren 
Fixes: 901bb9891855 ("nl80211: require and validate vendor command policy")
Signed-off-by: Johannes Berg 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c   | 4 
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 1 +
 drivers/net/wireless/ti/wlcore/vendor_cmd.c   | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 804955d24b30..37ac95940c22 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -177,6 +177,7 @@ static const struct wiphy_vendor_command 
wil_nl80211_vendor_commands[] = {
.info.subcmd = QCA_NL80211_VENDOR_SUBCMD_DMG_RF_GET_SECTOR_CFG,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
 WIPHY_VENDOR_CMD_NEED_RUNNING,
+   .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_get_cfg
},
{
@@ -184,6 +185,7 @@ static const struct wiphy_vendor_command 
wil_nl80211_vendor_commands[] = {
.info.subcmd = QCA_NL80211_VENDOR_SUBCMD_DMG_RF_SET_SECTOR_CFG,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
 WIPHY_VENDOR_CMD_NEED_RUNNING,
+   .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_set_cfg
},
{
@@ -192,6 +194,7 @@ static const struct wiphy_vendor_command 
wil_nl80211_vendor_commands[] = {
QCA_NL80211_VENDOR_SUBCMD_DMG_RF_GET_SELECTED_SECTOR,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
 WIPHY_VENDOR_CMD_NEED_RUNNING,
+   .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_get_selected
},
{
@@ -200,6 +203,7 @@ static const struct wiphy_vendor_command 
wil_nl80211_vendor_commands[] = {
QCA_NL80211_VENDOR_SUBCMD_DMG_RF_SET_SELECTED_SECTOR,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
 WIPHY_VENDOR_CMD_NEED_RUNNING,
+   .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_set_selected
},
 };
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index d493021f6031..30ebadc5e5bb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -123,6 +123,7 @@ const struct wiphy_vendor_command brcmf_vendor_cmds[] = {
},
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
 WIPHY_VENDOR_CMD_NEED_NETDEV,
+   .policy = VENDOR_CMD_RAW_DATA,
.doit = brcmf_cfg80211_vndr_cmds_dcmd_handler
},
 };
diff --git a/drivers/net/wireless/ti/wlcore/vendor_cmd.c 
b/drivers/net/wireless/ti/wlcore/vendor_cmd.c
index 5cf0b32c413b..e1bd344c4ebc 100644
--- a/drivers/net/wireless/ti/wlcore/vendor_cmd.c
+++ b/drivers/net/wireless/ti/wlcore/vendor_cmd.c
@@ -163,6 +163,7 @@ static const struct wiphy_vendor_command 
wlcore_vendor_commands[] = {
.flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
 WIPHY_VENDOR_CMD_NEED_RUNNING,
.doit = wlcore_vendor_cmd_smart_config_start,
+   .policy = wlcore_vendor_attr_policy,
},
{
.info = {
@@ -172,6 +173,7 @@ static const struct wiphy_vendor_command 
wlcore_vendor_commands[] = {
.flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
 WIPHY_VENDOR_CMD_NEED_RUNNING,
.doit = wlcore_vendor_cmd_smart_config_stop,
+   .policy = wlcore_vendor_attr_policy,
},
{
.info = {
@@ -181,6 +183,7 @@ static const struct wiphy_vendor_command 
wlcore_vendor_commands[] = {
.flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
 WIPHY_VENDOR_CMD_NEED_RUNNING,
.doit = wlcore_vendor_cmd_smart_config_set_group_key,
+   .policy = wlcore_vendor_attr_policy,
},
 };
 
-- 
2.17.2

Re: [PATCH] wireless: wil6210: no need to check return value of debugfs_create functions

[merez]

On 2019-06-11 22:10, Greg Kroah-Hartman wrote:

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Maya Erez 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: linux-wireless@vger.kernel.org
Cc: wil6...@qti.qualcomm.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/wireless/ath/wil6210/debugfs.c | 80 ++
 1 file changed, 22 insertions(+), 58 deletions(-)



Reviewed-by: Maya Erez 

--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames

[Lorenzo Bianconi]

> On Fri, Jun 14, 2019 at 02:46:36PM +0200, Lorenzo Bianconi wrote:
> > > > 
> > > > ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree
> > > > 
> > > > > 
> > > > > > +   int i, data_size;
> > > > > >  
> > > > > > +   data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > > > > > + 
> > > > > > dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
> > > > > > for (i = 0; i < nsgs; i++) {
> > > > > > struct page *page;
> > > > > > void *data;
> > > > > > @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct 
> > > > > > mt76_queue *q, struct urb *urb,
> > > > > >  
> > > > > > page = virt_to_head_page(data);
> > > > > > offset = data - page_address(page);
> > > > > > -   sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> > > > > > +   sg_set_page(&urb->sg[i], page, data_size, offset);
> > > > > 
> > > > > > -   q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
> > > > > > q->ndesc = MT_NUM_RX_ENTRIES;
> > > > > > +   q->buf_size = PAGE_SIZE;
> > > > > > +
> > > > > 
> > > > > This should be associated with decrease of MT_SG_MAX_SIZE to value 
> > > > > that
> > > > > is actually needed and currently this is 2 for 4k AMSDU.
> > > > 
> > > > MT_SG_MAX_SIZE is used even on tx side and I do not think we will end 
> > > > up with a
> > > > huge difference here
> > > 
> > > So use different value as argument for mt76u_fill_rx_sg() in
> > > mt76u_rx_urb_alloc(). After changing buf_size to PAGE_SIZE we will
> > > allocate 8 pages per rx queue entry, but only 2 pages will be used
> > > (with data_size change, 1 without data_size change). Or I'm wrong?
> > 
> > yes, it is right (we will use two pages with data_size change). Maybe 
> > better to
> > use 4 pages for each rx queue entry? (otherwise we will probably change it 
> > in
> > the future)
> 
> We should not allocate more than is required. If support for bigger
> rx AMSDUs will be added and announced in vht/ht capabilities to remote
> stations, then increase of number of segments will be needed.
> 
> > > > > However I don't think allocating 2 pages to avoid ieee80211 header 
> > > > > and SNAP
> > > > > copy is worth to do. For me best approach would be allocate 1 page for
> > > > > 4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without 
> > > > > data_size
> > > > > change to avoid 32B copying).
> > > > 
> > > > From my point of view it is better to avoid copying if it is possible. 
> > > > Are you
> > > > sure there is no difference?
> > > 
> > > I do not understand what you mean by difference here.
> > 
> > tpt differences, not sure if there are any
> 
> I would not expect any measurable difference in tpt nor in cpu usage
> either way.
> 
> But I think, if some AMSDU subframe will be spited into two fragments,
> data most likely will need to be linearised/copied, at some point before
> passed to application, what will overcome any benefit of avoiding coping
> 802.11 header. Thought, I don't think this somehow will be visible in
> benchmarking.

Sorry for the late reply. I think so.
I will post a v4 soon.

Regards,
Lorenzo

> 
> Stanislaw


signature.asc
Description: PGP signature

Re: [mac80211-next:master 17/20] drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?

[Johannes Berg]

On Mon, 2019-06-17 at 17:57 +0300, Kalle Valo wrote:
> Johannes Berg  writes:
> 
> > On Fri, 2019-06-14 at 16:33 +0200, Greg Kroah-Hartman wrote:
> > 
> > > Did you apply my "[PATCH 3/5] iwlwifi: dvm: no need to check return
> > > value of debugfs_create function" patch also to this tree?  The 5th
> > > patch in the series depended on it :(
> > 
> > Yeah, my bad, sorry about that. I was not paying attention to the "5/5"
> > in patchwork, and the other patches got assigned to other maintainers so
> > I didn't see them there.
> > 
> > I've dropped the patch for now, until that's all sorted out. Or maybe
> > Kalle will just take them all together.
> 
> Maybe it's easier that you just wait for other patches to trickle down
> your tree?

Sure, that works too, whichever you prefer.

johannes

Re: [mac80211-next:master 17/20] drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?

[Kalle Valo]

Johannes Berg  writes:

> On Fri, 2019-06-14 at 16:33 +0200, Greg Kroah-Hartman wrote:
>
>> Did you apply my "[PATCH 3/5] iwlwifi: dvm: no need to check return
>> value of debugfs_create function" patch also to this tree?  The 5th
>> patch in the series depended on it :(
>
> Yeah, my bad, sorry about that. I was not paying attention to the "5/5"
> in patchwork, and the other patches got assigned to other maintainers so
> I didn't see them there.
>
> I've dropped the patch for now, until that's all sorted out. Or maybe
> Kalle will just take them all together.

Maybe it's easier that you just wait for other patches to trickle down
your tree?

-- 
Kalle Valo

[PATCH v4 wireless-drivers] mt76: usb: fix rx A-MSDU support

[Lorenzo Bianconi]

Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
for rx") breaks A-MSDU support. When A-MSDU is enable the device can
receive frames up to q->buf_size but they will be discarded in
mt76u_process_rx_entry since there is no enough room for
skb_shared_info. Fix the issue reallocating the skb and copying in the
linear area the first 128B of the received frames and in the frag_list
the remaining part

Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
Signed-off-by: Lorenzo Bianconi 
---
Changes since v3:
- drop patch 2/3 and 3/3

Changes since v2:
- simplify mt76u_build_rx_skb
- add patch 2/3: mt76u: introduce mt76u_ep data structure
- align usb buffer size to usb max endpoint length
- set buf_size to PAGE_SIZE even for sg case

Changes since v1:
- do not allocate multiple page buffers but rely on fragmented skbs
  if there is no enough space to manage the AMSDU rx packets
---
 drivers/net/wireless/mediatek/mt76/mt76.h |  1 +
 drivers/net/wireless/mediatek/mt76/usb.c  | 46 ++-
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 8ecbf81a906f..889b76deb703 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -30,6 +30,7 @@
 #define MT_TX_RING_SIZE 256
 #define MT_MCU_RING_SIZE32
 #define MT_RX_BUF_SIZE  2048
+#define MT_SKB_HEAD_LEN 128
 
 struct mt76_dev;
 struct mt76_wcid;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
b/drivers/net/wireless/mediatek/mt76/usb.c
index bbaa1365bbda..dd90427b2d67 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -429,6 +429,42 @@ static int mt76u_get_rx_entry_len(u8 *data, u32 data_len)
return dma_len;
 }
 
+static struct sk_buff *
+mt76u_build_rx_skb(void *data, int len, int buf_size)
+{
+   struct sk_buff *skb;
+
+   if (SKB_WITH_OVERHEAD(buf_size) < MT_DMA_HDR_LEN + len) {
+   struct page *page;
+
+   /* slow path, not enough space for data and
+* skb_shared_info
+*/
+   skb = alloc_skb(MT_SKB_HEAD_LEN, GFP_ATOMIC);
+   if (!skb)
+   return NULL;
+
+   skb_put_data(skb, data + MT_DMA_HDR_LEN, MT_SKB_HEAD_LEN);
+   data += (MT_DMA_HDR_LEN + MT_SKB_HEAD_LEN);
+   page = virt_to_head_page(data);
+   skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
+   page, data - page_address(page),
+   len - MT_SKB_HEAD_LEN, buf_size);
+
+   return skb;
+   }
+
+   /* fast path */
+   skb = build_skb(data, buf_size);
+   if (!skb)
+   return NULL;
+
+   skb_reserve(skb, MT_DMA_HDR_LEN);
+   __skb_put(skb, len);
+
+   return skb;
+}
+
 static int
 mt76u_process_rx_entry(struct mt76_dev *dev, struct urb *urb)
 {
@@ -446,19 +482,11 @@ mt76u_process_rx_entry(struct mt76_dev *dev, struct urb 
*urb)
return 0;
 
data_len = min_t(int, len, data_len - MT_DMA_HDR_LEN);
-   if (MT_DMA_HDR_LEN + data_len > SKB_WITH_OVERHEAD(q->buf_size)) {
-   dev_err_ratelimited(dev->dev, "rx data too big %d\n", data_len);
-   return 0;
-   }
-
-   skb = build_skb(data, q->buf_size);
+   skb = mt76u_build_rx_skb(data, data_len, q->buf_size);
if (!skb)
return 0;
 
-   skb_reserve(skb, MT_DMA_HDR_LEN);
-   __skb_put(skb, data_len);
len -= data_len;
-
while (len > 0 && nsgs < urb->num_sgs) {
data_len = min_t(int, len, urb->sg[nsgs].length);
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
-- 
2.21.0

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Lorenzo Bianconi]

>
> On Fri, Jun 14, 2019 at 12:20:59PM +0200, Johannes Berg wrote:
> > On Fri, 2019-06-14 at 12:11 +0200, Lorenzo Bianconi wrote:
> >
> > > Looking at __ieee80211_amsdu_copy() now I got why other drivers copy 
> > > hdrlen +
> > > 8, thx :)
> > > In our case reuse_frag is true in __ieee80211_amsdu_copy, so we will end 
> > > up
> > > copying 32B + ether_len. Anyway I think 32 is a little bit too low and we 
> > > could get
> > > better performances increasing it a little bit.
> > > A typical use case (e.g IPv6 + TCP):
> > >
> > > IPv6 = 40B, TCP = 32B --> so 72B..I guess 128B is a good value :)
> > > @Felix, Johannes: what do you think?
> >
> > I think while we might *allocate* more, I don't think we should *copy*
> > more, since then the TCP payload will no longer be in pages.
> >
> > It'd probably be better to implement leaving enough tailroom (allocate
> > 128), but copying nothing, unless the *entire* packet fits.
>
> iwl4965 put entire packet in fragment in il4965_pass_packet_to_mac80211() .
> Initially I thought this is a bug, since mac80211 require header be
> in the linear area, but looks like ieee80211_rx_monitor() copy header
> before rest of mac80211 check it, so 4965 is fine.
>
> Anyway I think the driver should put ieee80211 header in linear area
> and iwlwifi & mt7601u implementation is somewhat optimal.

Actually the case is a little bit different for mt76 since we need
even mt76x02_rxwi in the linear area of the received skb.
Taking that into account the requested size to copy will be:
32 + 802.11 hdr + SNAP hdr  = ~ 70B
Moreover to pass rxwi size to usb module we need to add a field in
mt76_driver_ops (e.g rxwi_size).
I will carry out some tests and if there are no differences I will
post a single patch to wireless-drivers using 128B as default size

Regards,
Lorenzo

>
> Stanislaw

Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames

[Stanislaw Gruszka]

On Fri, Jun 14, 2019 at 02:46:36PM +0200, Lorenzo Bianconi wrote:
> > > 
> > > ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree
> > > 
> > > > 
> > > > > + int i, data_size;
> > > > >  
> > > > > + data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > > > > +   
> > > > > dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
> > > > >   for (i = 0; i < nsgs; i++) {
> > > > >   struct page *page;
> > > > >   void *data;
> > > > > @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct 
> > > > > mt76_queue *q, struct urb *urb,
> > > > >  
> > > > >   page = virt_to_head_page(data);
> > > > >   offset = data - page_address(page);
> > > > > - sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> > > > > + sg_set_page(&urb->sg[i], page, data_size, offset);
> > > > 
> > > > > - q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
> > > > >   q->ndesc = MT_NUM_RX_ENTRIES;
> > > > > + q->buf_size = PAGE_SIZE;
> > > > > +
> > > > 
> > > > This should be associated with decrease of MT_SG_MAX_SIZE to value that
> > > > is actually needed and currently this is 2 for 4k AMSDU.
> > > 
> > > MT_SG_MAX_SIZE is used even on tx side and I do not think we will end up 
> > > with a
> > > huge difference here
> > 
> > So use different value as argument for mt76u_fill_rx_sg() in
> > mt76u_rx_urb_alloc(). After changing buf_size to PAGE_SIZE we will
> > allocate 8 pages per rx queue entry, but only 2 pages will be used
> > (with data_size change, 1 without data_size change). Or I'm wrong?
> 
> yes, it is right (we will use two pages with data_size change). Maybe better 
> to
> use 4 pages for each rx queue entry? (otherwise we will probably change it in
> the future)

We should not allocate more than is required. If support for bigger
rx AMSDUs will be added and announced in vht/ht capabilities to remote
stations, then increase of number of segments will be needed.

> > > > However I don't think allocating 2 pages to avoid ieee80211 header and 
> > > > SNAP
> > > > copy is worth to do. For me best approach would be allocate 1 page for
> > > > 4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without data_size
> > > > change to avoid 32B copying).
> > > 
> > > From my point of view it is better to avoid copying if it is possible. 
> > > Are you
> > > sure there is no difference?
> > 
> > I do not understand what you mean by difference here.
> 
> tpt differences, not sure if there are any

I would not expect any measurable difference in tpt nor in cpu usage
either way.

But I think, if some AMSDU subframe will be spited into two fragments,
data most likely will need to be linearised/copied, at some point before
passed to application, what will overcome any benefit of avoiding coping
802.11 header. Thought, I don't think this somehow will be visible in
benchmarking.

Stanislaw

Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info

[Johannes Berg]

On Fri, 2019-06-14 at 08:14 -0700, Ben Greear wrote:
> 
> 
> So, maybe I return instead the elapsed time in the netlink API instead of a
> timestamp.  I think that will give me the value that I am looking for,
> and I can still print out the 'real' time in iw so any tools reading that
> output and do some simple math and figure out the 'real' associated-at time.

I don't think that's good. There's a delay between filling the message
and then processing it in userspace. We had this in the scan code and
learned that was full of races.

The better thing is to use CLOCK_BOOTTIME nanoseconds, and then
userspace can use clock_gettime() to get the current time etc. and then
do whatever calculations it needs. If it wants to print the realtime
timestamp, it could even calculate that (with some jitter) by doing
clock_gettime() on both realtime and boottime clocks...

johannes

Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info

[Ben Greear]

On 6/14/19 7:56 AM, Johannes Berg wrote:

On Fri, 2019-06-14 at 07:46 -0700, Ben Greear wrote:


The point of my patch was to allow 'iw' to return a more precise time
that the station has been associated, so I am not sure that BOOTIME is
a good thing to use for that?


Depends what you want, really.


+   if (sinfo[NL80211_STA_INFO_ASSOC_AT_MS])
+   printf("\n\tassociated at:\t%llu ms",
+(unsigned long 
long)nla_get_u64(sinfo[NL80211_STA_INFO_ASSOC_AT_MS]));

-   printf("\n");
+   printf("\n\tcurrent time:\t%llu ms\n", now_ms);


Since you just print the time in milliseconds, and the current time in
milliseconds, you don't even really have any value in the wall clock.
Quite the opposite - this lends itself to subtracting to try to figure
out how long it was associated, which is the completely wrong thing to
do with wall clock - timezone adjustment could've happened inbetween,
for example!

I really see no point in trying to give the wall clock at assoc time. If
no timezone adjustment happened, you can just as well give the boottime
and have the userspace figure out the wall clock. If timezone adjustment
happened, then any calculations are wrong anyway, what would the point
be?


So, maybe I return instead the elapsed time in the netlink API instead of a
timestamp.  I think that will give me the value that I am looking for,
and I can still print out the 'real' time in iw so any tools reading that
output and do some simple math and figure out the 'real' associated-at time.

If that sounds good to you, I'll code that up.

Thanks,
Ben



johannes




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [mac80211-next:master 17/20] drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?

[Johannes Berg]

On Fri, 2019-06-14 at 16:33 +0200, Greg Kroah-Hartman wrote:

> Did you apply my "[PATCH 3/5] iwlwifi: dvm: no need to check return
> value of debugfs_create function" patch also to this tree?  The 5th
> patch in the series depended on it :(

Yeah, my bad, sorry about that. I was not paying attention to the "5/5"
in patchwork, and the other patches got assigned to other maintainers so
I didn't see them there.

I've dropped the patch for now, until that's all sorted out. Or maybe
Kalle will just take them all together.

johannes

Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info

[Johannes Berg]

On Fri, 2019-06-14 at 07:46 -0700, Ben Greear wrote:
> 
> The point of my patch was to allow 'iw' to return a more precise time
> that the station has been associated, so I am not sure that BOOTIME is
> a good thing to use for that?

Depends what you want, really.

> +   if (sinfo[NL80211_STA_INFO_ASSOC_AT_MS])
> +   printf("\n\tassociated at:\t%llu ms",
> +(unsigned long 
> long)nla_get_u64(sinfo[NL80211_STA_INFO_ASSOC_AT_MS]));
> 
> -   printf("\n");
> +   printf("\n\tcurrent time:\t%llu ms\n", now_ms);

Since you just print the time in milliseconds, and the current time in
milliseconds, you don't even really have any value in the wall clock.
Quite the opposite - this lends itself to subtracting to try to figure
out how long it was associated, which is the completely wrong thing to
do with wall clock - timezone adjustment could've happened inbetween,
for example!

I really see no point in trying to give the wall clock at assoc time. If
no timezone adjustment happened, you can just as well give the boottime
and have the userspace figure out the wall clock. If timezone adjustment
happened, then any calculations are wrong anyway, what would the point
be?

johannes

Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info

[Ben Greear]

On 6/14/19 6:38 AM, Johannes Berg wrote:

On Mon, 2019-04-15 at 10:21 -0700, gree...@candelatech.com wrote:

From: Ben Greear 

Report time stamp of when sta became associated.


I guess that makes sense.


Signed-off-by: Ben Greear 
---
  include/net/cfg80211.h   | 2 ++
  include/uapi/linux/nl80211.h | 2 ++
  net/wireless/nl80211.c   | 1 +
  3 files changed, 5 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f49eb1464b7a..a3ad78b9d9f4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1268,6 +1268,7 @@ struct cfg80211_tid_stats {
   *indicate the relevant values in this struct for them
   * @connected_time: time(in secs) since a station is last connected
   * @inactive_time: time since last station activity (tx/rx) in milliseconds
+ * @assoc_at_ms: time in ms of the last association


I think the "_at_ms" doesn't really make sense. "time in ms" also
doesn't make sense as documentation. I think you need to say what should
be assigned here.

Also, you're actually using ktime_get_real() for this, which again
doesn't make much sense. For exposing an absolute time, I think we're
better off with CLOCK_BOOTTIME like we use elsewhere:


The point of my patch was to allow 'iw' to return a more precise time
that the station has been associated, so I am not sure that BOOTIME is
a good thing to use for that?

Here are the pertinent parts of my iw patches:


diff --git a/station.c b/station.c
index 25cbbc3..e7738cc 100644
--- a/station.c
+++ b/station.c
@@ -314,6 +314,12 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
[NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
};
char *chain;
+   struct timeval now;
+   unsigned long long now_ms;
+
+   gettimeofday(&now, NULL);
+   now_ms = now.tv_sec * 1000;
+   now_ms += (now.tv_usec / 1000);

nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
  genlmsg_attrlen(gnlh, 0), NULL);
@@ -557,8 +563,11 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
if (sinfo[NL80211_STA_INFO_CONNECTED_TIME])
printf("\n\tconnected time:\t%u seconds",
nla_get_u32(sinfo[NL80211_STA_INFO_CONNECTED_TIME]));
+   if (sinfo[NL80211_STA_INFO_ASSOC_AT_MS])
+   printf("\n\tassociated at:\t%llu ms",
+(unsigned long 
long)nla_get_u64(sinfo[NL80211_STA_INFO_ASSOC_AT_MS]));

-   printf("\n");
+   printf("\n\tcurrent time:\t%llu ms\n", now_ms);
return NL_SKIP;
 }


Thanks,
Ben



  * @boottime_ns: CLOCK_BOOTTIME timestamp the frame was received at, this is
  *  needed only for beacons and probe responses that update the scan cache.



+ * @NL80211_STA_INFO_ASSOC_AT_MS: Timestamp of last association


_ASSOC_TIMESTAMP or something would make more sense too as the attribute
name, and clearly the documentation needs to spell out the semantics
here too.

johannes




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [mac80211-next:master 17/20] drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?

[Greg Kroah-Hartman]

On Fri, Jun 14, 2019 at 09:17:28PM +0800, kbuild test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
> head:   499169fb3a5a27b8322cdd559a09e79e390c211b
> commit: d3f7e94bc458dd1b20bef591ee2b82e2ae631858 [17/20] mac80211: remove 
> unused and unneeded remove_sta_debugfs callback
> config: xtensa-allyesconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 7.4.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout d3f7e94bc458dd1b20bef591ee2b82e2ae631858
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=xtensa 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> All errors (new ones prefixed by >>):
> 
> >> drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct 
> >> rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 
> >> 'add_sta_debugfs'?
>  .remove_sta_debugfs = rs_remove_debugfs,
>   ^~
>   add_sta_debugfs

Did you apply my "[PATCH 3/5] iwlwifi: dvm: no need to check return
value of debugfs_create function" patch also to this tree?  The 5th
patch in the series depended on it :(

thanks,

greg k-h


> >> drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:24: error: initialization 
> >> from incompatible pointer type [-Werror=incompatible-pointer-types]
>  .remove_sta_debugfs = rs_remove_debugfs,
>^
>drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:24: note: (near 
> initialization for 'rs_ops.get_expected_throughput')
>cc1: some warnings being treated as errors
> --
> >> drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:3: error: 'const struct 
> >> rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 
> >> 'add_sta_debugfs'?
>  .remove_sta_debugfs = rs_remove_sta_debugfs,
>   ^~
>   add_sta_debugfs
> >> drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:24: error: initialization 
> >> from incompatible pointer type [-Werror=incompatible-pointer-types]
>  .remove_sta_debugfs = rs_remove_sta_debugfs,
>^
>drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:24: note: (near 
> initialization for 'rs_mvm_ops_drv.get_expected_throughput')
>cc1: some warnings being treated as errors
> --
> >> drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:3: error: 'const 
> >> struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you 
> >> mean 'add_sta_debugfs'?
>  .remove_sta_debugfs = il4965_rs_remove_debugfs,
>   ^~
>   add_sta_debugfs
> >> drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:24: error: 
> >> initialization from incompatible pointer type 
> >> [-Werror=incompatible-pointer-types]
>  .remove_sta_debugfs = il4965_rs_remove_debugfs,
>^~~~
>drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:24: note: (near 
> initialization for 'rs_4965_ops.get_expected_throughput')
>cc1: some warnings being treated as errors
> 
> vim +3317 drivers/net/wireless/intel/iwlwifi/dvm/rs.c
> 
> 631ad703b drivers/net/wireless/iwlwifi/dvm/rs.c  Johannes Berg   
> 2014-01-20  3305  
> 631ad703b drivers/net/wireless/iwlwifi/dvm/rs.c  Johannes Berg   
> 2014-01-20  3306  static const struct rate_control_ops rs_ops = {
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  
> 2007-09-25  3307 .name = RS_NAME,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  
> 2007-09-25  3308 .tx_status = rs_tx_status,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi      
> 2007-09-25  3309 .get_rate = rs_get_rate,
> fe6b23dd3 drivers/net/wireless/iwlwifi/iwl-agn-rs.c  Reinette Chatre 
> 2010-02-22  3310 .rate_init = rs_rate_init_stub,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  
> 2007-09-25  3311 .alloc = rs_alloc,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  
> 2007-09-25  3312 .free = rs_free,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  
> 2007-09-25  3313 .alloc_sta = rs_alloc_sta,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  
> 2

Re: [PATCH 1/3] net: wireless: trace: add trace for tx_mgmt_expired

[Johannes Berg]

Applied, but

 * I squashed 1 and 2, there's no point in 1 standalone
 * please be more careful with indentation in the future,
   I fixed a few places.

johannes

Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info

[Johannes Berg]

On Mon, 2019-04-15 at 10:21 -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> Report time stamp of when sta became associated.

I guess that makes sense.

> Signed-off-by: Ben Greear 
> ---
>  include/net/cfg80211.h   | 2 ++
>  include/uapi/linux/nl80211.h | 2 ++
>  net/wireless/nl80211.c   | 1 +
>  3 files changed, 5 insertions(+)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index f49eb1464b7a..a3ad78b9d9f4 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1268,6 +1268,7 @@ struct cfg80211_tid_stats {
>   *   indicate the relevant values in this struct for them
>   * @connected_time: time(in secs) since a station is last connected
>   * @inactive_time: time since last station activity (tx/rx) in milliseconds
> + * @assoc_at_ms: time in ms of the last association

I think the "_at_ms" doesn't really make sense. "time in ms" also
doesn't make sense as documentation. I think you need to say what should
be assigned here.

Also, you're actually using ktime_get_real() for this, which again
doesn't make much sense. For exposing an absolute time, I think we're
better off with CLOCK_BOOTTIME like we use elsewhere:

 * @boottime_ns: CLOCK_BOOTTIME timestamp the frame was received at, this is
 *  needed only for beacons and probe responses that update the scan cache.


> + * @NL80211_STA_INFO_ASSOC_AT_MS: Timestamp of last association

_ASSOC_TIMESTAMP or something would make more sense too as the attribute
name, and clearly the documentation needs to spell out the semantics
here too.

johannes

[mac80211-next:master 17/20] drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
head:   499169fb3a5a27b8322cdd559a09e79e390c211b
commit: d3f7e94bc458dd1b20bef591ee2b82e2ae631858 [17/20] mac80211: remove 
unused and unneeded remove_sta_debugfs callback
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d3f7e94bc458dd1b20bef591ee2b82e2ae631858
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=xtensa 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

>> drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct 
>> rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 
>> 'add_sta_debugfs'?
 .remove_sta_debugfs = rs_remove_debugfs,
  ^~
  add_sta_debugfs
>> drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:24: error: initialization 
>> from incompatible pointer type [-Werror=incompatible-pointer-types]
 .remove_sta_debugfs = rs_remove_debugfs,
   ^
   drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:24: note: (near 
initialization for 'rs_ops.get_expected_throughput')
   cc1: some warnings being treated as errors
--
>> drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:3: error: 'const struct 
>> rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 
>> 'add_sta_debugfs'?
 .remove_sta_debugfs = rs_remove_sta_debugfs,
  ^~
  add_sta_debugfs
>> drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:24: error: initialization 
>> from incompatible pointer type [-Werror=incompatible-pointer-types]
 .remove_sta_debugfs = rs_remove_sta_debugfs,
   ^
   drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:24: note: (near 
initialization for 'rs_mvm_ops_drv.get_expected_throughput')
   cc1: some warnings being treated as errors
--
>> drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:3: error: 'const struct 
>> rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 
>> 'add_sta_debugfs'?
 .remove_sta_debugfs = il4965_rs_remove_debugfs,
  ^~
  add_sta_debugfs
>> drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:24: error: 
>> initialization from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 .remove_sta_debugfs = il4965_rs_remove_debugfs,
   ^~~~
   drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:24: note: (near 
initialization for 'rs_4965_ops.get_expected_throughput')
   cc1: some warnings being treated as errors

vim +3317 drivers/net/wireless/intel/iwlwifi/dvm/rs.c

631ad703b drivers/net/wireless/iwlwifi/dvm/rs.c  Johannes Berg   2014-01-20 
 3305  
631ad703b drivers/net/wireless/iwlwifi/dvm/rs.c      Johannes Berg   2014-01-20 
 3306  static const struct rate_control_ops rs_ops = {
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3307   .name = RS_NAME,
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3308   .tx_status = rs_tx_status,
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3309   .get_rate = rs_get_rate,
fe6b23dd3 drivers/net/wireless/iwlwifi/iwl-agn-rs.c  Reinette Chatre 2010-02-22 
 3310   .rate_init = rs_rate_init_stub,
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3311   .alloc = rs_alloc,
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3312   .free = rs_free,
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3313   .alloc_sta = rs_alloc_sta,
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3314   .free_sta = rs_free_sta,
93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-27 
 3315  #ifdef CONFIG_MAC80211_DEBUGFS
93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi      2007-09-27 
 3316   .add_sta_debugfs = rs_add_debugfs,
93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-27 
@3317   .remove_sta_debugfs = rs_remove_debugfs,
93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-27 
 3318  #endif
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3319  };
b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi  2007-09-25 
 3320  

:: The code at line 3317 was first introduced by

Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames

[Lorenzo Bianconi]

> On Fri, Jun 14, 2019 at 12:22:48PM +0200, Lorenzo Bianconi wrote:
> > > On Thu, Jun 13, 2019 at 11:43:13PM +0200, Lorenzo Bianconi wrote:
> > > > Set usb buffer size taking into account skb_shared_info in order to
> > > > not always copy the first part of received frames if A-MSDU is enabled
> > > > for SG capable devices. Moreover align usb buffer size to max_ep
> > > > boundaries and set buf_size to PAGE_SIZE even for sg case
> > > 
> > > I think this should not be applied to wirless-drivers, only first patch
> > > that fix the bug and optimizations should be done in -next.
> > 
> > ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree
> > 
> > > 
> > > > +   int i, data_size;
> > > >  
> > > > +   data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > > > + 
> > > > dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
> > > > for (i = 0; i < nsgs; i++) {
> > > > struct page *page;
> > > > void *data;
> > > > @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct 
> > > > mt76_queue *q, struct urb *urb,
> > > >  
> > > > page = virt_to_head_page(data);
> > > > offset = data - page_address(page);
> > > > -   sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> > > > +   sg_set_page(&urb->sg[i], page, data_size, offset);
> > > 
> > > > -   q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
> > > > q->ndesc = MT_NUM_RX_ENTRIES;
> > > > +   q->buf_size = PAGE_SIZE;
> > > > +
> > > 
> > > This should be associated with decrease of MT_SG_MAX_SIZE to value that
> > > is actually needed and currently this is 2 for 4k AMSDU.
> > 
> > MT_SG_MAX_SIZE is used even on tx side and I do not think we will end up 
> > with a
> > huge difference here
> 
> So use different value as argument for mt76u_fill_rx_sg() in
> mt76u_rx_urb_alloc(). After changing buf_size to PAGE_SIZE we will
> allocate 8 pages per rx queue entry, but only 2 pages will be used
> (with data_size change, 1 without data_size change). Or I'm wrong?

yes, it is right (we will use two pages with data_size change). Maybe better to
use 4 pages for each rx queue entry? (otherwise we will probably change it in
the future)

> 
> > > However I don't think allocating 2 pages to avoid ieee80211 header and 
> > > SNAP
> > > copy is worth to do. For me best approach would be allocate 1 page for
> > > 4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without data_size
> > > change to avoid 32B copying).
> > 
> > From my point of view it is better to avoid copying if it is possible. Are 
> > you
> > sure there is no difference?
> 
> I do not understand what you mean by difference here.

tpt differences, not sure if there are any

Regards,
Lorenzo

> 
> Stanislaw


signature.asc
Description: PGP signature

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Lorenzo Bianconi]

> On Fri, Jun 14, 2019 at 12:11:17PM +0200, Lorenzo Bianconi wrote:
> > > On Thu, Jun 13, 2019 at 11:43:11PM +0200, Lorenzo Bianconi wrote:
> > > > Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> > > > for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> > > > receive frames up to q->buf_size but they will be discarded in
> > > > mt76u_process_rx_entry since there is no enough room for
> > > > skb_shared_info. Fix the issue reallocating the skb and copying in the
> > > > linear area the first 128B of the received frames and in the frag_list
> > > > the remaining part.
> > > > 
> > > > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes 
> > > > for rx")
> > > > Signed-off-by: Lorenzo Bianconi 
> > > > ---
> > > >  drivers/net/wireless/mediatek/mt76/mt76.h |  1 +
> > > >  drivers/net/wireless/mediatek/mt76/usb.c  | 49 ++-
> > > >  2 files changed, 41 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
> > > > b/drivers/net/wireless/mediatek/mt76/mt76.h
> > > > index 8ecbf81a906f..889b76deb703 100644
> > > > --- a/drivers/net/wireless/mediatek/mt76/mt76.h
> > > > +++ b/drivers/net/wireless/mediatek/mt76/mt76.h
> > > > @@ -30,6 +30,7 @@
> > > >  #define MT_TX_RING_SIZE 256
> > > >  #define MT_MCU_RING_SIZE32
> > > >  #define MT_RX_BUF_SIZE  2048
> > > > +#define MT_SKB_HEAD_LEN 128
> > > >  
> > > >  struct mt76_dev;
> > > >  struct mt76_wcid;
> > > > diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
> > > > b/drivers/net/wireless/mediatek/mt76/usb.c
> > > > index bbaa1365bbda..12d60d31cb51 100644
> > > > --- a/drivers/net/wireless/mediatek/mt76/usb.c
> > > > +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> > > > @@ -429,6 +429,45 @@ static int mt76u_get_rx_entry_len(u8 *data, u32 
> > > > data_len)
> > > > return dma_len;
> > > >  }
> > > >  
> > > > +static struct sk_buff *
> > > > +mt76u_build_rx_skb(u8 *data, int len, int buf_size)
> > > > +{
> > > > +   struct sk_buff *skb;
> > > > +
> > > > +   if (SKB_WITH_OVERHEAD(buf_size) < MT_DMA_HDR_LEN + len) {
> > > > +   struct page *page;
> > > > +   int offset;
> > > > +
> > > > +   /* slow path, not enough space for data and
> > > > +* skb_shared_info
> > > > +*/
> > > > +   skb = alloc_skb(MT_SKB_HEAD_LEN, GFP_ATOMIC);
> > > > +   if (!skb)
> > > > +   return NULL;
> > > > +
> > > > +   skb_put_data(skb, data + MT_DMA_HDR_LEN, 
> > > > MT_SKB_HEAD_LEN);
> > > 
> > > I looked how rx amsdu is processed in mac80211 and it is decomposed and
> > > copied into newly allocated individual skb's, see 
> > > ieee80211_amsdu_to_8023s()
> > > 
> > > So copy L3 & L4 headers doesn't do anything good here, actually seems to
> > > be better to have them in frag as __ieee80211_amsdu_copy_frag() do some
> > > magic to avid copy.
> > 
> > Looking at __ieee80211_amsdu_copy() now I got why other drivers copy hdrlen 
> > +
> > 8, thx :)
> > In our case reuse_frag is true in __ieee80211_amsdu_copy, so we will end up
> 
> I don't think reuse_frag is true in our case since skb->head_frag is
> not set when we use alloc_skb(). 

Oh, right. In this case it is probably better to use netdev_alloc_skb().
I will repost using the approach used in mt7601u since for the moment it will
not make any difference to copy more data.

Regards,
Lorenzo

> 
> Stanislaw


signature.asc
Description: PGP signature

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Johannes Berg]

On Fri, 2019-06-14 at 13:31 +0200, Stanislaw Gruszka wrote:
> On Fri, Jun 14, 2019 at 12:20:59PM +0200, Johannes Berg wrote:
> > On Fri, 2019-06-14 at 12:11 +0200, Lorenzo Bianconi wrote:
> > 
> > > Looking at __ieee80211_amsdu_copy() now I got why other drivers copy 
> > > hdrlen +
> > > 8, thx :)
> > > In our case reuse_frag is true in __ieee80211_amsdu_copy, so we will end 
> > > up
> > > copying 32B + ether_len. Anyway I think 32 is a little bit too low and we 
> > > could get
> > > better performances increasing it a little bit.
> > > A typical use case (e.g IPv6 + TCP):
> > > 
> > > IPv6 = 40B, TCP = 32B --> so 72B..I guess 128B is a good value :)
> > > @Felix, Johannes: what do you think?
> > 
> > I think while we might *allocate* more, I don't think we should *copy*
> > more, since then the TCP payload will no longer be in pages.
> > 
> > It'd probably be better to implement leaving enough tailroom (allocate
> > 128), but copying nothing, unless the *entire* packet fits.
> 
> iwl4965 put entire packet in fragment in il4965_pass_packet_to_mac80211() .
> Initially I thought this is a bug, since mac80211 require header be
> in the linear area, but looks like ieee80211_rx_monitor() copy header
> before rest of mac80211 check it, so 4965 is fine.

Mac80211 should not assume anything about header being present or not,
just like the rest of the network stack.

> Anyway I think the driver should put ieee80211 header in linear area
> and iwlwifi & mt7601u implementation is somewhat optimal.

Yes, it's just an optimisation to do the copy-break (copy small packets
completely) or to copy the header already (since we may have better ways
to do so than skb_copy_bits if we still have a virt pointer to the page,
rather than just the page pointer).

johannes

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Stanislaw Gruszka]

On Fri, Jun 14, 2019 at 12:20:59PM +0200, Johannes Berg wrote:
> On Fri, 2019-06-14 at 12:11 +0200, Lorenzo Bianconi wrote:
> 
> > Looking at __ieee80211_amsdu_copy() now I got why other drivers copy hdrlen 
> > +
> > 8, thx :)
> > In our case reuse_frag is true in __ieee80211_amsdu_copy, so we will end up
> > copying 32B + ether_len. Anyway I think 32 is a little bit too low and we 
> > could get
> > better performances increasing it a little bit.
> > A typical use case (e.g IPv6 + TCP):
> > 
> > IPv6 = 40B, TCP = 32B --> so 72B..I guess 128B is a good value :)
> > @Felix, Johannes: what do you think?
> 
> I think while we might *allocate* more, I don't think we should *copy*
> more, since then the TCP payload will no longer be in pages.
> 
> It'd probably be better to implement leaving enough tailroom (allocate
> 128), but copying nothing, unless the *entire* packet fits.

iwl4965 put entire packet in fragment in il4965_pass_packet_to_mac80211() .
Initially I thought this is a bug, since mac80211 require header be
in the linear area, but looks like ieee80211_rx_monitor() copy header
before rest of mac80211 check it, so 4965 is fine.

Anyway I think the driver should put ieee80211 header in linear area
and iwlwifi & mt7601u implementation is somewhat optimal.

Stanislaw

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Stanislaw Gruszka]

On Fri, Jun 14, 2019 at 12:11:17PM +0200, Lorenzo Bianconi wrote:
> > On Thu, Jun 13, 2019 at 11:43:11PM +0200, Lorenzo Bianconi wrote:
> > > Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> > > for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> > > receive frames up to q->buf_size but they will be discarded in
> > > mt76u_process_rx_entry since there is no enough room for
> > > skb_shared_info. Fix the issue reallocating the skb and copying in the
> > > linear area the first 128B of the received frames and in the frag_list
> > > the remaining part.
> > > 
> > > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes 
> > > for rx")
> > > Signed-off-by: Lorenzo Bianconi 
> > > ---
> > >  drivers/net/wireless/mediatek/mt76/mt76.h |  1 +
> > >  drivers/net/wireless/mediatek/mt76/usb.c  | 49 ++++++-
> > >  2 files changed, 41 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
> > > b/drivers/net/wireless/mediatek/mt76/mt76.h
> > > index 8ecbf81a906f..889b76deb703 100644
> > > --- a/drivers/net/wireless/mediatek/mt76/mt76.h
> > > +++ b/drivers/net/wireless/mediatek/mt76/mt76.h
> > > @@ -30,6 +30,7 @@
> > >  #define MT_TX_RING_SIZE 256
> > >  #define MT_MCU_RING_SIZE32
> > >  #define MT_RX_BUF_SIZE  2048
> > > +#define MT_SKB_HEAD_LEN 128
> > >  
> > >  struct mt76_dev;
> > >  struct mt76_wcid;
> > > diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
> > > b/drivers/net/wireless/mediatek/mt76/usb.c
> > > index bbaa1365bbda..12d60d31cb51 100644
> > > --- a/drivers/net/wireless/mediatek/mt76/usb.c
> > > +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> > > @@ -429,6 +429,45 @@ static int mt76u_get_rx_entry_len(u8 *data, u32 
> > > data_len)
> > >   return dma_len;
> > >  }
> > >  
> > > +static struct sk_buff *
> > > +mt76u_build_rx_skb(u8 *data, int len, int buf_size)
> > > +{
> > > + struct sk_buff *skb;
> > > +
> > > + if (SKB_WITH_OVERHEAD(buf_size) < MT_DMA_HDR_LEN + len) {
> > > + struct page *page;
> > > + int offset;
> > > +
> > > + /* slow path, not enough space for data and
> > > +  * skb_shared_info
> > > +  */
> > > + skb = alloc_skb(MT_SKB_HEAD_LEN, GFP_ATOMIC);
> > > + if (!skb)
> > > + return NULL;
> > > +
> > > + skb_put_data(skb, data + MT_DMA_HDR_LEN, MT_SKB_HEAD_LEN);
> > 
> > I looked how rx amsdu is processed in mac80211 and it is decomposed and
> > copied into newly allocated individual skb's, see ieee80211_amsdu_to_8023s()
> > 
> > So copy L3 & L4 headers doesn't do anything good here, actually seems to
> > be better to have them in frag as __ieee80211_amsdu_copy_frag() do some
> > magic to avid copy.
> 
> Looking at __ieee80211_amsdu_copy() now I got why other drivers copy hdrlen +
> 8, thx :)
> In our case reuse_frag is true in __ieee80211_amsdu_copy, so we will end up

I don't think reuse_frag is true in our case since skb->head_frag is
not set when we use alloc_skb(). 

Stanislaw

Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames

[Stanislaw Gruszka]

On Fri, Jun 14, 2019 at 12:22:48PM +0200, Lorenzo Bianconi wrote:
> > On Thu, Jun 13, 2019 at 11:43:13PM +0200, Lorenzo Bianconi wrote:
> > > Set usb buffer size taking into account skb_shared_info in order to
> > > not always copy the first part of received frames if A-MSDU is enabled
> > > for SG capable devices. Moreover align usb buffer size to max_ep
> > > boundaries and set buf_size to PAGE_SIZE even for sg case
> > 
> > I think this should not be applied to wirless-drivers, only first patch
> > that fix the bug and optimizations should be done in -next.
> 
> ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree
> 
> > 
> > > + int i, data_size;
> > >  
> > > + data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > > +   dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
> > >   for (i = 0; i < nsgs; i++) {
> > >   struct page *page;
> > >   void *data;
> > > @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct 
> > > mt76_queue *q, struct urb *urb,
> > >  
> > >   page = virt_to_head_page(data);
> > >   offset = data - page_address(page);
> > > - sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> > > + sg_set_page(&urb->sg[i], page, data_size, offset);
> > 
> > > - q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
> > >   q->ndesc = MT_NUM_RX_ENTRIES;
> > > + q->buf_size = PAGE_SIZE;
> > > +
> > 
> > This should be associated with decrease of MT_SG_MAX_SIZE to value that
> > is actually needed and currently this is 2 for 4k AMSDU.
> 
> MT_SG_MAX_SIZE is used even on tx side and I do not think we will end up with 
> a
> huge difference here

So use different value as argument for mt76u_fill_rx_sg() in
mt76u_rx_urb_alloc(). After changing buf_size to PAGE_SIZE we will
allocate 8 pages per rx queue entry, but only 2 pages will be used
(with data_size change, 1 without data_size change). Or I'm wrong?

> > However I don't think allocating 2 pages to avoid ieee80211 header and SNAP
> > copy is worth to do. For me best approach would be allocate 1 page for
> > 4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without data_size
> > change to avoid 32B copying).
> 
> From my point of view it is better to avoid copying if it is possible. Are you
> sure there is no difference?

I do not understand what you mean by difference here.

Stanislaw

Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames

[Lorenzo Bianconi]

> On Thu, Jun 13, 2019 at 11:43:13PM +0200, Lorenzo Bianconi wrote:
> > Set usb buffer size taking into account skb_shared_info in order to
> > not always copy the first part of received frames if A-MSDU is enabled
> > for SG capable devices. Moreover align usb buffer size to max_ep
> > boundaries and set buf_size to PAGE_SIZE even for sg case
> 
> I think this should not be applied to wirless-drivers, only first patch
> that fix the bug and optimizations should be done in -next.

ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree

> 
> > +   int i, data_size;
> >  
> > +   data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > + dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
> > for (i = 0; i < nsgs; i++) {
> > struct page *page;
> > void *data;
> > @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct 
> > mt76_queue *q, struct urb *urb,
> >  
> > page = virt_to_head_page(data);
> > offset = data - page_address(page);
> > -   sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> > +   sg_set_page(&urb->sg[i], page, data_size, offset);
> 
> > -   q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
> > q->ndesc = MT_NUM_RX_ENTRIES;
> > +   q->buf_size = PAGE_SIZE;
> > +
> 
> This should be associated with decrease of MT_SG_MAX_SIZE to value that
> is actually needed and currently this is 2 for 4k AMSDU.

MT_SG_MAX_SIZE is used even on tx side and I do not think we will end up with a
huge difference here

> 
> However I don't think allocating 2 pages to avoid ieee80211 header and SNAP
> copy is worth to do. For me best approach would be allocate 1 page for
> 4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without data_size
> change to avoid 32B copying).

From my point of view it is better to avoid copying if it is possible. Are you
sure there is no difference?

Regards,
Lorenzo

> 
> Stanislaw


signature.asc
Description: PGP signature

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Johannes Berg]

On Fri, 2019-06-14 at 12:11 +0200, Lorenzo Bianconi wrote:

> Looking at __ieee80211_amsdu_copy() now I got why other drivers copy hdrlen +
> 8, thx :)
> In our case reuse_frag is true in __ieee80211_amsdu_copy, so we will end up
> copying 32B + ether_len. Anyway I think 32 is a little bit too low and we 
> could get
> better performances increasing it a little bit.
> A typical use case (e.g IPv6 + TCP):
> 
> IPv6 = 40B, TCP = 32B --> so 72B..I guess 128B is a good value :)
> @Felix, Johannes: what do you think?

I think while we might *allocate* more, I don't think we should *copy*
more, since then the TCP payload will no longer be in pages.

It'd probably be better to implement leaving enough tailroom (allocate
128), but copying nothing, unless the *entire* packet fits.

johannes

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Lorenzo Bianconi]

> On Thu, Jun 13, 2019 at 11:43:11PM +0200, Lorenzo Bianconi wrote:
> > Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> > for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> > receive frames up to q->buf_size but they will be discarded in
> > mt76u_process_rx_entry since there is no enough room for
> > skb_shared_info. Fix the issue reallocating the skb and copying in the
> > linear area the first 128B of the received frames and in the frag_list
> > the remaining part.
> > 
> > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for 
> > rx")
> > Signed-off-by: Lorenzo Bianconi 
> > ---
> >  drivers/net/wireless/mediatek/mt76/mt76.h |  1 +
> >  drivers/net/wireless/mediatek/mt76/usb.c  | 49 ++++++-
> >  2 files changed, 41 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
> > b/drivers/net/wireless/mediatek/mt76/mt76.h
> > index 8ecbf81a906f..889b76deb703 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76.h
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76.h
> > @@ -30,6 +30,7 @@
> >  #define MT_TX_RING_SIZE 256
> >  #define MT_MCU_RING_SIZE32
> >  #define MT_RX_BUF_SIZE  2048
> > +#define MT_SKB_HEAD_LEN 128
> >  
> >  struct mt76_dev;
> >  struct mt76_wcid;
> > diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
> > b/drivers/net/wireless/mediatek/mt76/usb.c
> > index bbaa1365bbda..12d60d31cb51 100644
> > --- a/drivers/net/wireless/mediatek/mt76/usb.c
> > +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> > @@ -429,6 +429,45 @@ static int mt76u_get_rx_entry_len(u8 *data, u32 
> > data_len)
> > return dma_len;
> >  }
> >  
> > +static struct sk_buff *
> > +mt76u_build_rx_skb(u8 *data, int len, int buf_size)
> > +{
> > +   struct sk_buff *skb;
> > +
> > +   if (SKB_WITH_OVERHEAD(buf_size) < MT_DMA_HDR_LEN + len) {
> > +   struct page *page;
> > +   int offset;
> > +
> > +   /* slow path, not enough space for data and
> > +* skb_shared_info
> > +*/
> > +   skb = alloc_skb(MT_SKB_HEAD_LEN, GFP_ATOMIC);
> > +   if (!skb)
> > +   return NULL;
> > +
> > +   skb_put_data(skb, data + MT_DMA_HDR_LEN, MT_SKB_HEAD_LEN);
> 
> I looked how rx amsdu is processed in mac80211 and it is decomposed and
> copied into newly allocated individual skb's, see ieee80211_amsdu_to_8023s()
> 
> So copy L3 & L4 headers doesn't do anything good here, actually seems to
> be better to have them in frag as __ieee80211_amsdu_copy_frag() do some
> magic to avid copy.

Looking at __ieee80211_amsdu_copy() now I got why other drivers copy hdrlen +
8, thx :)
In our case reuse_frag is true in __ieee80211_amsdu_copy, so we will end up
copying 32B + ether_len. Anyway I think 32 is a little bit too low and we could 
get
better performances increasing it a little bit.
A typical use case (e.g IPv6 + TCP):

IPv6 = 40B, TCP = 32B --> so 72B..I guess 128B is a good value :)
@Felix, Johannes: what do you think?

Regarding the patch I guess let's apply it as it is in order to fix the pending
issue and then we will figure out how to proceed (copy hdr_len + 3 or increase
the value in __ieee80211_amsdu_copy)

Regards,
Lorenzo

> 
> Stanislaw


signature.asc
Description: PGP signature

Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames

[Stanislaw Gruszka]

On Thu, Jun 13, 2019 at 11:43:13PM +0200, Lorenzo Bianconi wrote:
> Set usb buffer size taking into account skb_shared_info in order to
> not always copy the first part of received frames if A-MSDU is enabled
> for SG capable devices. Moreover align usb buffer size to max_ep
> boundaries and set buf_size to PAGE_SIZE even for sg case

I think this should not be applied to wirless-drivers, only first patch
that fix the bug and optimizations should be done in -next.

> + int i, data_size;
>  
> + data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> +   dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
>   for (i = 0; i < nsgs; i++) {
>   struct page *page;
>   void *data;
> @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue 
> *q, struct urb *urb,
>  
>   page = virt_to_head_page(data);
>   offset = data - page_address(page);
> - sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> + sg_set_page(&urb->sg[i], page, data_size, offset);

> - q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
>   q->ndesc = MT_NUM_RX_ENTRIES;
> + q->buf_size = PAGE_SIZE;
> +

This should be associated with decrease of MT_SG_MAX_SIZE to value that
is actually needed and currently this is 2 for 4k AMSDU.

However I don't think allocating 2 pages to avoid ieee80211 header and SNAP
copy is worth to do. For me best approach would be allocate 1 page for
4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without data_size
change to avoid 32B copying).

Stanislaw

Re: [PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Stanislaw Gruszka]

On Thu, Jun 13, 2019 at 11:43:11PM +0200, Lorenzo Bianconi wrote:
> Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
> for rx") breaks A-MSDU support. When A-MSDU is enable the device can
> receive frames up to q->buf_size but they will be discarded in
> mt76u_process_rx_entry since there is no enough room for
> skb_shared_info. Fix the issue reallocating the skb and copying in the
> linear area the first 128B of the received frames and in the frag_list
> the remaining part.
> 
> Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for 
> rx")
> Signed-off-by: Lorenzo Bianconi 
> ---
>  drivers/net/wireless/mediatek/mt76/mt76.h |  1 +
>  drivers/net/wireless/mediatek/mt76/usb.c  | 49 ++-
>  2 files changed, 41 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
> b/drivers/net/wireless/mediatek/mt76/mt76.h
> index 8ecbf81a906f..889b76deb703 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt76.h
> @@ -30,6 +30,7 @@
>  #define MT_TX_RING_SIZE 256
>  #define MT_MCU_RING_SIZE32
>  #define MT_RX_BUF_SIZE  2048
> +#define MT_SKB_HEAD_LEN 128
>  
>  struct mt76_dev;
>  struct mt76_wcid;
> diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
> b/drivers/net/wireless/mediatek/mt76/usb.c
> index bbaa1365bbda..12d60d31cb51 100644
> --- a/drivers/net/wireless/mediatek/mt76/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> @@ -429,6 +429,45 @@ static int mt76u_get_rx_entry_len(u8 *data, u32 data_len)
>   return dma_len;
>  }
>  
> +static struct sk_buff *
> +mt76u_build_rx_skb(u8 *data, int len, int buf_size)
> +{
> + struct sk_buff *skb;
> +
> + if (SKB_WITH_OVERHEAD(buf_size) < MT_DMA_HDR_LEN + len) {
> + struct page *page;
> + int offset;
> +
> + /* slow path, not enough space for data and
> +  * skb_shared_info
> +  */
> + skb = alloc_skb(MT_SKB_HEAD_LEN, GFP_ATOMIC);
> + if (!skb)
> + return NULL;
> +
> + skb_put_data(skb, data + MT_DMA_HDR_LEN, MT_SKB_HEAD_LEN);

I looked how rx amsdu is processed in mac80211 and it is decomposed and
copied into newly allocated individual skb's, see ieee80211_amsdu_to_8023s()

So copy L3 & L4 headers doesn't do anything good here, actually seems to
be better to have them in frag as __ieee80211_amsdu_copy_frag() do some
magic to avid copy.

Stanislaw

Re: Cleanup of -Wunused-const-variable in drivers/net/wireless/ti/wl18xx/main.c

[Kalle Valo]

Nathan Huckleberry  writes:

> I'm looking into cleaning up ignored warnings in the kernel so we can
> remove compiler flags to ignore warnings.
>
> There are two unused variables ('wl18xx_iface_ap_cl_limits' and
> 'wl18xx_iface_ap_go_limits') in drivers/net/wireless/ti/wl18xx/main.c.
> These appear to be limits when using p2p devices, yet they are never
> used.
>
> Wanted to reach out for the best course of action to fix the warning.
>
> https://github.com/ClangBuiltLinux/linux/issues/530

The the variables were added in this commit:

commit 7845af35e0deeb7537de759ebc69d6395d4123bf
Author: Eliad Peller 
AuthorDate: Thu Jul 30 22:38:22 2015 +0300
Commit: Kalle Valo 
CommitDate: Mon Aug 10 22:16:34 2015 +0300

wlcore: add p2p device support

And even that commit didn't use them, no idea why. Just send a patch
removing them, if someone needs them later they can be added again.

-- 
Kalle Valo

[PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames

[Lorenzo Bianconi]

Set usb buffer size taking into account skb_shared_info in order to
not always copy the first part of received frames if A-MSDU is enabled
for SG capable devices. Moreover align usb buffer size to max_ep
boundaries and set buf_size to PAGE_SIZE even for sg case

Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/usb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
b/drivers/net/wireless/mediatek/mt76/usb.c
index 1ee54a9b302e..2ee3f8fa1483 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -289,8 +289,10 @@ static int
 mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue *q, struct urb *urb,
 int nsgs, gfp_t gfp)
 {
-   int i;
+   int i, data_size;
 
+   data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
+ dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
for (i = 0; i < nsgs; i++) {
struct page *page;
void *data;
@@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue 
*q, struct urb *urb,
 
page = virt_to_head_page(data);
offset = data - page_address(page);
-   sg_set_page(&urb->sg[i], page, q->buf_size, offset);
+   sg_set_page(&urb->sg[i], page, data_size, offset);
}
 
if (i < nsgs) {
@@ -314,7 +316,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue 
*q, struct urb *urb,
}
 
urb->num_sgs = max_t(int, i, urb->num_sgs);
-   urb->transfer_buffer_length = urb->num_sgs * q->buf_size,
+   urb->transfer_buffer_length = urb->num_sgs * data_size;
sg_init_marker(urb->sg, urb->num_sgs);
 
return i ? : -ENOMEM;
@@ -611,8 +613,9 @@ static int mt76u_alloc_rx(struct mt76_dev *dev)
if (!q->entry)
return -ENOMEM;
 
-   q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
q->ndesc = MT_NUM_RX_ENTRIES;
+   q->buf_size = PAGE_SIZE;
+
for (i = 0; i < q->ndesc; i++) {
err = mt76u_rx_urb_alloc(dev, &q->entry[i]);
if (err < 0)
-- 
2.21.0

[PATCH v3 wireless-drivers 0/3] mt76: usb: fix A-MSDU support

[Lorenzo Bianconi]

Reallocate the skb if there is no enough space to manage the AMSDU rx packets.
Do not always copy the first part of received frames if A-MSDU is enabled
for SG capable devices

Changes since v2:
- simplify mt76u_build_rx_skb
- add patch 2/3: mt76u: introduce mt76u_ep data structure
- align usb buffer size to usb max endpoint length
- set buf_size to PAGE_SIZE even for sg case

Changes since v1:
- do not allocate multiple page buffers but rely on fragmented skbs
  if there is no enough space to manage the AMSDU rx packets

Lorenzo Bianconi (3):
  mt76: usb: fix rx A-MSDU support
  mt76: mt76u: introduce mt76u_ep data structure
  mt76: usb: do not always copy the first part of received frames

 drivers/net/wireless/mediatek/mt76/mt76.h | 17 +++--
 drivers/net/wireless/mediatek/mt76/usb.c  | 75 +--
 2 files changed, 67 insertions(+), 25 deletions(-)

-- 
2.21.0

[PATCH v3 wireless-drivers 2/3] mt76: mt76u: introduce mt76u_ep data structure

[Lorenzo Bianconi]

Introduce mt76u_ep data structure as a container for usb endpoint info.
This is a preliminary patch to compute proper usb buffer size and avoid
always copy the first part of received frames

Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76.h | 16 ++--
 drivers/net/wireless/mediatek/mt76/usb.c  | 15 +--
 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 889b76deb703..1c51d6d48e60 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -382,6 +382,11 @@ enum mt76u_out_ep {
__MT_EP_OUT_MAX,
 };
 
+struct mt76u_ep {
+   u16 max_packet;
+   u8 ep;
+};
+
 #define MT_SG_MAX_SIZE 8
 #define MT_NUM_TX_ENTRIES  256
 #define MT_NUM_RX_ENTRIES  128
@@ -393,10 +398,8 @@ struct mt76_usb {
struct tasklet_struct rx_tasklet;
struct delayed_work stat_work;
 
-   u8 out_ep[__MT_EP_OUT_MAX];
-   u16 out_max_packet;
-   u8 in_ep[__MT_EP_IN_MAX];
-   u16 in_max_packet;
+   struct mt76u_ep out_ep[__MT_EP_OUT_MAX];
+   struct mt76u_ep in_ep[__MT_EP_IN_MAX];
bool sg_en;
 
struct mt76u_mcu {
@@ -786,9 +789,10 @@ mt76u_bulk_msg(struct mt76_dev *dev, void *data, int len, 
int *actual_len,
unsigned int pipe;
 
if (actual_len)
-   pipe = usb_rcvbulkpipe(udev, usb->in_ep[MT_EP_IN_CMD_RESP]);
+   pipe = usb_rcvbulkpipe(udev, usb->in_ep[MT_EP_IN_CMD_RESP].ep);
else
-   pipe = usb_sndbulkpipe(udev, usb->out_ep[MT_EP_OUT_INBAND_CMD]);
+   pipe = usb_sndbulkpipe(udev,
+  usb->out_ep[MT_EP_OUT_INBAND_CMD].ep);
 
return usb_bulk_msg(udev, pipe, data, len, actual_len, timeout);
 }
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
b/drivers/net/wireless/mediatek/mt76/usb.c
index 12d60d31cb51..1ee54a9b302e 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -260,19 +260,22 @@ mt76u_set_endpoints(struct usb_interface *intf,
struct usb_host_interface *intf_desc = intf->cur_altsetting;
struct usb_endpoint_descriptor *ep_desc;
int i, in_ep = 0, out_ep = 0;
+   struct mt76u_ep *ep;
 
for (i = 0; i < intf_desc->desc.bNumEndpoints; i++) {
ep_desc = &intf_desc->endpoint[i].desc;
 
if (usb_endpoint_is_bulk_in(ep_desc) &&
in_ep < __MT_EP_IN_MAX) {
-   usb->in_ep[in_ep] = usb_endpoint_num(ep_desc);
-   usb->in_max_packet = usb_endpoint_maxp(ep_desc);
+   ep = &usb->in_ep[in_ep];
+   ep->max_packet = usb_endpoint_maxp(ep_desc);
+   ep->ep = usb_endpoint_num(ep_desc);
in_ep++;
} else if (usb_endpoint_is_bulk_out(ep_desc) &&
   out_ep < __MT_EP_OUT_MAX) {
-   usb->out_ep[out_ep] = usb_endpoint_num(ep_desc);
-   usb->out_max_packet = usb_endpoint_maxp(ep_desc);
+   ep = &usb->out_ep[out_ep];
+   ep->max_packet = usb_endpoint_maxp(ep_desc);
+   ep->ep = usb_endpoint_num(ep_desc);
out_ep++;
}
}
@@ -386,9 +389,9 @@ mt76u_fill_bulk_urb(struct mt76_dev *dev, int dir, int 
index,
unsigned int pipe;
 
if (dir == USB_DIR_IN)
-   pipe = usb_rcvbulkpipe(udev, dev->usb.in_ep[index]);
+   pipe = usb_rcvbulkpipe(udev, dev->usb.in_ep[index].ep);
else
-   pipe = usb_sndbulkpipe(udev, dev->usb.out_ep[index]);
+   pipe = usb_sndbulkpipe(udev, dev->usb.out_ep[index].ep);
 
urb->dev = udev;
urb->pipe = pipe;
-- 
2.21.0

[PATCH v3 wireless-drivers 1/3] mt76: usb: fix rx A-MSDU support

[Lorenzo Bianconi]

Commit f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes
for rx") breaks A-MSDU support. When A-MSDU is enable the device can
receive frames up to q->buf_size but they will be discarded in
mt76u_process_rx_entry since there is no enough room for
skb_shared_info. Fix the issue reallocating the skb and copying in the
linear area the first 128B of the received frames and in the frag_list
the remaining part.

Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76.h |  1 +
 drivers/net/wireless/mediatek/mt76/usb.c  | 49 ++-
 2 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 8ecbf81a906f..889b76deb703 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -30,6 +30,7 @@
 #define MT_TX_RING_SIZE 256
 #define MT_MCU_RING_SIZE32
 #define MT_RX_BUF_SIZE  2048
+#define MT_SKB_HEAD_LEN 128
 
 struct mt76_dev;
 struct mt76_wcid;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
b/drivers/net/wireless/mediatek/mt76/usb.c
index bbaa1365bbda..12d60d31cb51 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -429,6 +429,45 @@ static int mt76u_get_rx_entry_len(u8 *data, u32 data_len)
return dma_len;
 }
 
+static struct sk_buff *
+mt76u_build_rx_skb(u8 *data, int len, int buf_size)
+{
+   struct sk_buff *skb;
+
+   if (SKB_WITH_OVERHEAD(buf_size) < MT_DMA_HDR_LEN + len) {
+   struct page *page;
+   int offset;
+
+   /* slow path, not enough space for data and
+* skb_shared_info
+*/
+   skb = alloc_skb(MT_SKB_HEAD_LEN, GFP_ATOMIC);
+   if (!skb)
+   return NULL;
+
+   skb_put_data(skb, data + MT_DMA_HDR_LEN, MT_SKB_HEAD_LEN);
+   data += (MT_SKB_HEAD_LEN + MT_DMA_HDR_LEN);
+   page = virt_to_head_page(data);
+   offset = data - (u8 *)page_address(page);
+
+   skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
+   page, offset, len - MT_SKB_HEAD_LEN,
+   buf_size);
+
+   return skb;
+   }
+
+   /* fast path */
+   skb = build_skb(data, buf_size);
+   if (!skb)
+   return NULL;
+
+   skb_reserve(skb, MT_DMA_HDR_LEN);
+   __skb_put(skb, len);
+
+   return skb;
+}
+
 static int
 mt76u_process_rx_entry(struct mt76_dev *dev, struct urb *urb)
 {
@@ -446,19 +485,11 @@ mt76u_process_rx_entry(struct mt76_dev *dev, struct urb 
*urb)
return 0;
 
data_len = min_t(int, len, data_len - MT_DMA_HDR_LEN);
-   if (MT_DMA_HDR_LEN + data_len > SKB_WITH_OVERHEAD(q->buf_size)) {
-   dev_err_ratelimited(dev->dev, "rx data too big %d\n", data_len);
-   return 0;
-   }
-
-   skb = build_skb(data, q->buf_size);
+   skb = mt76u_build_rx_skb(data, data_len, q->buf_size);
if (!skb)
return 0;
 
-   skb_reserve(skb, MT_DMA_HDR_LEN);
-   __skb_put(skb, data_len);
len -= data_len;
-
while (len > 0 && nsgs < urb->num_sgs) {
data_len = min_t(int, len, urb->sg[nsgs].length);
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
-- 
2.21.0

Cleanup of -Wunused-const-variable in drivers/net/wireless/ti/wl18xx/main.c

[Nathan Huckleberry]

Hey all,

I'm looking into cleaning up ignored warnings in the kernel so we can
remove compiler flags to ignore warnings.

There are two unused variables ('wl18xx_iface_ap_cl_limits' and
'wl18xx_iface_ap_go_limits') in drivers/net/wireless/ti/wl18xx/main.c.
These appear to be limits when using p2p devices, yet they are never
used.

Wanted to reach out for the best course of action to fix the warning.

https://github.com/ClangBuiltLinux/linux/issues/530

Thanks,
Nathan Huckleberry

[PATCH 1/3] net: wireless: trace: add trace for tx_mgmt_expired

[James Prestwood]

Signed-off-by: James Prestwood 
---
 net/wireless/trace.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 2abfff925aac..4fbb91a511ae 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2752,6 +2752,24 @@ TRACE_EVENT(cfg80211_ready_on_channel_expired,
  WDEV_PR_ARG, __entry->cookie, CHAN_PR_ARG)
 );
 
+TRACE_EVENT(cfg80211_tx_mgmt_expired,
+   TP_PROTO(struct wireless_dev *wdev, u64 cookie,
+struct ieee80211_channel *chan),
+   TP_ARGS(wdev, cookie, chan),
+   TP_STRUCT__entry(
+   WDEV_ENTRY
+   __field(u64, cookie)
+   CHAN_ENTRY
+   ),
+   TP_fast_assign(
+   WDEV_ASSIGN;
+   __entry->cookie = cookie;
+   CHAN_ASSIGN(chan);
+   ),
+   TP_printk(WDEV_PR_FMT ", cookie: %llu, " CHAN_PR_FMT,
+ WDEV_PR_ARG, __entry->cookie, CHAN_PR_ARG)
+);
+
 TRACE_EVENT(cfg80211_new_sta,
TP_PROTO(struct net_device *netdev, const u8 *mac_addr,
 struct station_info *sinfo),
-- 
2.17.1

Re: [PATCH] wireless: wil6210: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

On Wed, Jun 12, 2019 at 12:07:17PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 11, 2019 at 09:10:24PM +0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > Cc: Maya Erez 
> > Cc: Kalle Valo 
> > Cc: "David S. Miller" 
> > Cc: linux-wireless@vger.kernel.org
> > Cc: wil6...@qti.qualcomm.com
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  drivers/net/wireless/ath/wil6210/debugfs.c | 80 ++
> >  1 file changed, 22 insertions(+), 58 deletions(-)
> 
> Oops, 0-day finally woke up and shows I messed this patch up.  Please
> drop it, I will submit a v2 soon.

{sigh}, no, that was a different patch that broke things.  This pathc is
fine, please consider it as-is.

I'll go get more coffee...

greg k-h

Re: [PATCH] wireless: wil6210: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

On Tue, Jun 11, 2019 at 09:10:24PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
> 
> Cc: Maya Erez 
> Cc: Kalle Valo 
> Cc: "David S. Miller" 
> Cc: linux-wireless@vger.kernel.org
> Cc: wil6...@qti.qualcomm.com
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/net/wireless/ath/wil6210/debugfs.c | 80 ++
>  1 file changed, 22 insertions(+), 58 deletions(-)

Oops, 0-day finally woke up and shows I messed this patch up.  Please
drop it, I will submit a v2 soon.

thanks,

greg k-h

[PATCH] wireless: wil6210: no need to check return value of debugfs_create functions

[Greg Kroah-Hartman]

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Maya Erez 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: linux-wireless@vger.kernel.org
Cc: wil6...@qti.qualcomm.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/wireless/ath/wil6210/debugfs.c | 80 ++
 1 file changed, 22 insertions(+), 58 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index df2adff6c33a..ea5da93196fd 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -394,25 +394,18 @@ static int wil_debugfs_iomem_x32_get(void *data, u64 *val)
 DEFINE_DEBUGFS_ATTRIBUTE(fops_iomem_x32, wil_debugfs_iomem_x32_get,
 wil_debugfs_iomem_x32_set, "0x%08llx\n");
 
-static struct dentry *wil_debugfs_create_iomem_x32(const char *name,
-  umode_t mode,
-  struct dentry *parent,
-  void *value,
-  struct wil6210_priv *wil)
+static void wil_debugfs_create_iomem_x32(const char *name, umode_t mode,
+struct dentry *parent, void *value,
+struct wil6210_priv *wil)
 {
-   struct dentry *file;
struct wil_debugfs_iomem_data *data = &wil->dbg_data.data_arr[
  wil->dbg_data.iomem_data_count];
 
data->wil = wil;
data->offset = value;
 
-   file = debugfs_create_file_unsafe(name, mode, parent, data,
- &fops_iomem_x32);
-   if (!IS_ERR_OR_NULL(file))
-   wil->dbg_data.iomem_data_count++;
-
-   return file;
+   debugfs_create_file_unsafe(name, mode, parent, data, &fops_iomem_x32);
+   wil->dbg_data.iomem_data_count++;
 }
 
 static int wil_debugfs_ulong_set(void *data, u64 val)
@@ -430,14 +423,6 @@ static int wil_debugfs_ulong_get(void *data, u64 *val)
 DEFINE_DEBUGFS_ATTRIBUTE(wil_fops_ulong, wil_debugfs_ulong_get,
 wil_debugfs_ulong_set, "0x%llx\n");
 
-static struct dentry *wil_debugfs_create_ulong(const char *name, umode_t mode,
-  struct dentry *parent,
-  ulong *value)
-{
-   return debugfs_create_file_unsafe(name, mode, parent, value,
- &wil_fops_ulong);
-}
-
 /**
  * wil6210_debugfs_init_offset - create set of debugfs files
  * @wil - driver's context, used for printing
@@ -454,37 +439,30 @@ static void wil6210_debugfs_init_offset(struct 
wil6210_priv *wil,
int i;
 
for (i = 0; tbl[i].name; i++) {
-   struct dentry *f;
-
switch (tbl[i].type) {
case doff_u32:
-   f = debugfs_create_u32(tbl[i].name, tbl[i].mode, dbg,
-  base + tbl[i].off);
+   debugfs_create_u32(tbl[i].name, tbl[i].mode, dbg,
+  base + tbl[i].off);
break;
case doff_x32:
-   f = debugfs_create_x32(tbl[i].name, tbl[i].mode, dbg,
-  base + tbl[i].off);
+   debugfs_create_x32(tbl[i].name, tbl[i].mode, dbg,
+  base + tbl[i].off);
break;
case doff_ulong:
-   f = wil_debugfs_create_ulong(tbl[i].name, tbl[i].mode,
-dbg, base + tbl[i].off);
+   debugfs_create_file_unsafe(tbl[i].name, tbl[i].mode,
+  dbg, base + tbl[i].off,
+  &wil_fops_ulong);
break;
case doff_io32:
-   f = wil_debugfs_create_iomem_x32(tbl[i].name,
-tbl[i].mode, dbg,
-base + tbl[i].off,
-wil);
+   wil_debugfs_create_iomem_x32(tbl[i].name, tbl[i].mode,
+dbg, base + tbl[i].off,
+wil);
break;
case doff_u8:
-   f = debugfs_create_u8(tbl[i].name, tbl[i].mode, dbg,
- base + tbl[i].off)

Trace with softblocked wireless card during startup on v5.1.x

[Julian Wollrath]

Hi,

I have an Intel Corporation Wireless 8265 / 8275 [8086:24fd] card which
is softblocked during startup and I get the following reproducable
trace:

wpa_supplicant[580]: rfkill: WLAN soft blocked
kernel: [   10.881037] WARNING: CPU: 0 PID: 580 at net/wireless/nl80211.c:6714 
nl80211_get_reg_do+0x1d9/0x240 [cfg802

kernel: [   10.881038] Modules linked in: arc4 snd_hda_codec_hdmi iwlmvm 
mac80211 snd_hda_codec_realtek snd_hda_codec
m btintel bluetooth nft_counter iwlwifi nft_limit drbg snd_hda_intel uvcvideo 
snd_hda_codec snd_usb_audio(+) videobuf
s intel_rapl snd_usbmidi_lib ansi_cprng x86_pkg_temp_thermal snd_hwdep 
snd_hda_core intel_powerclamp coretemp snd_pcm
odev snd_rawmidi snd_timer snd_seq_device videobuf2_common evdev serio_raw snd 
soundcore cfg80211 i2c_algo_bit nft_ct
per crc16 rfkill syscopyarea sysfillrect sysimgblt fb_sys_fops nf_conntrack 
idma64 drm nf_defrag_ipv6 nf_defrag_ipv4
b fujitsu_laptop tpm sparse_keymap acpi_pad video ac nf_tables_set nf_tables 
nfnetlink sch_fq autofs4 algif_skcipher
 hid dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel 
i2c_designware_platform i2c_designware_core gh
psmouse ptp pps_core
kernel: [   10.881066]  ahci libahci i2c_i801 sdhci_pci cqhci xhci_pci sdhci 
libata xhci_hcd mmc_core scsi_mod usbcor
ss usb_common
kernel: [   10.881073] CPU: 0 PID: 580 Comm: wpa_supplicant Not tainted 5.1.8 #4
kernel: [   10.881074] Hardware name: FUJITSU LIFEBOOK U747/FJNB2A5, BIOS 
Version 1.17 09/11/2017
kernel: [   10.881082] RIP: 0010:nl80211_get_reg_do+0x1d9/0x240 [cfg80211]
kernel: [   10.881083] Code: 9a 00 00 00 c7 44 24 0c 01 00 00 00 48 89 df e8 ed 
ff 24 cf 85 c0 74 c3 48 89 df e8 91 1
 73 ff ff ff <0f> 0b 48 89 df e8 7d 18 3c cf b8 ea ff ff ff e9 5f ff ff ff b8 97
kernel: [   10.881084] RSP: 0018:b6b5c1ce7ad8 EFLAGS: 00010202
kernel: [   10.881085] RAX:  RBX: 8ef0951e3e00 RCX: 

kernel: [   10.881086] RDX: 8ef09331c008 RSI:  RDI: 
8ef09331c300
kernel: [   10.881086] RBP: b6b5c1ce7b68 R08: 0004 R09: 
8ef093ad2014
kernel: [   10.881087] R10: c07da5e0 R11: 0004 R12: 
8ef093ad2014
kernel: [   10.881088] R13:  R14: 8ef09331c300 R15: 
0001
kernel: [   10.881089] FS:  7f689cc7a800() GS:8ef09dc0() 
knlGS:
kernel: [   10.881090] CS:  0010 DS:  ES:  CR0: 80050033
kernel: [   10.881091] CR2: 55d5cdb69000 CR3: 00024bc50001 CR4: 
003606f0
kernel: [   10.881091] DR0:  DR1:  DR2: 

kernel: [   10.881092] DR3:  DR6: fffe0ff0 DR7: 
0400
kernel: [   10.881093] Call Trace:
kernel: [   10.881098]  ? _cond_resched+0x10/0x20
kernel: [   10.881100]  genl_family_rcv_msg+0x1c5/0x3b0
kernel: [   10.881103]  genl_rcv_msg+0x42/0x87
kernel: [   10.881104]  ? genl_family_rcv_msg+0x3b0/0x3b0
kernel: [   10.881106]  netlink_rcv_skb+0x44/0x110
kernel: [   10.881108]  genl_rcv+0x1f/0x30
kernel: [   10.88]  netlink_unicast+0x194/0x250
kernel: [   10.881113]  netlink_sendmsg+0x1c7/0x3f0
kernel: [   10.881115]  ? netlink_unicast+0x250/0x250
kernel: [   10.881117]  ___sys_sendmsg+0x291/0x2e0
kernel: [   10.881122]  ? alloc_set_pte+0xe7/0x530
kernel: [   10.881133]  ? filemap_map_pages+0x1ae/0x390
kernel: [   10.881134]  ? __handle_mm_fault+0x100d/0x1240
kernel: [   10.881136]  __sys_sendmsg+0x52/0xa0
kernel: [   10.881139]  do_syscall_64+0x43/0xf0
kernel: [   10.881142]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
kernel: [   10.881144] RIP: 0033:0x7f689cfc5914
kernel: [   10.881145] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 
80 00 00 00 00 48 8d 05 e9 5d 0c 00 8
 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53
kernel: [   10.881146] RSP: 002b:7fff25f0fac8 EFLAGS: 0246 ORIG_RAX: 
002e
kernel: [   10.881147] RAX: ffda RBX: 55d5cdb5c480 RCX: 
7f689cfc5914
kernel: [   10.881148] RDX:  RSI: 7fff25f0fb00 RDI: 
0005
kernel: [   10.881148] RBP: 55d5cdb5cbb0 R08: 0004 R09: 
000d
kernel: [   10.881149] R10: 7fff25f0fbd4 R11: 0246 R12: 
55d5cdb5c390
kernel: [   10.881150] R13: 7fff25f0fb00 R14: 7fff25f0fc30 R15: 
7fff25f0fbd4
kernel: [   10.881151] ---[ end trace dfad2d1ce058f730 ]---



Best regards,
Julian Wollrath

--
 ()  ascii ribbon campaign - against html e-mail
 /\- against proprietary attachments

Update to wireless-regdb about Italy

[Giorgio Bernardi]

Hi

I'm Italian and I work in Italy, I realize that nowadays the regdb entry 
for Italy is as follows:


country IT: DFS-ETSI
    (2402 - 2482 @ 40), (20)
    (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
    (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
    (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
    # 60 GHz band channels 1-4, ref: Etsi En 302 567
    (57000 - 66000 @ 2160), (40)

And it misses the lines:

    # Short Range Devices (SRD) (ETSI EN 300 440)
    (5725 - 5875 @ 80), (25 mW)

Common to may European Countries.

I dug a bit in the current Italian regulation that is online on the 
website of the

Ministry of Economic Development: https://www.mise.gov.it/index.php/en/

In the section about the "National Plan of Frequencies" (only in 
Italian) at the URL:


https://www.mise.gov.it/index.php/it/comunicazioni/radio/pnrf-piano-nazionale-di-ripartizione-delle-frequenze

Two PDF files are linked:

--Tabelle di attribuzione Tabella B (27,50 MHz – 10.000 MHz) (pdf)
https://www.mise.gov.it/images/stories/documenti/Tabella_B_2750_MHz-1_Mhz.pdf
Which at page 28 allows the use for ISM according to the general 
European legislation: 2006/771/CE ERC/REC 70-03


--Note (esplicative, di carattere tecnico e con attribuzioni in deroga 
al piano) (pdf)

https://www.mise.gov.it/images/stories/documenti/NOTE-pnrf.pdf
Which at page 334, in the paragraph 3.2.3 states in a explicit way the 
permit to operate the in the band 5.725 ÷ 5.875 MHz,

with SRD and max power at 25 mW.

According to this regulation there's no reason not to have the:
 (5725 - 5875 @ 80), (25 mW)
Inserted for Italy in the regdb

Who can do it ?

--

Giorgio Bernardi

[ANN] wireless-regdb: master-2019-06-03

[Seth Forshee]

A new release of wireless-regdb (master-2019-06-03) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2019.06.03.tar.gz

The short log of changes since the 2019-03-01 release is below.

Thanks,
Seth

---

Peter Oh (1):
  wireless-regdb: Update regulatory rules for South Korea

Seth Forshee (2):
  wireless-regdb: Expand 60 GHz band for Japan to 57-66 GHz
  wireless-regdb: update regulatory database based on preceding changes

Vladimir Koutny (1):
  wireless-regdb: Update regulatory rules for Japan (JP) on 5GHz

Xose Vazquez Perez (2):
  wireless-regdb: update source of information for ES
  wireless-regdb: update source of information for CU

Re: [PATCH] wireless-regdb: update source of information for CU

[Seth Forshee]

On Thu, May 30, 2019 at 01:00:47PM +0200, Xose Vazquez Perez wrote:
> Cc: Seth Forshee 
> Cc: WIRELESS ML 
> Cc: REGDB ML 
> Signed-off-by: Xose Vazquez Perez 

Applied, thanks!

Re: [PATCH] wireless-regdb: Expand 60 GHz band for Japan to 57-66 GHz

[Seth Forshee]

On Wed, May 15, 2019 at 08:26:17AM -0500, Seth Forshee wrote:
> The official documents are not feely available, but based on
> summaries such as [1] and numerous third-party resources the 60
> GHz band in Japan has been 57-66 GHz for some time now. Update
> our rules accordingly.
> 
> [1] https://webstore.arib.or.jp/en/products/detail.php?product_id=288
> 
> Signed-off-by: Seth Forshee 

Applied.

[PATCH] wireless-regdb: update source of information for CU

[Xose Vazquez Perez]

Cc: Seth Forshee 
Cc: WIRELESS ML 
Cc: REGDB ML 
Signed-off-by: Xose Vazquez Perez 
---
 db.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index 6b65312..3bdc7c0 100644
--- a/db.txt
+++ b/db.txt
@@ -316,7 +316,7 @@ country CR: DFS-FCC
(5735 - 5835 @ 20), (30)
 
 # Source:
-# http://www.mincom.gob.cu/?q=marcoregulatorio
+# https://www.mincom.gob.cu/es/marco-legal
 # - Redes Informáticas
 # Resolución 127- 2011 Reglamento de Banda de frecuencias de 2,4 GHz.
 country CU: DFS-FCC
-- 
2.21.0

Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices

[Kalle Valo]

Lorenzo Bianconi  writes:

>> Lorenzo Bianconi  writes:
>> 
>> > Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
>> > aligned buffer sizes for rx") since it breaks A-MSDU support.
>> > When A-MSDU is enable the device can receive frames up to
>> > q->buf_size but they will be discarded in mt76u_process_rx_entry
>> > since there is no enough room for skb_shared_info.
>> > Fix it by introducing q->data_size and take info account
>> > skb_shared_info size in q->buf_size
>> > Moreover increase buffer size even for legacy mode (scatter-gather not
>> > available)
>> >
>> > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes 
>> > for rx")
>> > Signed-off-by: Lorenzo Bianconi 
>> 
>> Felix, can I take this directly to wireless-drivers?
>
> Hi Kalle,
>
> please hold on with this patch, I will post a new one with a different
> approach based on what Felix has suggested me

Ok, thanks for letting me know.

-- 
Kalle Valo

Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices

[Lorenzo Bianconi]

> Lorenzo Bianconi  writes:
> 
> > Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
> > aligned buffer sizes for rx") since it breaks A-MSDU support.
> > When A-MSDU is enable the device can receive frames up to
> > q->buf_size but they will be discarded in mt76u_process_rx_entry
> > since there is no enough room for skb_shared_info.
> > Fix it by introducing q->data_size and take info account
> > skb_shared_info size in q->buf_size
> > Moreover increase buffer size even for legacy mode (scatter-gather not
> > available)
> >
> > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for 
> > rx")
> > Signed-off-by: Lorenzo Bianconi 
> 
> Felix, can I take this directly to wireless-drivers?

Hi Kalle,

please hold on with this patch, I will post a new one with a different
approach based on what Felix has suggested me

Regards,
Lorenzo

> 
> -- 
> Kalle Valo


signature.asc
Description: PGP signature

Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices

[Kalle Valo]

Lorenzo Bianconi  writes:

> Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
> aligned buffer sizes for rx") since it breaks A-MSDU support.
> When A-MSDU is enable the device can receive frames up to
> q->buf_size but they will be discarded in mt76u_process_rx_entry
> since there is no enough room for skb_shared_info.
> Fix it by introducing q->data_size and take info account
> skb_shared_info size in q->buf_size
> Moreover increase buffer size even for legacy mode (scatter-gather not
> available)
>
> Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for 
> rx")
> Signed-off-by: Lorenzo Bianconi 

Felix, can I take this directly to wireless-drivers?

-- 
Kalle Valo

[PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices

[Lorenzo Bianconi]

Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
aligned buffer sizes for rx") since it breaks A-MSDU support.
When A-MSDU is enable the device can receive frames up to
q->buf_size but they will be discarded in mt76u_process_rx_entry
since there is no enough room for skb_shared_info.
Fix it by introducing q->data_size and take info account
skb_shared_info size in q->buf_size
Moreover increase buffer size even for legacy mode (scatter-gather not
available)

Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76.h |  4 
 drivers/net/wireless/mediatek/mt76/usb.c  | 26 ---
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 8ecbf81a906f..f118919ca5ff 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -31,6 +31,9 @@
 #define MT_MCU_RING_SIZE32
 #define MT_RX_BUF_SIZE  2048
 
+#define MT_BUF_WITH_OVERHEAD(x) \
+   ((x) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+
 struct mt76_dev;
 struct mt76_wcid;
 
@@ -124,6 +127,7 @@ struct mt76_queue {
u16 tail;
int ndesc;
int queued;
+   int data_size;
int buf_size;
bool stopped;
 
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
b/drivers/net/wireless/mediatek/mt76/usb.c
index bbaa1365bbda..9e328e4532b3 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -299,7 +299,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue 
*q, struct urb *urb,
 
page = virt_to_head_page(data);
offset = data - page_address(page);
-   sg_set_page(&urb->sg[i], page, q->buf_size, offset);
+   sg_set_page(&urb->sg[i], page, q->data_size, offset);
}
 
if (i < nsgs) {
@@ -311,7 +311,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue 
*q, struct urb *urb,
}
 
urb->num_sgs = max_t(int, i, urb->num_sgs);
-   urb->transfer_buffer_length = urb->num_sgs * q->buf_size,
+   urb->transfer_buffer_length = urb->num_sgs * q->data_size;
sg_init_marker(urb->sg, urb->num_sgs);
 
return i ? : -ENOMEM;
@@ -322,14 +322,13 @@ mt76u_refill_rx(struct mt76_dev *dev, struct urb *urb, 
int nsgs, gfp_t gfp)
 {
struct mt76_queue *q = &dev->q_rx[MT_RXQ_MAIN];
 
-   if (dev->usb.sg_en) {
+   if (dev->usb.sg_en)
return mt76u_fill_rx_sg(dev, q, urb, nsgs, gfp);
-   } else {
-   urb->transfer_buffer_length = q->buf_size;
-   urb->transfer_buffer = page_frag_alloc(&q->rx_page,
-  q->buf_size, gfp);
-   return urb->transfer_buffer ? 0 : -ENOMEM;
-   }
+
+   urb->transfer_buffer_length = q->data_size;
+   urb->transfer_buffer = page_frag_alloc(&q->rx_page, q->buf_size, gfp);
+
+   return urb->transfer_buffer ? 0 : -ENOMEM;
 }
 
 static int
@@ -446,8 +445,9 @@ mt76u_process_rx_entry(struct mt76_dev *dev, struct urb 
*urb)
return 0;
 
data_len = min_t(int, len, data_len - MT_DMA_HDR_LEN);
-   if (MT_DMA_HDR_LEN + data_len > SKB_WITH_OVERHEAD(q->buf_size)) {
-   dev_err_ratelimited(dev->dev, "rx data too big %d\n", data_len);
+   if (MT_DMA_HDR_LEN + data_len > q->data_size) {
+   dev_err_ratelimited(dev->dev, "rx data too big %d\n",
+   data_len);
return 0;
}
 
@@ -577,8 +577,10 @@ static int mt76u_alloc_rx(struct mt76_dev *dev)
if (!q->entry)
return -ENOMEM;
 
-   q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
+   q->data_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
+   q->buf_size = MT_BUF_WITH_OVERHEAD(q->data_size);
q->ndesc = MT_NUM_RX_ENTRIES;
+
for (i = 0; i < q->ndesc; i++) {
err = mt76u_rx_urb_alloc(dev, &q->entry[i]);
if (err < 0)
-- 
2.21.0

Re: [wireless-regdb] [PATCH v3] wireless-regdb: Update regulatory rules for South Korea

[Seth Forshee]

On Wed, May 15, 2019 at 07:28:29PM +, Peter Oh wrote:
> From: Peter Oh 
> 
> Update power limit as documented in:
> http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/
> %EC%8B%A0%EA%B3%A0%ED%95%98%EC%A7%80%EC%95%84%EB%8B%88%ED
> %95%98%EA%B3%A0%EA%B0%9C%EC%84%A4%ED%95%A0%EC%88%98%EC%9E
> %88%EB%8A%94%EB%AC%B4%EC%84%A0%EA%B5%AD%EC%9A%A9%EB%AC%B4
> %EC%84%A0%EA%B8%B0%EA%B8%B0/(2018-89,20181227)
> which revised on December 27, 2018.
> 
> Signed-off-by: Peter Oh 

Applied, thanks!

[PATCH] net: wireless: p54: fix crash during initialization

[Christian Lamparter]

This patch fixes a crash that got introduced when the
mentioned patch replaced  the direct list_head access
with skb_peek_tail(). When the device is starting up,
there are  no entries in  the queue, so previously to
"Use skb_peek_tail() instead..." the target_skb would
end up as the  tail and head pointer which then could
be used by __skb_queue_after to fill the empty queue.

With skb_peek_tail() in its place will instead just
return NULL which then causes a crash in the
__skb_queue_after().

| BUG: unable to handle kernel NULL pointer dereference at 00
| #PF error: [normal kernel read fault]
| PGD 0 P4D 0
| Oops:  [#1] SMP PTI
| CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: GO   5.1.0-rc7-wt+ #218
| Hardware name: MSI MS-7816/Z87-G43 (MS-7816), BIOS V1.11 05/09/2015
| Workqueue: events request_firmware_work_func
| RIP: 0010:p54_tx_pending+0x10f/0x1b0 [p54common]
| Code: 78 06 80 78 28 00 74 6d <48> 8b 07 49 89 7c 24 08 49 89 04 24 4
| RSP: 0018:a81c81927d90 EFLAGS: 00010086
| RAX: 9bbaaf131048 RBX: 00020670 RCX: 00020264
| RDX: 9bbaa976d660 RSI: 0202 RDI: 
| RBP: 9bbaa976d620 R08: 06c0 R09: 9bbaa976d660
| R10:  R11: e8480dbc5900 R12: 9bbb45e87700
| R13: 9bbaa976d648 R14: 9bbaa976d674 R15: 9bbaaf131048
| FS:  () GS:9bbb5ec0() knlGS:0
| CS:  0010 DS:  ES:  CR0: 80050033
| CR2:  CR3: 0003695fc003 CR4: 001606f0
| Call Trace:
|  p54_download_eeprom+0xbe/0x120 [p54common]
|  p54_read_eeprom+0x7f/0xc0 [p54common]
|  p54u_load_firmware_cb+0xe0/0x160 [p54usb]
|  request_firmware_work_func+0x42/0x80
|  process_one_work+0x1f5/0x3f0
|  worker_thread+0x28/0x3c0

Cc: sta...@vger.kernel.org
Fixes: e3554197fc8f ("p54: Use skb_peek_tail() instead of direct head pointer 
accesses.")
Signed-off-by: Christian Lamparter 
---
 drivers/net/wireless/intersil/p54/txrx.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/p54/txrx.c 
b/drivers/net/wireless/intersil/p54/txrx.c
index 790784568ad2..5bf1c19ecced 100644
--- a/drivers/net/wireless/intersil/p54/txrx.c
+++ b/drivers/net/wireless/intersil/p54/txrx.c
@@ -142,7 +142,10 @@ static int p54_assign_address(struct p54_common *priv, 
struct sk_buff *skb)
unlikely(GET_HW_QUEUE(skb) == P54_QUEUE_BEACON))
priv->beacon_req_id = data->req_id;
 
-   __skb_queue_after(&priv->tx_queue, target_skb, skb);
+   if (target_skb)
+   __skb_queue_after(&priv->tx_queue, target_skb, skb);
+   else
+   __skb_queue_head(&priv->tx_queue, skb);
spin_unlock_irqrestore(&priv->tx_queue.lock, flags);
return 0;
 }
-- 
2.20.1

[PATCH v3] wireless-regdb: Update regulatory rules for South Korea

[Peter Oh]

From: Peter Oh 

Update power limit as documented in:
http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/
%EC%8B%A0%EA%B3%A0%ED%95%98%EC%A7%80%EC%95%84%EB%8B%88%ED
%95%98%EA%B3%A0%EA%B0%9C%EC%84%A4%ED%95%A0%EC%88%98%EC%9E
%88%EB%8A%94%EB%AC%B4%EC%84%A0%EA%B5%AD%EC%9A%A9%EB%AC%B4
%EC%84%A0%EA%B8%B0%EA%B8%B0/(2018-89,20181227)
which revised on December 27, 2018.

Signed-off-by: Peter Oh 
---
 db.txt | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/db.txt b/db.txt
index 4fb1948..6e5019f 100644
--- a/db.txt
+++ b/db.txt
@@ -695,11 +695,12 @@ country KP: DFS-JP
(5735 - 5815 @ 20), (30)
 
 country KR: DFS-JP
-   (2402 - 2482 @ 40), (13)
-   (5170 - 5250 @ 80), (20), AUTO-BW
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
-   (5490 - 5710 @ 160), (30), DFS
-   (5735 - 5835 @ 80), (30)
+   # ref: https://www.rra.go.kr
+   (2400 - 2483.5 @ 40), (23)
+   (5150 - 5250 @ 80), (23), AUTO-BW
+   (5250 - 5350 @ 80), (20), DFS, AUTO-BW
+   (5470 - 5725 @ 160), (20), DFS
+   (5725 - 5835 @ 80), (23)
# 60 GHz band channels 1-4,
# ref: 
http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
(57000 - 66000 @ 2160), (43)
-- 
2.7.4