* [PATCH 1/5] qtnfmac: modify full Tx queue error reporting
From: Sergey Matyukevich @ 2017-10-15 20:53 UTC (permalink / raw)
To: linux-wireless
Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov, Sergey Matyukevich
In-Reply-To: <20171015205327.9966-1-sergey.matyukevich.os@quantenna.com>
Under heavy load it is normal that h/w Tx queue is almost full all the time
and reclaim should be done before transmitting next packet. Warning still
should be reported as well as s/w Tx queues should be stopped in the
case when reclaim failed.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 502e72b7cdcc..a8f2c46f3a25 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -643,11 +643,11 @@ static int qtnf_tx_queue_ready(struct qtnf_pcie_bus_priv *priv)
{
if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
priv->tx_bd_num)) {
- pr_err_ratelimited("reclaim full Tx queue\n");
qtnf_pcie_data_tx_reclaim(priv);
if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
priv->tx_bd_num)) {
+ pr_warn_ratelimited("reclaim full Tx queue\n");
priv->tx_full_count++;
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 0/8] qtnfmac: misc small features and fixes
From: Sergey Matyukevich @ 2017-10-15 20:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov
Hello Kalle, Igor, and all
This patch series includes a number of small features and fixes
for qtnfmac driver.
Igor Mitsyanko (1):
qtnfmac: advertise support of inactivity timeout
Sergey Matyukevich (4):
qtnfmac: modify full Tx queue error reporting
qtnfmac: enable registration of more mgmt frames
qtnfmac: drop nonexistent function declaration
qtnfmac: modify full Tx queue recovery
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 17 +++++++++++++++--
drivers/net/wireless/quantenna/qtnfmac/commands.c | 5 +++--
drivers/net/wireless/quantenna/qtnfmac/core.c | 27 +++++++++++++++++++++++++++
drivers/net/wireless/quantenna/qtnfmac/core.h | 4 +---
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 15 +++++++++------
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h | 1 +
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 11 ++++++++++-
7 files changed, 66 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: iwlwifi crash with hostapd
From: Mario Theodoridis @ 2017-10-15 16:21 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20171012212454.GB4362@us.netrek.org>
Thanks for the pointers, James.
On 12.10.2017 23:24, James Cameron wrote:
> There's a good chance this problem has been fixed already. You
> are using a v4.4 kernel with many patches applied by Ubuntu. Here, we
> are more concerned with the latest kernels, and v4.4 is quite old.
>
> Please test some of the later kernels, see
> https://wiki.ubuntu.com/Kernel/MainlineBuilds
>
> In particular, test v4.13 or v4.14-rc4.
I'm having a hard time with that, because the virtualbox-dkms build
fails with the 4.13 kernel, and virtualbox unfortunately is essential.
>
> If the problem still happens, capture the same information and send it
> again as a reply.
>
> If the problem doesn't happen, then you can either continue to use the
> new kernel, or find when the problem was fixed; a long but rewarding
> process.
>
> Should the problem have been fixed for v4.10, you might also switch to
> using the Ubuntu package linux-generic-hwe-16.04.
> https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#hwe-16.04
The 4.10 kernel readily produced this one
------------[ cut here ]------------
WARNING: CPU: 4 PID: 1617 at
/build/linux-hwe-IJy1zi/linux-hwe-4.10.0/drivers/net/wireless/intel/iwlwifi/mvm/tx.c:510
iwl_mvm_tx_skb_non_sta+0x39a/0x440 [iwlmvm]
Modules linked in: bnep ccm pci_stub vboxpci(OE) vboxnetadp(OE)
vboxnetflt(OE) vboxdrv(OE) nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
iptable_filter ip_tables x_tables snd_hda_codec_hdmi arc4 iwlmvm
mac80211 snd_hda_codec_realtek snd_hda_codec_generic intel_rapl
x86_pkg_temp_thermal intel_powerclamp iwlwifi coretemp snd_hda_intel
snd_hda_codec kvm_intel snd_hda_core snd_hwdep kvm input_leds irqbypass
crct10dif_pclmul snd_pcm bridge crc32_pclmul joydev stp llc
ghash_clmulni_intel snd_seq_midi pcbc snd_seq_midi_event snd_rawmidi
aesni_intel snd_seq aes_x86_64 crypto_simd snd_seq_device glue_helper
cfg80211 cryptd snd_timer intel_cstate snd intel_rapl_perf soundcore
shpchp mei_me hci_uart mei btbcm btqca btintel bluetooth intel_lpss_acpi
acpi_als mac_hid intel_lpss kfifo_buf tpm_infineon industrialio
acpi_pad parport_pc ppdev lp parport autofs4 i915 e1000e i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops e100
hid_generic ptp i2c_hid ahci mii drm pps_core pinctrl_sunrisepoint
libahci usbhid e1000 hid wmi video pinctrl_intel fjes
CPU: 4 PID: 1617 Comm: hostapd Tainted: G OE
4.10.0-37-generic #41~16.04.1-Ubuntu
Hardware name: Gigabyte Technology Co., Ltd. Z170M-D3H/Z170M-D3H-CF,
BIOS F20 11/17/2016
Call Trace:
dump_stack+0x63/0x90
__warn+0xcb/0xf0
warn_slowpath_null+0x1d/0x20
iwl_mvm_tx_skb_non_sta+0x39a/0x440 [iwlmvm]
iwl_mvm_mac_tx+0x11e/0x1d0 [iwlmvm]
ieee80211_tx_frags+0x14b/0x220 [mac80211]
__ieee80211_tx+0x81/0x180 [mac80211]
ieee80211_tx+0x10f/0x150 [mac80211]
ieee80211_xmit+0x9b/0xf0 [mac80211]
__ieee80211_tx_skb_tid_band+0x5c/0x70 [mac80211]
ieee80211_mgmt_tx+0x42c/0x4a0 [mac80211]
cfg80211_mlme_mgmt_tx+0xdc/0x310 [cfg80211]
nl80211_tx_mgmt+0x212/0x360 [cfg80211]
genl_family_rcv_msg+0x1db/0x3b0
? skb_queue_tail+0x43/0x50
genl_rcv_msg+0x59/0xa0
? genl_notify+0x80/0x80
netlink_rcv_skb+0xa4/0xc0
genl_rcv+0x28/0x40
netlink_unicast+0x18c/0x240
netlink_sendmsg+0x2fb/0x3a0
? aa_sock_msg_perm+0x61/0x150
sock_sendmsg+0x38/0x50
___sys_sendmsg+0x2c2/0x2d0
? sock_sendmsg+0x38/0x50
? SYSC_sendto+0x101/0x190
? __check_object_size+0x108/0x1e3
? _copy_to_user+0x55/0x60
__sys_sendmsg+0x54/0x90
SyS_sendmsg+0x12/0x20
entry_SYSCALL_64_fastpath+0x1e/0xad
RIP: 0033:0x7fcc38cfe450
RSP: 002b:00007fffdefc9b18 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000563e91285590 RCX: 00007fcc38cfe450
RDX: 0000000000000000 RSI: 00007fffdefc9ba0 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000563e91283a70
R10: 0000000000001000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000009 R14: 0000000000000000 R15: 0000000000000000
---[ end trace 4d9a544d3976536e ]---
--
Mit freundlichen Grüßen/Best regards
Mario Theodoridis
^ permalink raw reply
* [PATCH] wireless-regdb: add Short Range Devices (SRD) (ETSI EN 300 440) for Spain
From: Xose Vazquez Perez @ 2017-10-15 13:46 UTC (permalink / raw)
Cc: Xose Vazquez Perez, Seth Forshee, linux-wireless, wireless-regdb
UN - 130 Dispositivos de corto alcance en 5 GHz :
https://www.boe.es/buscar/act.php?id=BOE-A-2013-4845&tn=1&p=20150410
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: linux-wireless@vger.kernel.org
Cc: wireless-regdb@lists.infradead.org
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
db.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/db.txt b/db.txt
index e48f9a6..1509491 100644
--- a/db.txt
+++ b/db.txt
@@ -431,6 +431,8 @@ country ES: DFS-ETSI
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (500 mW), DFS
+ # Short Range Devices (SRD) (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
--
2.14.2
^ permalink raw reply related
* Re: [PATCH] iw: add command to register and capture mgmt frames
From: Julian Calaby @ 2017-10-15 13:41 UTC (permalink / raw)
To: Steve deRosier, Johannes Berg, linux-wireless, Igor Mitsyanko,
Avinash Patil
In-Reply-To: <20171015095133.prxuuukv6osx52td@bars>
Hi Sergey,
On Sun, Oct 15, 2017 at 8:51 PM, Sergey Matyukevich
<sergey.matyukevich.os@quantenna.com> wrote:
>> > Add new command to register for receiving multiple mgmt frames,
>> > capture and print them. Frames are selected by their type and
>> > pattern containing their the first several bytes of the frame
>> > that should match.
>> >
>>
>> Forgive me for asking, what does this provide that isn't already
>> available in tshark? And since we already have user-space tools
>> tailored for capturing and filtering any frames, including management
>> frames, why do we need to add this to iw?
>
> IIUC tshark and other specific capture tools need wireless netdevice to be
> in monitor mode. This particular iw command is based on NL80211_CMD_REGISTER_FRAME
> and related cfg80211 ops. In fact, this command can be used to subscribe
> to mgmt frames when wireless device is up and running in AP or STA mode.
> That can be convenient for monitor and debug purposes. There is a
> limitation though: currently cfg80211 core allows only one subscriber
> for each particular frame/pattern.
Stupid question: Can Wireshark / Tshark be taught how to do this?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH] iw: add command to register and capture mgmt frames
From: Sergey Matyukevich @ 2017-10-15 9:51 UTC (permalink / raw)
To: Steve deRosier
Cc: Johannes Berg, linux-wireless, Igor Mitsyanko, Avinash Patil
In-Reply-To: <CALLGbR+DonvXRDysZGx3fJ0wGQsmnWNW3db7mv9KObwTcicnOg@mail.gmail.com>
> > Add new command to register for receiving multiple mgmt frames,
> > capture and print them. Frames are selected by their type and
> > pattern containing their the first several bytes of the frame
> > that should match.
> >
>
> Forgive me for asking, what does this provide that isn't already
> available in tshark? And since we already have user-space tools
> tailored for capturing and filtering any frames, including management
> frames, why do we need to add this to iw?
IIUC tshark and other specific capture tools need wireless netdevice to be
in monitor mode. This particular iw command is based on NL80211_CMD_REGISTER_FRAME
and related cfg80211 ops. In fact, this command can be used to subscribe
to mgmt frames when wireless device is up and running in AP or STA mode.
That can be convenient for monitor and debug purposes. There is a
limitation though: currently cfg80211 core allows only one subscriber
for each particular frame/pattern.
It looks like 'capture' part of commit message is a bit confusing.
Regards,
Sergey
^ permalink raw reply
* RE: wl1837: poor performance?
From: Reizer, Eyal @ 2017-10-15 7:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless@vger.kernel.org, Altshul, Maxim, Narang, Saurabh,
Loewy, Chen
Hi Russel,
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@armlinux.org.uk]
> Sent: Saturday, October 14, 2017 2:30 PM
> To: Reizer, Eyal
> Cc: linux-wireless@vger.kernel.org; Altshul, Maxim; Narang, Saurabh
> Subject: Re: wl1837: poor performance?
>=20
> On Fri, Oct 13, 2017 at 07:43:37AM +0000, Reizer, Eyal wrote:
> > Sorry for top posting.
> > Signal level on wlan0 seems low (-79 dbm) are you sure there are antenn=
as
> > connected?
>=20
> Thanks for the reply.
>=20
> In development environments, it's common to have the AP and station
> nearby, which will give good signal. Out of the development
> environment, the AP and station may be separated by several 10s of ft
> and objects in the way. That's the case here, so about -80dBm is to
> be expected.
>=20
> As I mentioned, there's two stations each with different chipsets, both
> with the same signal level being reported, both at a similar distance
> from the AP, but one performs way better than the other. I've found
> the reason for this (see below.)
>=20
> I should also mention that this is installed remotely, and I'm debugging
> it over the 'net, involving this very Wi-Fi connection.
>=20
> The radio environment is not excessively populated - both systems are
> within a tower with >2ft thick stone and lime mortar walls which radio
> has difficulty penetrating, which is itself in a park with very few
> other buildings around. I'm using the 2.4G channel 8, I've seen some
> other APs on channel 1 when outside but almost never inside the tower.
>=20
> nmcli (used to?) occasionally reports that the wl1837 can see another
> AP ("CARWIFI") on channel 1, but that's rare - I suspect it requires
> someone to park their car in direct line of literal sight through a
> tower window from the machine. I suspect NM noticed that before I
> configured the BSSID of the associated AP as I haven't recently
> noticed NM reporting any other networks. Could also be that non-wifi
> enabled cars are parked in those spaces!
>=20
> > In addition what type of module is used here?
>=20
> It's a WL1837 integrated onto SolidRun's iMX6 microsom. I'm not sure
> what other information in terms of "module" you're asking for.
Do you know what type of wilink8 module is installed with this SOM board?
Is it a TI module similar to this one?:
http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
>=20
> > Di you use the configure_device.sh scripts as documented in the
> > "wlconf" manual?
>=20
> No, because quite honestly the wilink tooling is something of a mess
> in terms of trying to find the right tooling. This is what I ended
> up doing:
Wlconf should be taken from:
https://git.ti.com/wilink8-wlan/18xx-ti-utils/trees/R8.7_SP2
I think you have used something a bit outdated.
You can see the following wiki for building all latest components:
http://processors.wiki.ti.com/index.php/WL18xx_System_Build_Scripts
You can use the build script for building just the "utils" part if you just=
need wlconf. You can also use the git above directly.
Once elconf is build and installed you will see the following script in you=
r rootfs:
https://git.ti.com/wilink8-wlan/18xx-ti-utils/blobs/R8.7_SP2/wlconf/configu=
re-device.sh
That you just need to run once, answering the relevant questions and it wil=
l create wl18xx-conf.bin for you.
There is no need for manually editing any files.
See the following document as well:
http://www.ti.com/lit/an/swra489/swra489.pdf
You can follow section 2 of this document.
>=20
> 1. cloning git://github.com/TI-OpenLink/18xx-ti-utils
> 2. taking the wl18xx driver default configuration (from debugfs).
> 3. taking the ti wilink driver conf.h files.
> 4. massaging the conf.h files into a form that wlconf can read
> 5. generating a new struct.bin
> 6. changing:
> wl18xx.phy.number_of_assembled_ant2_4 =3D 0x01
> wl18xx.phy.number_of_assembled_ant5 =3D 0x00
>=20
> since this variant of the microsom I have only populates one antenna.
> (The layout allows for the design to be extended to a second antenna.)
>=20
> I've since found the _right_ repository for the tooling
> (git://git.ti.com/wilink8-wlan/18xx-ti-utils.git), and compared the
> resulting files, and confirmed that my new struct.bin is identical to
> the one in the right repository.
>=20
> There are some differences between the two files (- =3D mine,
> + =3D configure_device.sh generated):
>=20
> -core.sg.params =3D 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x000000aa, 0x00000032,
> 0x00000000, 0x00000000, 0x00000000, 0x000000c8, 0x00000000, 0x00000000,
> 0x00000000, 0x00000001, 0x00000000, 0x0000003c, 0x00000000, 0x000004b0,
> 0x00000000, 0x00000001, 0x00000003, 0x00000006, 0x00000000, 0x00000000,
> 0x00000002, 0x00000000, 0x00000000, 0x00000003, 0x00000000, 0x00000002,
> 0x0000001e, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000
> +core.sg.params =3D 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x0000000f, 0x0000001b, 0x00000011, 0x000000aa, 0x00000032,
> 0x00000064, 0x00000320, 0x000000c8, 0x000000c8, 0x00000000, 0x00000000,
> 0x00000000, 0x00000001, 0x00000000, 0x0000003c, 0x00001388, 0x000004b0,
> 0x000003e8, 0x00000001, 0x00000003, 0x00000006, 0x0000000a, 0x0000000a,
> 0x00000002, 0x00000005, 0x0000001e, 0x00000003, 0x0000000a, 0x00000002,
> 0x00000000, 0x00000019, 0x00000019, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
> 0x00000000, 0x00000000, 0x00000000
> -core.conn.dynamic_ps_timeout =3D 0x05dc
> +core.conn.dynamic_ps_timeout =3D 0x0096
> -core.sched_scan.num_short_intervals =3D 0x0e
> +core.sched_scan.num_short_intervals =3D 0x0d
> -core.fwlog.mem_blocks =3D 0x00
> +core.fwlog.mem_blocks =3D 0x02
> -wl18xx.ap_sleep.max_stations_thresh =3D 0x00
> -wl18xx.ap_sleep.idle_conn_thresh =3D 0x00
> +wl18xx.ap_sleep.max_stations_thresh =3D 0x04
> +wl18xx.ap_sleep.idle_conn_thresh =3D 0x08
>=20
> The core.sg.param differences in an easier to read format are:
> mine configure_device.sh
> [23] 0x00000000 =3D> 0x0000000f WL18XX_CONF_SG_PARAM_23
> [24] 0x00000000 =3D> 0x0000001b WL18XX_CONF_SG_PARAM_24
> [25] 0x00000000 =3D> 0x00000011 WL18XX_CONF_SG_PARAM_25
> [28] 0x00000000 =3D> 0x00000064 WL18XX_CONF_SG_PARAM_28
> [29] 0x00000000 =3D> 0x00000320 WL18XX_CONF_SG_PARAM_29
> [30] 0x00000000 =3D> 0x000000c8 WL18XX_CONF_SG_PARAM_30
> [38] 0x00000000 =3D> 0x00001388 WL18XX_CONF_SG_PARAM_38
> [40] 0x00000000 =3D> 0x000003e8 WL18XX_CONF_SG_UNUSED
> [44] 0x00000000 =3D> 0x0000000a WL18XX_CONF_SG_PARAM_44
> [45] 0x00000000 =3D> 0x0000000a WL18XX_CONF_SG_PARAM_45
> [47] 0x00000000 =3D> 0x00000005 WL18XX_CONF_SG_GEMINI_PARAM_47
> [48] 0x00000000 =3D> 0x0000001e
> WL18XX_CONF_SG_STA_CONNECTION_PROTECTION_TIME
> [50] 0x00000000 =3D> 0x0000000a WL18XX_CONF_SG_PARAM_50
> [52] 0x0000001e =3D> 0x00000000
> WL18XX_CONF_SG_AP_CONNECTION_PROTECTION_TIME
> [53] 0x00000000 =3D> 0x00000019 WL18XX_CONF_SG_PARAM_53
> [54] 0x00000000 =3D> 0x00000019 WL18XX_CONF_SG_PARAM_54
>=20
You don't normally need to change anything, especially as you are using a s=
tandard wl18xx module.
> In any case, I eventually tracked down the reason for the 10ms pings - it
> seems the iMX6 host SDHCI aggressively enters PM, with the autosuspend
> delay is set to 50ms. Disabling runtime PM on the host results in ping
> times around what I would expect - between 2 to 4ms.
>=20
> > In addition, for the recovery. Are you using latest firmware (8.9.0.0.7=
0)?
>=20
> I'm using 8.9.0.0.75, which seems to be the latest as of 19th June,
> which came from https://git.ti.com/wilink8-wlan/wl18xx_fw
>=20
Yes, you are using latest firmware.
> The recovery doesn't seem to be a regular thing - I've only seen it
> once so far, and it was non-fatal.
Can you send us the recovery log next time you see it? It is not fatal as y=
ou have noted but still
Should be very rare and interesting for us to see if there is any meaningfu=
l information there.
>=20
>=20
> However, I have one lingering difference between the wl1837 and rtl8192eu
> stations. If I set both up identically - with a BSS MAC address, thus
> telling them that they should only associate with an AP with that MAC,
> I find that rtl8192eu doesn't go off-channel to scan for APs, and has
> pretty a stable ping RTT.
>=20
> However, the wl1837 seems to end up with a ping RTT of about 110ms every
> 32s or so. I tried increasing "core.sched_scan.long_interval" in the
> conf file to 40000, and this seemed to increase this to about once every
> 50s.
>=20
> I've tried disabling the scheduled scan code in the wl18xx driver, but
> that doesn't seem to have made a difference. I've also tried telling
> wpa_supplicant not to scan (wpa_cli set pon) but that also doesn't seem
> to make a difference. I don't think it's NetworkManager triggering the
> scans, as both the wl1837 and rtl8192eu are setup identically, and
> stracing NM only shows it polling for the signal level/bit rate etc -
> and from what I read, configuring the connection with a BSSID stops
> NM scanning for roaming.
>=20
I don't think you need to change these values.
Your issue should not be related to these settings.
> It doesn't seem to be causing a problem, but it would be nice to get
> rid of the additional latency if possible. Obviously, it does need
> to scan initially, so NM/wpa_supplicant can associate with the AP.
>=20
> With "core.sched_scan.long_interval" set back to 30000, and the
> scheduled scan code in the wl18xx driver disabled, I'm seeing:
>=20
> 64 bytes from 192.168.250.1: icmp_seq=3D25 ttl=3D64 time=3D2.68 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D26 ttl=3D64 time=3D114 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D27 ttl=3D64 time=3D3.58 ms
> ...
> 64 bytes from 192.168.250.1: icmp_seq=3D65 ttl=3D64 time=3D2.58 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D66 ttl=3D64 time=3D107 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D67 ttl=3D64 time=3D2.71 ms
> ...
> 64 bytes from 192.168.250.1: icmp_seq=3D105 ttl=3D64 time=3D3.04 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D106 ttl=3D64 time=3D110 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D107 ttl=3D64 time=3D3.42 ms
> ...
> 64 bytes from 192.168.250.1: icmp_seq=3D145 ttl=3D64 time=3D3.18 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D146 ttl=3D64 time=3D109 ms
> 64 bytes from 192.168.250.1: icmp_seq=3D147 ttl=3D64 time=3D3.27 ms
>=20
> Any ideas?
>=20
Two suggestions:
Are you seeing this if disabling power save:
iw wlan0 set power_save off
Maybe unrelated, but can you also check if your kernel is configured with =
the following TCP congestion settings:
CONFIG_TCP_CONG_ADVANCED=3Dy
CONFIG_DEFAULT_RENO=3Dy
CONFIG_DEFAULT_TCP_CONG=3D"reno"
This has helped customers in the past using latest kernels that had TCP uns=
table performance issues.
Best Regards,
Eyal
^ permalink raw reply
* [PATCH] rtlwifi: Fix typo in if ... else if ... else construct
From: Larry Finger @ 2017-10-15 1:54 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, Larry Finger, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting, kbuild-all, Julia Lawall
The kbuild test robot reports two conditions with no effect (if == else).
These are the result of copy and paste typographical errors.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Cc: kbuild-all@01.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
---
Kalle,
This material is for the 4.15 stream.
Larry
---
drivers/net/wireless/realtek/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
index ea18aa7afecb..66737f6b7359 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -835,7 +835,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x000c) >> 2 ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
@@ -847,7 +847,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x0003) ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
--
2.12.3
^ permalink raw reply related
* Re: pull-request: mac80211-next 2017-10-13
From: David Miller @ 2017-10-15 1:37 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20171013155332.4310-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 13 Oct 2017 17:53:31 +0200
> Sorry for the quick succession - there were a few issues with
> the last pull request that only got noticed now, so I'm fixing
> those here.
>
> Please pull and let me know if there's any problem.
No worries, pulled, thanks Johannes.
^ permalink raw reply
* Re: [PATCH] iw: add command to register and capture mgmt frames
From: Steve deRosier @ 2017-10-14 22:15 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: Johannes Berg, linux-wireless, Igor Mitsyanko, Avinash Patil
In-Reply-To: <20171014210036.29556-1-sergey.matyukevich.os@quantenna.com>
Hi Sergey,
On Sat, Oct 14, 2017 at 2:00 PM, Sergey Matyukevich
<sergey.matyukevich.os@quantenna.com> wrote:
> Add new command to register for receiving multiple mgmt frames,
> capture and print them. Frames are selected by their type and
> pattern containing their the first several bytes of the frame
> that should match.
>
Forgive me for asking, what does this provide that isn't already
available in tshark? And since we already have user-space tools
tailored for capturing and filtering any frames, including management
frames, why do we need to add this to iw?
- Steve
^ permalink raw reply
* [PATCH] iw: add command to register and capture mgmt frames
From: Sergey Matyukevich @ 2017-10-14 21:00 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich
Add new command to register for receiving multiple mgmt frames,
capture and print them. Frames are selected by their type and
pattern containing their the first several bytes of the frame
that should match.
Format:
$ iw dev <devname> frame <type> <pattern> [frame <type> <pattern>]* [count <frames>]
Example:
$ iw dev wlan0 mgmt capture frame 40 00 frame 40 01:02 count 10
Frame type is supplied as hex w/o leading 0x. Frame pattern is supplied
as hex pattern of the form aa:bb:cc w/o leading 0x as well.
Count is a number of frames to capture.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
Makefile | 2 +-
mgmt.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 150 insertions(+), 1 deletion(-)
create mode 100644 mgmt.c
diff --git a/Makefile b/Makefile
index e61825e..38d782d 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ OBJS = iw.o genl.o event.o info.o phy.o \
interface.o ibss.o station.o survey.o util.o ocb.o \
mesh.o mpath.o mpp.o scan.o reg.o version.o \
reason.o status.o connect.o link.o offch.o ps.o cqm.o \
- bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o
+ bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o mgmt.o
OBJS += sections.o
OBJS-$(HWSIM) += hwsim.o
diff --git a/mgmt.c b/mgmt.c
new file mode 100644
index 0000000..c42d802
--- /dev/null
+++ b/mgmt.c
@@ -0,0 +1,149 @@
+#include <string.h>
+#include <errno.h>
+
+#include <netlink/genl/genl.h>
+#include <netlink/genl/family.h>
+#include <netlink/genl/ctrl.h>
+#include <netlink/msg.h>
+#include <netlink/attr.h>
+
+#include "nl80211.h"
+#include "iw.h"
+
+SECTION(mgmt);
+
+static int seq_handler(struct nl_msg *msg, void *arg)
+{
+ return NL_OK;
+}
+
+static int dump_mgmt_frame(struct nl_msg *msg, void *arg)
+{
+ struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+ struct nlattr *tb_msg[NL80211_ATTR_MAX + 1];
+
+ nla_parse(tb_msg, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+ genlmsg_attrlen(gnlh, 0), NULL);
+
+ if (tb_msg[NL80211_ATTR_WIPHY_FREQ]) {
+ uint32_t freq = nla_get_u32(tb_msg[NL80211_ATTR_WIPHY_FREQ]);
+ printf("freq %u MHz\n", freq);
+ }
+
+ if (tb_msg[NL80211_ATTR_RX_SIGNAL_DBM]) {
+ uint32_t dbm = nla_get_u32(tb_msg[NL80211_ATTR_RX_SIGNAL_DBM]);
+ printf("signal %u dbm\n", dbm);
+ }
+
+ if (tb_msg[NL80211_ATTR_FRAME]) {
+ int len = nla_len(tb_msg[NL80211_ATTR_FRAME]);
+ uint8_t *data = nla_data(tb_msg[NL80211_ATTR_FRAME]);
+ iw_hexdump("mgmt frame", data, len);
+ }
+
+ return 0;
+}
+
+static int register_mgmt_frame(struct nl80211_state *state,
+ struct nl_msg *msg, int argc, char **argv,
+ enum id_input id)
+{
+ unsigned int type;
+ unsigned char *match;
+ size_t match_len;
+ int ret;
+
+ ret = sscanf(argv[0], "%x", &type);
+ if (ret != 1) {
+ printf("invalid frame type: %s\n", argv[0]);
+ return 2;
+ }
+
+ match = parse_hex(argv[1], &match_len);
+ if (!match) {
+ printf("invalid frame pattern: %s\n", argv[1]);
+ return 2;
+ }
+
+ NLA_PUT_U16(msg, NL80211_ATTR_FRAME_TYPE, type);
+ NLA_PUT(msg, NL80211_ATTR_FRAME_MATCH, match_len, match);
+
+ return 0;
+
+nla_put_failure:
+ return -ENOBUFS;
+}
+
+static int handle_mgmt_reg(struct nl80211_state *state,
+ struct nl_msg *msg, int argc,
+ char **argv, enum id_input id)
+{
+ return register_mgmt_frame(state, msg, argc, argv, id);
+}
+
+HIDDEN(mgmt, reg, "", NL80211_CMD_REGISTER_FRAME, 0, CIB_NETDEV, handle_mgmt_reg);
+
+static int handle_mgmt_capture(struct nl80211_state *state,
+ struct nl_msg *msg, int argc,
+ char **argv, enum id_input id)
+{
+ struct nl_cb *mgmt_cb;
+ char *ndev = argv[0];
+ int mgmt_argc = 5;
+ char **mgmt_argv;
+ unsigned int count = 0;
+ int err = 0;
+ int i;
+
+ mgmt_argv = calloc(mgmt_argc, sizeof(char*));
+ if (!mgmt_argv)
+ return -ENOMEM;
+
+ mgmt_argv[0] = ndev;
+ mgmt_argv[1] = "mgmt";
+ mgmt_argv[2] = "reg";
+
+ for (i = 3; i < argc; i += 3) {
+ if (strcmp(argv[i], "count") == 0) {
+ count = 1 + atoi(argv[i + 1]);
+ break;
+ }
+
+ if (strcmp(argv[i], "frame") != 0) {
+ err = 1;
+ goto out;
+ }
+
+ mgmt_argv[3] = argv[i + 1];
+ mgmt_argv[4] = argv[i + 2];
+
+ err = handle_cmd(state, II_NETDEV, mgmt_argc, mgmt_argv);
+ if (err)
+ goto out;
+ }
+
+ mgmt_cb = nl_cb_alloc(iw_debug ? NL_CB_DEBUG : NL_CB_DEFAULT);
+ if (!mgmt_cb) {
+ err = 1;
+ goto out;
+ }
+
+ /* need to turn off sequence number checking */
+ nl_cb_set(mgmt_cb, NL_CB_SEQ_CHECK, NL_CB_CUSTOM, seq_handler, NULL);
+ nl_cb_set(mgmt_cb, NL_CB_VALID, NL_CB_CUSTOM, dump_mgmt_frame, NULL);
+
+ while (--count)
+ nl_recvmsgs(state->nl_sock, mgmt_cb);
+
+ nl_cb_put(mgmt_cb);
+out:
+ free(mgmt_argv);
+ return err;
+}
+
+COMMAND(mgmt, capture, "frame <type as hex ab> <pattern as hex ab:cd:..> [frame <type> <pattern>]* [count <frames>]",
+ 0, 0, CIB_NETDEV, handle_mgmt_capture,
+ "Register for receiving certain mgmt frames, capture and print them.\n"
+ "Frames are selected by their type and pattern containing\n"
+ "the first several bytes of the frame that should match.\n\n"
+ "Example: iw dev wlan0 mgmt capture frame 40 00 frame 40 01:02 count 10\n");
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 1/3] dt-bindings: net: add mt76 wireless device binding
From: Christian Lamparter @ 2017-10-14 15:43 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Rob Herring, linux-wireless, kvalo, devicetree
In-Reply-To: <3828919b-d634-9f03-22ad-1515219c31d4@nbd.name>
On Saturday, October 14, 2017 9:20:46 AM CEST Felix Fietkau wrote:
> On 2017-10-13 21:07, Rob Herring wrote:
> > On Fri, Oct 06, 2017 at 01:02:47PM +0200, Felix Fietkau wrote:
> >> Add documentation describing how device tree can be used to configure
> >> wireless chips supported by the mt76 driver.
> >>
> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> >> ---
> >> .../bindings/net/wireless/mediatek,mt76.txt | 24 ++++++++++++++++++++++
> >> 1 file changed, 24 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >> new file mode 100644
> >> index 000000000000..19522ab97d62
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >> @@ -0,0 +1,24 @@
> >> +* MediaTek mt76xx devices
> >> +
> >> +This node provides properties for configuring the MediaTek mt76xx wireless
> >> +device. The node is expected to be specified as a child node of the PCI
> >> +controller to which the wireless chip is connected.
> >> +
> >> +Optional properties:
> >> +
> >> +- mac-address: See ethernet.txt in the parent directory
> >> +- local-mac-address: See ethernet.txt in the parent directory
> >> +- ieee80211-freq-limit: See ieee80211.txt
> >> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
> >
> > MTD is a Linuxism. And is an EEPROM the only supported device? I'd
> > suggest naming if after what the data contains.
> PCI cards with this kind of wireless chip usually come with some form of
> EEPROM or use the on-chip OTP ROM.
> This property is for the case where the chip is built into an embedded
> device and the data that would otherwise be on an EEPROM is stored on a
> MTD partition instead.
> The EEPROM data itself contains multiple things: calibration data,
> hardware capabilities, MAC address, etc.
> I couldn't think of a better name for it, do you have any suggestions?
This sort of reminds me of the failed ath9k nvmem patches:
https://patchwork.kernel.org/patch/9622127/
Which uses the nvmem system.
https://github.com/torvalds/linux/blob/master/Documentation/nvmem/nvmem.txt
Rob, would this be acceptable?
Regards,
Christian
^ permalink raw reply
* Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index
From: Dmitry Vyukov @ 2017-10-14 14:38 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Andrey Konovalov, Helmut Schaa, Kalle Valo, linux-wireless,
netdev, LKML, Kostya Serebryany, syzkaller
In-Reply-To: <20171012072529.GB2686@redhat.com>
On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Hi
>
> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>>
>> I'm not sure whether this is a bug in the driver, or just a way to
>> report misbehaving device. In the latter case this shouldn't be a
>> WARN() call, since WARN() means bug in the kernel.
>
> This is about wrong EEPROM, which reported 3 tx streams on
> non 3 antenna device. I think WARN() is justified and thanks
> to the call trace I was actually able to to understand what
> happened.
>
> In general I do not think WARN() only means a kernel bug, it
> can be F/W or H/W bug too.
Hi Stanislaw,
Printing messages is fine. Printing stacks is fine. Just please make
them distinguishable from kernel bugs and don't kill the whole
possibility of automated Linux kernel testing. That's an important
capability.
Thanks
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: icenowy @ 2017-10-14 12:00 UTC (permalink / raw)
To: Kalle Valo
Cc: devicetree, Arend van Spriel, netdev, linux-wireless,
linux-kernel, linux-sunxi, Rob Herring, Maxime Ripard,
Chen-Yu Tsai, linux-arm-kernel
In-Reply-To: <878tgq5beu.fsf@codeaurora.org>
在 2017-10-05 14:58，Kalle Valo 写道：
> Icenowy Zheng <icenowy@aosc.io> writes:
>
>> 于 2017年10月4日 GMT+08:00 下午6:11:45, Maxime Ripard
>> <maxime.ripard@free-electrons.com> 写到:
>>> On Wed, Oct 04, 2017 at 10:02:48AM +0000, Arend van Spriel wrote:
>>>> On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
>>>> >
>>>> >
>>>> > 于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kvalo@codeaurora.org>
>>> 写到:
>>>> > > Icenowy Zheng <icenowy@aosc.io> writes:
>>>> > >
>>>> > > > Allwinner XR819 is a SDIO Wi-Fi chip, which has the
>>> functionality to
>>>> > > use
>>>> > > > an out-of-band interrupt pin instead of SDIO in-band interrupt.
>>>> > > >
>>>> > > > Add the device tree binding of this chip, in order to make it
>>>> > > possible
>>>> > > > to add this interrupt pin to device trees.
>>>> > > >
>>>> > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> > > > Acked-by: Rob Herring <robh@kernel.org>
>>>> > > > ---
>>>> > > > Changes in v3:
>>>> > > > - Renames the node name.
>>>> > > > - Adds ACK from Rob.
>>>> > > > Changes in v2:
>>>> > > > - Removed status property in example.
>>>> > > > - Added required property reg.
>>>> > > >
>>>> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38
>>>> > > ++++++++++++++++++++++
>>>> > > > 1 file changed, 38 insertions(+)
>>>> > > > create mode 100644
>>>> > >
>>> Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>>>> > >
>>>> > > Like I asked already last time, AFAICS there is no upstream xr819
>>>> > > wireless driver in drivers/net/wireless directory. Do we still
>>> accept
>>>> > > bindings like this for out-of-tree drivers?
>>>> >
>>>> > See esp8089.
>>>> >
>>>> > There's also no in-tree driver for it.
>>>>
>>>> The question is whether we should. The above might be a precedent,
>>> but it
>>>> may not necessarily be the way to go. The commit message for esp8089
>>> seems
>>>> to hint that there is intent to have an in-tree driver:
>>>>
>>>> """
>>>> Note that at this point there only is an out of tree driver for
>>> this
>>>> hardware, there is no clear timeline / path for merging this.
>>> Still
>>>> I believe it would be good to specify the binding for this in
>>> tree
>>>> now, so that any future migration to an in tree driver will not
>>> cause
>>>> compatiblity issues.
>>>>
>>>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>>> """
>>>>
>>>> Regardless the bindings are in principle independent of the kernel
>>> and just
>>>> describing hardware. I think there have been discussions to move the
>>>> bindings to their own repository, but apparently it was decided
>>> otherwise.
>>>
>>> Yeah, I guess especially how it could be merged with the cw1200
>>> driver
>>> would be very relevant to that commit log.
>>
>> The cw1200 driver seems to still have some legacy platform
>> data. Maybe they should also be convert to DT.
>> (Or maybe compatible = "allwinner,xr819" is enough, as
>> xr819 is a specified variant of cw1200 family)
>
> Ah, so the upstream cw1200 driver supports xr819? Has anyone tested
> that? Or does cw1200 more changes than just adding the DT support?
The support of XR819 in CW1200 driver is far more difficult than I
imagined -- the codedrop used in the mainlined CW1200 driver seems to
be so old that it's before XR819 (which seems to be based on CW1160),
and there's a large number of problems to adapt it to a modern CW1200
variant.
P.S. could you apply this device tree binding patch now?
^ permalink raw reply
* Re: [EXTERNAL] wl1837: poor performance?
From: Russell King - ARM Linux @ 2017-10-14 11:29 UTC (permalink / raw)
To: Reizer, Eyal
Cc: linux-wireless@vger.kernel.org, Altshul, Maxim, Narang, Saurabh
In-Reply-To: <kxtrhma14knf9mq4u3dw8875.1507880614445@email.android.com>
On Fri, Oct 13, 2017 at 07:43:37AM +0000, Reizer, Eyal wrote:
> Sorry for top posting.
> Signal level on wlan0 seems low (-79 dbm) are you sure there are antennas
> connected?
Thanks for the reply.
In development environments, it's common to have the AP and station
nearby, which will give good signal. Out of the development
environment, the AP and station may be separated by several 10s of ft
and objects in the way. That's the case here, so about -80dBm is to
be expected.
As I mentioned, there's two stations each with different chipsets, both
with the same signal level being reported, both at a similar distance
from the AP, but one performs way better than the other. I've found
the reason for this (see below.)
I should also mention that this is installed remotely, and I'm debugging
it over the 'net, involving this very Wi-Fi connection.
The radio environment is not excessively populated - both systems are
within a tower with >2ft thick stone and lime mortar walls which radio
has difficulty penetrating, which is itself in a park with very few
other buildings around. I'm using the 2.4G channel 8, I've seen some
other APs on channel 1 when outside but almost never inside the tower.
nmcli (used to?) occasionally reports that the wl1837 can see another
AP ("CARWIFI") on channel 1, but that's rare - I suspect it requires
someone to park their car in direct line of literal sight through a
tower window from the machine. I suspect NM noticed that before I
configured the BSSID of the associated AP as I haven't recently
noticed NM reporting any other networks. Could also be that non-wifi
enabled cars are parked in those spaces!
> In addition what type of module is used here?
It's a WL1837 integrated onto SolidRun's iMX6 microsom. I'm not sure
what other information in terms of "module" you're asking for.
> Di you use the configure_device.sh scripts as documented in the
> "wlconf" manual?
No, because quite honestly the wilink tooling is something of a mess
in terms of trying to find the right tooling. This is what I ended
up doing:
1. cloning git://github.com/TI-OpenLink/18xx-ti-utils
2. taking the wl18xx driver default configuration (from debugfs).
3. taking the ti wilink driver conf.h files.
4. massaging the conf.h files into a form that wlconf can read
5. generating a new struct.bin
6. changing:
wl18xx.phy.number_of_assembled_ant2_4 = 0x01
wl18xx.phy.number_of_assembled_ant5 = 0x00
since this variant of the microsom I have only populates one antenna.
(The layout allows for the design to be extended to a second antenna.)
I've since found the _right_ repository for the tooling
(git://git.ti.com/wilink8-wlan/18xx-ti-utils.git), and compared the
resulting files, and confirmed that my new struct.bin is identical to
the one in the right repository.
There are some differences between the two files (- = mine,
+ = configure_device.sh generated):
-core.sg.params = 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x000000aa, 0x00000032, 0x00000000, 0x00000000, 0x00000000, 0x000000c8, 0x00000000, 0x00000000, 0x00000000, 0x00000001, 0x00000000, 0x0000003c, 0x00000000, 0x000004b0, 0x00000000, 0x00000001, 0x00000003, 0x00000006, 0x00000000, 0x00000000, 0x00000002, 0x00000000, 0x00000000, 0x00000003, 0x00000000, 0x00000002, 0x0000001e, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
+core.sg.params = 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x0000000f, 0x0000001b, 0x00000011, 0x000000aa, 0x00000032, 0x00000064, 0x00000320, 0x000000c8, 0x000000c8, 0x00000000, 0x00000000, 0x00000000, 0x00000001, 0x00000000, 0x0000003c, 0x00001388, 0x000004b0, 0x000003e8, 0x00000001, 0x00000003, 0x00000006, 0x0000000a, 0x0000000a, 0x00000002, 0x00000005, 0x0000001e, 0x00000003, 0x0000000a, 0x00000002, 0x00000000, 0x00000019, 0x00000019, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
-core.conn.dynamic_ps_timeout = 0x05dc
+core.conn.dynamic_ps_timeout = 0x0096
-core.sched_scan.num_short_intervals = 0x0e
+core.sched_scan.num_short_intervals = 0x0d
-core.fwlog.mem_blocks = 0x00
+core.fwlog.mem_blocks = 0x02
-wl18xx.ap_sleep.max_stations_thresh = 0x00
-wl18xx.ap_sleep.idle_conn_thresh = 0x00
+wl18xx.ap_sleep.max_stations_thresh = 0x04
+wl18xx.ap_sleep.idle_conn_thresh = 0x08
The core.sg.param differences in an easier to read format are:
mine configure_device.sh
[23] 0x00000000 => 0x0000000f WL18XX_CONF_SG_PARAM_23
[24] 0x00000000 => 0x0000001b WL18XX_CONF_SG_PARAM_24
[25] 0x00000000 => 0x00000011 WL18XX_CONF_SG_PARAM_25
[28] 0x00000000 => 0x00000064 WL18XX_CONF_SG_PARAM_28
[29] 0x00000000 => 0x00000320 WL18XX_CONF_SG_PARAM_29
[30] 0x00000000 => 0x000000c8 WL18XX_CONF_SG_PARAM_30
[38] 0x00000000 => 0x00001388 WL18XX_CONF_SG_PARAM_38
[40] 0x00000000 => 0x000003e8 WL18XX_CONF_SG_UNUSED
[44] 0x00000000 => 0x0000000a WL18XX_CONF_SG_PARAM_44
[45] 0x00000000 => 0x0000000a WL18XX_CONF_SG_PARAM_45
[47] 0x00000000 => 0x00000005 WL18XX_CONF_SG_GEMINI_PARAM_47
[48] 0x00000000 => 0x0000001e WL18XX_CONF_SG_STA_CONNECTION_PROTECTION_TIME
[50] 0x00000000 => 0x0000000a WL18XX_CONF_SG_PARAM_50
[52] 0x0000001e => 0x00000000 WL18XX_CONF_SG_AP_CONNECTION_PROTECTION_TIME
[53] 0x00000000 => 0x00000019 WL18XX_CONF_SG_PARAM_53
[54] 0x00000000 => 0x00000019 WL18XX_CONF_SG_PARAM_54
In any case, I eventually tracked down the reason for the 10ms pings - it
seems the iMX6 host SDHCI aggressively enters PM, with the autosuspend
delay is set to 50ms. Disabling runtime PM on the host results in ping
times around what I would expect - between 2 to 4ms.
> In addition, for the recovery. Are you using latest firmware (8.9.0.0.70)?
I'm using 8.9.0.0.75, which seems to be the latest as of 19th June,
which came from https://git.ti.com/wilink8-wlan/wl18xx_fw
The recovery doesn't seem to be a regular thing - I've only seen it
once so far, and it was non-fatal.
However, I have one lingering difference between the wl1837 and rtl8192eu
stations. If I set both up identically - with a BSS MAC address, thus
telling them that they should only associate with an AP with that MAC,
I find that rtl8192eu doesn't go off-channel to scan for APs, and has
pretty a stable ping RTT.
However, the wl1837 seems to end up with a ping RTT of about 110ms every
32s or so. I tried increasing "core.sched_scan.long_interval" in the
conf file to 40000, and this seemed to increase this to about once every
50s.
I've tried disabling the scheduled scan code in the wl18xx driver, but
that doesn't seem to have made a difference. I've also tried telling
wpa_supplicant not to scan (wpa_cli set pon) but that also doesn't seem
to make a difference. I don't think it's NetworkManager triggering the
scans, as both the wl1837 and rtl8192eu are setup identically, and
stracing NM only shows it polling for the signal level/bit rate etc -
and from what I read, configuring the connection with a BSSID stops
NM scanning for roaming.
It doesn't seem to be causing a problem, but it would be nice to get
rid of the additional latency if possible. Obviously, it does need
to scan initially, so NM/wpa_supplicant can associate with the AP.
With "core.sched_scan.long_interval" set back to 30000, and the
scheduled scan code in the wl18xx driver disabled, I'm seeing:
64 bytes from 192.168.250.1: icmp_seq=25 ttl=64 time=2.68 ms
64 bytes from 192.168.250.1: icmp_seq=26 ttl=64 time=114 ms
64 bytes from 192.168.250.1: icmp_seq=27 ttl=64 time=3.58 ms
...
64 bytes from 192.168.250.1: icmp_seq=65 ttl=64 time=2.58 ms
64 bytes from 192.168.250.1: icmp_seq=66 ttl=64 time=107 ms
64 bytes from 192.168.250.1: icmp_seq=67 ttl=64 time=2.71 ms
...
64 bytes from 192.168.250.1: icmp_seq=105 ttl=64 time=3.04 ms
64 bytes from 192.168.250.1: icmp_seq=106 ttl=64 time=110 ms
64 bytes from 192.168.250.1: icmp_seq=107 ttl=64 time=3.42 ms
...
64 bytes from 192.168.250.1: icmp_seq=145 ttl=64 time=3.18 ms
64 bytes from 192.168.250.1: icmp_seq=146 ttl=64 time=109 ms
64 bytes from 192.168.250.1: icmp_seq=147 ttl=64 time=3.27 ms
Any ideas?
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] ath9k: debug: Remove redundant check
From: Christos Gkekas @ 2017-10-14 9:46 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
Cc: Christos Gkekas
Variable val is unsigned, so checking whether it is less than zero is
redundant.
Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
---
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 01fa301..4f5f141 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1167,7 +1167,7 @@ static ssize_t write_file_tpc(struct file *file, const char __user *user_buf,
if (kstrtoul(buf, 0, &val))
return -EINVAL;
- if (val < 0 || val > 1)
+ if (val > 1)
return -EINVAL;
tpc_enabled = !!val;
--
2.7.4
^ permalink raw reply related
* [PATCH] ath10k: spectral: Remove redundant check
From: Christos Gkekas @ 2017-10-14 9:41 UTC (permalink / raw)
To: Kalle Valo, ath10k, linux-wireless, netdev, linux-kernel; +Cc: Christos Gkekas
Variable val is unsigned, so checking whether it is less than zero is
redundant.
Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
---
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/spectral.c b/drivers/net/wireless/ath/ath10k/spectral.c
index dd9cc09..2048b1e 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -406,7 +406,7 @@ static ssize_t write_file_spectral_count(struct file *file,
if (kstrtoul(buf, 0, &val))
return -EINVAL;
- if (val < 0 || val > 255)
+ if (val > 255)
return -EINVAL;
mutex_lock(&ar->conf_mutex);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ath9k: debug: Simplify error checking
From: Christos Gkekas @ 2017-10-14 8:16 UTC (permalink / raw)
To: Kalle Valo; +Cc: QCA ath9k Development, linux-wireless, netdev, linux-kernel
In-Reply-To: <87infjw6us.fsf@purkki.adurom.net>
On 13/10/17 15:49:15 +0300, Kalle Valo wrote:
> Christos Gkekas <chris.gekas@gmail.com> writes:
>
> > Variable val is unsigned so checking whether it is less than zero is
> > redundant.
> >
> > Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
> > ---
> > drivers/net/wireless/ath/ath9k/debug.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
> > index 01fa301..3b93c23 100644
> > --- a/drivers/net/wireless/ath/ath9k/debug.c
> > +++ b/drivers/net/wireless/ath/ath9k/debug.c
> > @@ -1164,10 +1164,7 @@ static ssize_t write_file_tpc(struct file *file, const char __user *user_buf,
> > return -EFAULT;
> >
> > buf[len] = '\0';
> > - if (kstrtoul(buf, 0, &val))
> > - return -EINVAL;
> > -
> > - if (val < 0 || val > 1)
> > + if (kstrtoul(buf, 0, &val) || val > 1)
> > return -EINVAL;
>
> Same as with the ath10k patch, please keep the two if statements
> separate.
>
> --
> Kalle Valo
Thanks, will submit an new, updated patch.
Christos Gkekas
^ permalink raw reply
* Re: [PATCH] ath10k: spectral: Simplify error checking
From: Christos Gkekas @ 2017-10-14 8:12 UTC (permalink / raw)
To: Kalle Valo
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <87fuannse6.fsf@kamboji.qca.qualcomm.com>
On 13/10/17 12:28:50 +0000, Kalle Valo wrote:
> Christos Gkekas <chris.gekas@gmail.com> writes:
>
> > Variable val is unsigned so checking whether it is less than zero is
> > redundant.
> >
> > Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
> > ---
> > drivers/net/wireless/ath/ath10k/spectral.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/spectral.c b/drivers/net/wireless/ath/ath10k/spectral.c
> > index dd9cc09..1867937 100644
> > --- a/drivers/net/wireless/ath/ath10k/spectral.c
> > +++ b/drivers/net/wireless/ath/ath10k/spectral.c
> > @@ -403,10 +403,7 @@ static ssize_t write_file_spectral_count(struct file *file,
> > return -EFAULT;
> >
> > buf[len] = '\0';
> > - if (kstrtoul(buf, 0, &val))
> > - return -EINVAL;
> > -
> > - if (val < 0 || val > 255)
> > + if (kstrtoul(buf, 0, &val) || val > 255)
> > return -EINVAL;
>
> Removing the check for negative is correct but I don't think you are
> simplifying anything, on the contrary it's harder to read. Please keep
> the two if statements separate.
>
> --
> Kalle Valo
You are right, will make the change and send a new patch.
Thanks for your time.
Christos Gkekas
^ permalink raw reply
* Re: [PATCH v6 1/3] dt-bindings: net: add mt76 wireless device binding
From: Felix Fietkau @ 2017-10-14 7:20 UTC (permalink / raw)
To: Rob Herring; +Cc: linux-wireless, kvalo, devicetree
In-Reply-To: <20171013190749.lzzw4zjzt7fkp3hs@rob-hp-laptop>
On 2017-10-13 21:07, Rob Herring wrote:
> On Fri, Oct 06, 2017 at 01:02:47PM +0200, Felix Fietkau wrote:
>> Add documentation describing how device tree can be used to configure
>> wireless chips supported by the mt76 driver.
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> ---
>> .../bindings/net/wireless/mediatek,mt76.txt | 24 ++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> new file mode 100644
>> index 000000000000..19522ab97d62
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> @@ -0,0 +1,24 @@
>> +* MediaTek mt76xx devices
>> +
>> +This node provides properties for configuring the MediaTek mt76xx wireless
>> +device. The node is expected to be specified as a child node of the PCI
>> +controller to which the wireless chip is connected.
>> +
>> +Optional properties:
>> +
>> +- mac-address: See ethernet.txt in the parent directory
>> +- local-mac-address: See ethernet.txt in the parent directory
>> +- ieee80211-freq-limit: See ieee80211.txt
>> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
>
> MTD is a Linuxism. And is an EEPROM the only supported device? I'd
> suggest naming if after what the data contains.
PCI cards with this kind of wireless chip usually come with some form of
EEPROM or use the on-chip OTP ROM.
This property is for the case where the chip is built into an embedded
device and the data that would otherwise be on an EEPROM is stored on a
MTD partition instead.
The EEPROM data itself contains multiple things: calibration data,
hardware capabilities, MAC address, etc.
I couldn't think of a better name for it, do you have any suggestions?
- Felix
^ permalink raw reply
* Re: [PATCH v2] ath10k: Retry pci probe on failure.
From: Adrian Chadd @ 2017-10-13 20:55 UTC (permalink / raw)
To: Ben Greear
Cc: Kalle Valo, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <59E124EB.6090602@candelatech.com>
[snip]
* WMI setup stuff fails locally because of memory fragmentation when
you reload the driver. Heh. Sigh.
* I also see the PCI wakeup failures, so I'm going to go poke that
soon and see what I find.
-adrian
^ permalink raw reply
* Re: [PATCH v2] ath10k: Retry pci probe on failure.
From: Ben Greear @ 2017-10-13 20:41 UTC (permalink / raw)
To: Adrian Chadd, Kalle Valo
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAJ-Vmon0SszxH22Zb+O5RVQSommFFuc5XmG+at9=xbGagOb7PQ@mail.gmail.com>
On 10/13/2017 08:50 AM, Adrian Chadd wrote:
> On 13 October 2017 at 05:41, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> This works around a problem we see when sometimes the wifi NIC does
>>> not respond the first time. This seems to happen especially often on
>>> some of the 9984 NICs in mid-range platforms.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> [...]
>>
>>> -static int ath10k_pci_probe(struct pci_dev *pdev,
>>> - const struct pci_device_id *pci_dev)
>>> +static int __ath10k_pci_probe(struct pci_dev *pdev,
>>> + const struct pci_device_id *pci_dev)
>>> {
>>> int ret = 0;
>>> struct ath10k *ar;
>>> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>>> return ret;
>>> }
>>>
>>> +static int ath10k_pci_probe(struct pci_dev *pdev,
>>> + const struct pci_device_id *pci_dev)
>>> +{
>>> + int cnt = 0;
>>> + int rv;
>>> + do {
>>> + rv = __ath10k_pci_probe(pdev, pci_dev);
>>> + if (rv == 0)
>>> + return rv;
>>> + pr_err("ath10k: failed to probe PCI : %d, retry-count: %d\n", rv, cnt);
>>> + mdelay(10); /* let the ath10k firmware gerbil take a small break */
>>> + } while (cnt++ < 10);
>>> + return rv;
>>> +}
>>
>> This is a sledgehammer approach and it causes reload for all error
>> cases, like when hardware is broken or memory allocation is failing.
>>
>> When the problem happens does it always fail at the the same place? Is
>> it hw reset or something else? It's better to retry the invidiual action
>> than to do this hack. Or is it just some more delay needed somewhere?
>
> I am seeing WMI timeouts during initial firmware load and wait on
> QCA9984 + BCM7444S SoC.
> My guess is the WMI wakeup time is not "right" enough and needs to be
> extended a little bit.
>
> But then, I have played a lot of whackamole with WMI timeouts during
> my loooong porting effort..
The failure I saw was a failure to wake pci, and from comments, it seems that
the current wait is longer than what should be required, and it warns on slow
wakes, and I never saw that warning. So I assume that waiting longer would not help.
I saw it fail twice in a row to wake pci and then succeed on the third try, for instance,
when testing my patch.
As for a big hammer, I guess we could check for certain return codes if you think
that is better than just retrying all failures?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v6 1/3] dt-bindings: net: add mt76 wireless device binding
From: Rob Herring @ 2017-10-13 19:07 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo, devicetree
In-Reply-To: <20171006110249.31013-2-nbd@nbd.name>
On Fri, Oct 06, 2017 at 01:02:47PM +0200, Felix Fietkau wrote:
> Add documentation describing how device tree can be used to configure
> wireless chips supported by the mt76 driver.
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> .../bindings/net/wireless/mediatek,mt76.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> new file mode 100644
> index 000000000000..19522ab97d62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -0,0 +1,24 @@
> +* MediaTek mt76xx devices
> +
> +This node provides properties for configuring the MediaTek mt76xx wireless
> +device. The node is expected to be specified as a child node of the PCI
> +controller to which the wireless chip is connected.
> +
> +Optional properties:
> +
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +- ieee80211-freq-limit: See ieee80211.txt
> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
MTD is a Linuxism. And is an EEPROM the only supported device? I'd
suggest naming if after what the data contains.
> +
> +&pcie {
> + status = "okay";
Don't show status in examples.
> +
> + pcie0 {
> + wifi@0,0 {
You need a compatible here too.
> + reg = <0x0000 0 0 0 0>;
> + ieee80211-freq-limit = <5000000 6000000>;
> + mediatek,mtd-eeprom = <&factory 0x8000>;
> + };
> + };
> +};
> --
> 2.14.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* pull-request: mac80211-next 2017-10-13
From: Johannes Berg @ 2017-10-13 15:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Sorry for the quick succession - there were a few issues with
the last pull request that only got noticed now, so I'm fixing
those here.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 90a53e4432b12288316efaa5f308adafb8d304b0:
cfg80211: implement regdb signature checking (2017-10-11 14:24:24 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2017-10-13
for you to fetch changes up to b1b1ae2c1c150f8db5d3523c74e81eaf8cae5cbb:
mac80211: don't track HT capability changes (2017-10-13 14:29:02 +0200)
----------------------------------------------------------------
Three fixes for the recently added new code:
* make "make -s" silent for the certs file (Arnd)
* fix missing CONFIG_ in extra certs symbol (Arnd)
* use crypto_aead_authsize() to use the proper API
and two other changes:
* remove a set-but-unused variable
* don't track HT *capability* changes, capabilities
are supposed to be constant (HT operation changes)
----------------------------------------------------------------
Arnd Bergmann (2):
cfg80211: don't print log output for building shipped-certs
cfg80211: fix CFG80211_EXTRA_REGDB_KEYDIR typo
Johannes Berg (3):
mac80211: use crypto_aead_authsize()
cfg80211: remove set but never used variable cf_offset
mac80211: don't track HT capability changes
net/mac80211/aead_api.c | 4 ++--
net/mac80211/mlme.c | 14 +++-----------
net/wireless/Makefile | 4 ++--
net/wireless/chan.c | 4 +---
net/wireless/reg.c | 2 +-
5 files changed, 9 insertions(+), 19 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] ath10k: Retry pci probe on failure.
From: Adrian Chadd @ 2017-10-13 15:50 UTC (permalink / raw)
To: Kalle Valo
Cc: greearb@candelatech.com, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <87a80vnrsb.fsf@kamboji.qca.qualcomm.com>
On 13 October 2017 at 05:41, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This works around a problem we see when sometimes the wifi NIC does
>> not respond the first time. This seems to happen especially often on
>> some of the 9984 NICs in mid-range platforms.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> [...]
>
>> -static int ath10k_pci_probe(struct pci_dev *pdev,
>> - const struct pci_device_id *pci_dev)
>> +static int __ath10k_pci_probe(struct pci_dev *pdev,
>> + const struct pci_device_id *pci_dev)
>> {
>> int ret = 0;
>> struct ath10k *ar;
>> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>> return ret;
>> }
>>
>> +static int ath10k_pci_probe(struct pci_dev *pdev,
>> + const struct pci_device_id *pci_dev)
>> +{
>> + int cnt = 0;
>> + int rv;
>> + do {
>> + rv = __ath10k_pci_probe(pdev, pci_dev);
>> + if (rv == 0)
>> + return rv;
>> + pr_err("ath10k: failed to probe PCI : %d, retry-count: %d\n", rv, cnt);
>> + mdelay(10); /* let the ath10k firmware gerbil take a small break */
>> + } while (cnt++ < 10);
>> + return rv;
>> +}
>
> This is a sledgehammer approach and it causes reload for all error
> cases, like when hardware is broken or memory allocation is failing.
>
> When the problem happens does it always fail at the the same place? Is
> it hw reset or something else? It's better to retry the invidiual action
> than to do this hack. Or is it just some more delay needed somewhere?
I am seeing WMI timeouts during initial firmware load and wait on
QCA9984 + BCM7444S SoC.
My guess is the WMI wakeup time is not "right" enough and needs to be
extended a little bit.
But then, I have played a lot of whackamole with WMI timeouts during
my loooong porting effort..
-adrian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox