* Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs
From: Johannes Berg @ 2017-09-04 9:33 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, linux-wireless; +Cc: nbd
In-Reply-To: <87378lvyfz.fsf@toke.dk>
On Mon, 2017-08-21 at 15:32 +0200, Toke Høiland-Jørgensen wrote:
>
> > + struct ieee80211_vif *vif;
> > struct ieee80211_key_conf *hw_key;
> > u32 flags;
> > - /* 4 bytes free */
> > + codel_time_t enqueue_time;
>
> A side effect of this is that enqueue_time will be valid in the
> driver; which is good as far as I'm concerned (I've been thinking
> about using it to make decisions about when to stop retrying a
> frame).
Well, I think we need to do a lot more to allow that, but I guess
ultimately it would be possible - though we have this as codel_time_t
so the driver doesn't really know the reference etc. immediately.
> If we want to save the four bytes, is there any reason we can't just
> change the codel code to use skb->tstamp instead?
I didn't really want to go into that.
Any comments on the patch itself? I don't think I even merged this yet.
johannes
^ permalink raw reply
* Re: Bug Report for iwlwifi kernel module
From: Luca Coelho @ 2017-09-04 7:34 UTC (permalink / raw)
To: Carl Myers, linux-wireless; +Cc: linuxwifi
In-Reply-To: <20170903191552.GE7829@cmyers.org>
Hi Carl,
On Sun, 2017-09-03 at 12:15 -0700, Carl Myers wrote:
> Greetings all,
>
> Apologies if any of this is wrong, this is my first attempt to report a bug in
> the linux kernel =)
>
> I got here by running the get_maintainer script on the iwlwifi directory of a
> linux kernel checkout.
>
> I am running debian stock kernel 4.8.15, and using the built in iwlwifi
> driver
>
> $⮀ uname -a
> Linux powerhouse 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux
> $⮀ dpkg -l | grep iwlwifi
> ii firmware-iwlwifi 20160110-1~bpo8+1 all Binary firmware for Intel Wireless cards
>
> I am on a slightly older firmware and kernel due to the currently-outstanding bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849330
>
> This is the newest combination of kernel/firmware I've been able to make work.
>
> Here is the lspci -v output for my wifi:
> 03:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
> Subsystem: Intel Corporation Wireless 8260
> Flags: bus master, fast devsel, latency 0, IRQ 136
> Memory at df200000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: <access denied>
> Kernel driver in use: iwlwifi
> Kernel modules: iwlwifi
First of all, what makes you think this is a bug in the iwlwifi driver
module?
> Recently, while testing a 2nd panda wifi card (trying to make a hotspot and use
> the iwl card as a gateway device), I got a kernel panic. Here is the relevant
> excerpt from kern.log:
>
> Sep 3 11:37:49 powerhouse kernel: [21394.510512] ------------[ cut here ]------------
> Sep 3 11:37:49 powerhouse kernel: [21394.510514] kernel BUG at /build/linux-zDY19G/linux-4.8.15/kernel/module.c:890!
> Sep 3 11:37:49 powerhouse kernel: [21394.510515] invalid opcode: 0000 [#1] SMP
> Sep 3 11:37:49 powerhouse kernel: [21394.510516] Modules linked in: iwlmvm iwlwifi ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp hid_generic rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp overlay iptable_filter appletalk ax25 ipx p8023 p8022 psnap llc bnep snd_hda_codec_hdmi arc4 binfmt_misc nls_ascii nls_cp437 vfat fat mac80211 snd_hda_codec_realtek intel_rapl x86_pkg_temp_thermal mxm_wmi intel_powerclamp coretemp snd_hda_codec_generic kvm_intel kvm efi_pstore irqbypass snd_hda_intel intel_cstate snd_hda_codec uvcvideo videobuf2_vmalloc rtsx_pci_ms videobuf2_memops snd_hda_core videobuf2_v4l2 iTCO_wdt videobuf2_core snd_hwdep intel_uncore videodev joydev btusb intel_rapl_perf evdev media btrtl cfg80211 serio_raw pcspkr efivars memstick iTCO_vendor_support snd_pcm snd_timer mei_me hci_uart snd mei soundcore btbcm btqca btintel bluetooth rfkill wmi video intel_lpss_acpi intel_lpss shpchp battery acpi_pad ac tpm_tis button tpm_tis_core tpm nvidia_drm(POE) drm_kms_helper drm nvidia_modeset(POE) nvidia(POE) parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache algif_skcipher af_alg dm_crypt dm_mod hid_logitech_hidpp hid_logitech_dj usbhid rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ahci libahci aes_x86_64 lrw gf128mul glue_helper xhci_pci ablk_helper cryptd libata xhci_hcd psmouse usbcore nvme scsi_mod i2c_i801 nvme_core i2c_smbus rtsx_pci r8169 mii mfd_core usb_common thermal i2c_hid hid fjes [last unloaded: iwlwifi]
> Sep 3 11:37:49 powerhouse kernel: [21394.510561] CPU: 4 PID: 8122 Comm: rmmod Tainted: P R OE 4.8.0-2-amd64 #1 Debian 4.8.15-2
> Sep 3 11:37:49 powerhouse kernel: [21394.510562] Hardware name: System76, Inc. Oryx Pro/Oryx Pro, BIOS 1.05.09RSA1 11/16/2015
> Sep 3 11:37:49 powerhouse kernel: [21394.510563] task: ffff8dec4a3e0000 task.stack: ffff8decf4cd4000
> Sep 3 11:37:49 powerhouse kernel: [21394.510564] RIP: 0010:[<ffffffffbccf98b9>] [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
> Sep 3 11:37:49 powerhouse kernel: [21394.510568] RSP: 0018:ffff8decf4cd7ef0 EFLAGS: 00010297
> Sep 3 11:37:49 powerhouse kernel: [21394.510569] RAX: 00000000ffffffff RBX: ffffffffc1aa71c0 RCX: 0000000000000005
> Sep 3 11:37:49 powerhouse kernel: [21394.510570] RDX: ffffffffc1aa74a0 RSI: ffffffffc1aa74c8 RDI: ffffffffc1aa71d8
> Sep 3 11:37:49 powerhouse kernel: [21394.510571] RBP: 000055fb472021f0 R08: 0000000000000000 R09: 000000000000006d
> Sep 3 11:37:49 powerhouse kernel: [21394.510572] R10: 000055fb472011c0 R11: 8080808080808080 R12: 0000000000000a00
> Sep 3 11:37:49 powerhouse kernel: [21394.510572] R13: 0000000000000a00 R14: 00007fff6cd8d4f8 R15: 0000000000000000
> Sep 3 11:37:49 powerhouse kernel: [21394.510573] FS: 00007f498ef22700(0000) GS:ffff8ded76500000(0000) knlGS:0000000000000000
> Sep 3 11:37:49 powerhouse kernel: [21394.510574] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Sep 3 11:37:49 powerhouse kernel: [21394.510575] CR2: 00007f498eacf801 CR3: 0000000fa99d0000 CR4: 00000000003406e0
> Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Sep 3 11:37:49 powerhouse kernel: [21394.510577] Stack:
> Sep 3 11:37:49 powerhouse kernel: [21394.510578] 00006d766d6c7769 0000000000000002 ffff8decf4cd4000 ffffffffbcc03290
> Sep 3 11:37:49 powerhouse kernel: [21394.510579] ffff8decf4cd7f58 ffff8decf4cd4000 0000000000000050 00000000520cd409
> Sep 3 11:37:49 powerhouse kernel: [21394.510581] 00007fff6cd8d338 000055fb472021f0 00007fff6cd8d508 00007fff6cd8ebbb
> Sep 3 11:37:49 powerhouse kernel: [21394.510582] Call Trace:
> Sep 3 11:37:49 powerhouse kernel: [21394.510586] [<ffffffffbcc03290>] ? exit_to_usermode_loop+0xa0/0xc0
> Sep 3 11:37:49 powerhouse kernel: [21394.510588] [<ffffffffbd1e8cb6>] ? system_call_fast_compare_end+0xc/0x96
> Sep 3 11:37:49 powerhouse kernel: [21394.510588] Code: fe ff ff 41 f7 c4 00 02 00 00 48 c7 c5 f0 ff ff ff 0f 84 5c fe ff ff be 01 00 00 00 bf 03 00 00 00 e8 0c b3 f7 ff e9 b7 fe ff ff <0f> 0b e8 90 b4 f7 ff 0f 1f 44 00 00 31 c0 c3 0f 1f 84 00 00 00
> Sep 3 11:37:49 powerhouse kernel: [21394.510605] RIP [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
> Sep 3 11:37:49 powerhouse kernel: [21394.510607] RSP <ffff8decf4cd7ef0>
> Sep 3 11:37:49 powerhouse kernel: [21394.510608] ---[ end trace 5b24b93b49e857eb ]---
> Sep 3 11:37:49 powerhouse kernel: [21409.372738] ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -110
> Sep 3 11:38:05 powerhouse kernel: [21425.406196] INFO: rcu_sched detected stalls on CPUs/tasks:
> Sep 3 11:38:20 powerhouse kernel: [21425.406201] 4-...: (0 ticks this GP) idle=02d/140000000000000/0 softirq=277173/277173 fqs=8
> Sep 3 11:38:20 powerhouse kernel: [21425.406202] (detected by 7, t=7721 jiffies, g=246559, c=246558, q=936)
> Sep 3 11:38:20 powerhouse kernel: [21425.406204] Task dump for CPU 4:
> Sep 3 11:38:20 powerhouse kernel: [21425.406206] rmmod R running task 0 8122 8121 0x00000008
> Sep 3 11:38:20 powerhouse kernel: [21425.406209] 0000000000000002 ffff8decf4cd7e48 ffffffffbd3df853 0000000000000000
> Sep 3 11:38:20 powerhouse kernel: [21425.406211] 0000000000000000 ffffffffbcccc3d3 0000000000000246 000000000000000b
> Sep 3 11:38:20 powerhouse kernel: [21425.406214] ffffffffbcc289f8 0000000000000006 ffff8decf4cd7e48 0000000000000004
> Sep 3 11:38:20 powerhouse kernel: [21425.406216] Call Trace:
> Sep 3 11:38:20 powerhouse kernel: [21425.406222] [<ffffffffbcccc3d3>] ? kmsg_dump+0x93/0xb0
> Sep 3 11:38:20 powerhouse kernel: [21425.406225] [<ffffffffbcc289f8>] ? oops_end+0x78/0xd0
> Sep 3 11:38:20 powerhouse kernel: [21425.406228] [<ffffffffbcc26446>] ? do_error_trap+0x86/0x100
> Sep 3 11:38:20 powerhouse kernel: [21425.406976] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
> Sep 3 11:38:20 powerhouse kernel: [21425.406979] [<ffffffffbcdda242>] ? kmem_cache_alloc+0x122/0x530
> Sep 3 11:38:20 powerhouse kernel: [21425.406982] [<ffffffffbd1e9a2e>] ? invalid_op+0x1e/0x30
> Sep 3 11:38:20 powerhouse kernel: [21425.407276] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
> Sep 3 11:38:20 powerhouse kernel: [21425.407277] perf: interrupt took too long (8612 > 2500), lowering kernel.perf_event_max_sample_rate to 23000
> Sep 3 11:3Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Linux version 4.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)
> Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 root=/dev/mapper/powerhouse--vg-root ro quiet
>
> Obviously, I'm not certain the bug is in this kernel module or even has
> anything to do with it, but I thought this was a good place to start. Advice
> welcome, happy to help however I can, I am a software engineer but not very
> experienced at kernel hacking.
The bug you're seeing is happening in the module removal code[1].
Apparently the system is getting a bad value in refcnt and it's becoming
negative, which should never happen. Have you been trying to force-
remove modules or something like that?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/module.c?h=linux-4.8.y#n890
In any case, this doesn't seem like a iwlwifi bug at all.
HTH.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] brcmfmac: return -EPERM when getting error in vendor command handler
From: Wright Feng @ 2017-09-04 7:34 UTC (permalink / raw)
To: arend.vanspriel, franky.lin, hante.meuleman, kvalo, chi-hsien.lin
Cc: wright.feng, linux-wireless, brcm80211-dev-list.pdl
Firmware returns proprietary error code when getting error in
fil_cmd_data_set or fil_cmd_data_get. The vendor tools or
utilities which uses libnl may stuck in some commands when wl is down.
For example, issue "scan" command after issuing "down" command, the
"scan" command will be the blocking call and stuck as no response from
libnl. It is caused by that firmware returns BCME_NOTUP(-4) when wl
is down, but the -4 is -EINTR in Linux kernel, so libnl catches the error
and not passes to upper layer.
Because of that, the driver should return Linux error code instead of the
proprietary error code, and the tools or utilities need to get the real
firmware error code by command "bcmerror" or "bcmerrorstr" after receiving
the error.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index 8eff275..2b88ba1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -80,8 +80,12 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
else
ret = brcmf_fil_cmd_data_get(ifp, cmdhdr->cmd, dcmd_buf,
ret_len);
- if (ret != 0)
+
+ if (ret != 0) {
+ brcmf_dbg(INFO, "error(%d), return -EPERM\n", ret);
+ ret = -EPERM;
goto exit;
+ }
wr_pointer = dcmd_buf;
while (ret_len > 0) {
--
1.9.1
^ permalink raw reply related
* status of rtl8188eu driver
From: bruce m beach @ 2017-09-03 22:59 UTC (permalink / raw)
To: linux-wireless
Hello
Is the driver rtl8188eu supposed to be working at this point?
I downloaded the driver, compiled it and started
up the stick all without problems but when I started playing around
with it I found things like 'iw' wouldn't recognize it, iwconfig and
family did, it showed up in '/proc/net/wireless', would not respond to
'iwconfig wlan0 essid "bismuth"' and so on.
Bruce
^ permalink raw reply
* Bug Report for iwlwifi kernel module
From: Carl Myers @ 2017-09-03 19:15 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 9358 bytes --]
Greetings all,
Apologies if any of this is wrong, this is my first attempt to report a bug in
the linux kernel =)
I got here by running the get_maintainer script on the iwlwifi directory of a
linux kernel checkout.
I am running debian stock kernel 4.8.15, and using the built in iwlwifi
driver
$⮀ uname -a
Linux powerhouse 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux
$⮀ dpkg -l | grep iwlwifi
ii firmware-iwlwifi 20160110-1~bpo8+1 all Binary firmware for Intel Wireless cards
I am on a slightly older firmware and kernel due to the currently-outstanding bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849330
This is the newest combination of kernel/firmware I've been able to make work.
Here is the lspci -v output for my wifi:
03:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
Subsystem: Intel Corporation Wireless 8260
Flags: bus master, fast devsel, latency 0, IRQ 136
Memory at df200000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
Recently, while testing a 2nd panda wifi card (trying to make a hotspot and use
the iwl card as a gateway device), I got a kernel panic. Here is the relevant
excerpt from kern.log:
Sep 3 11:37:49 powerhouse kernel: [21394.510512] ------------[ cut here ]------------
Sep 3 11:37:49 powerhouse kernel: [21394.510514] kernel BUG at /build/linux-zDY19G/linux-4.8.15/kernel/module.c:890!
Sep 3 11:37:49 powerhouse kernel: [21394.510515] invalid opcode: 0000 [#1] SMP
Sep 3 11:37:49 powerhouse kernel: [21394.510516] Modules linked in: iwlmvm iwlwifi ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp hid_generic rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp overlay iptable_filter appletalk ax25 ipx p8023 p8022 psnap llc bnep snd_hda_codec_hdmi arc4 binfmt_misc nls_ascii nls_cp437 vfat fat mac80211 snd_hda_codec_realtek intel_rapl x86_pkg_temp_thermal mxm_wmi intel_powerclamp coretemp snd_hda_codec_generic kvm_intel kvm efi_pstore irqbypass snd_hda_intel intel_cstate snd_hda_codec uvcvideo videobuf2_vmalloc rtsx_pci_ms videobuf2_memops snd_hda_core videobuf2_v4l2 iTCO_wdt videobuf2_core snd_hwdep intel_uncore videodev joydev btusb intel_rapl_perf evdev media btrtl cfg80211 serio_raw pcspkr efivars memstick iTCO_vendor_support snd_pcm snd_timer mei_me hci_uart snd mei soundcore btbcm btqca btintel bluetooth rfkill wmi video intel_lpss_acpi intel_lpss shpchp battery acpi_pad ac tpm_tis button tpm_tis_core tpm nvidia_drm(POE) drm_kms_helper drm nvidia_modeset(POE) nvidia(POE) parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache algif_skcipher af_alg dm_crypt dm_mod hid_logitech_hidpp hid_logitech_dj usbhid rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ahci libahci aes_x86_64 lrw gf128mul glue_helper xhci_pci ablk_helper cryptd libata xhci_hcd psmouse usbcore nvme scsi_mod i2c_i801 nvme_core i2c_smbus rtsx_pci r8169 mii mfd_core usb_common thermal i2c_hid hid fjes [last unloaded: iwlwifi]
Sep 3 11:37:49 powerhouse kernel: [21394.510561] CPU: 4 PID: 8122 Comm: rmmod Tainted: P R OE 4.8.0-2-amd64 #1 Debian 4.8.15-2
Sep 3 11:37:49 powerhouse kernel: [21394.510562] Hardware name: System76, Inc. Oryx Pro/Oryx Pro, BIOS 1.05.09RSA1 11/16/2015
Sep 3 11:37:49 powerhouse kernel: [21394.510563] task: ffff8dec4a3e0000 task.stack: ffff8decf4cd4000
Sep 3 11:37:49 powerhouse kernel: [21394.510564] RIP: 0010:[<ffffffffbccf98b9>] [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
Sep 3 11:37:49 powerhouse kernel: [21394.510568] RSP: 0018:ffff8decf4cd7ef0 EFLAGS: 00010297
Sep 3 11:37:49 powerhouse kernel: [21394.510569] RAX: 00000000ffffffff RBX: ffffffffc1aa71c0 RCX: 0000000000000005
Sep 3 11:37:49 powerhouse kernel: [21394.510570] RDX: ffffffffc1aa74a0 RSI: ffffffffc1aa74c8 RDI: ffffffffc1aa71d8
Sep 3 11:37:49 powerhouse kernel: [21394.510571] RBP: 000055fb472021f0 R08: 0000000000000000 R09: 000000000000006d
Sep 3 11:37:49 powerhouse kernel: [21394.510572] R10: 000055fb472011c0 R11: 8080808080808080 R12: 0000000000000a00
Sep 3 11:37:49 powerhouse kernel: [21394.510572] R13: 0000000000000a00 R14: 00007fff6cd8d4f8 R15: 0000000000000000
Sep 3 11:37:49 powerhouse kernel: [21394.510573] FS: 00007f498ef22700(0000) GS:ffff8ded76500000(0000) knlGS:0000000000000000
Sep 3 11:37:49 powerhouse kernel: [21394.510574] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 3 11:37:49 powerhouse kernel: [21394.510575] CR2: 00007f498eacf801 CR3: 0000000fa99d0000 CR4: 00000000003406e0
Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Sep 3 11:37:49 powerhouse kernel: [21394.510577] Stack:
Sep 3 11:37:49 powerhouse kernel: [21394.510578] 00006d766d6c7769 0000000000000002 ffff8decf4cd4000 ffffffffbcc03290
Sep 3 11:37:49 powerhouse kernel: [21394.510579] ffff8decf4cd7f58 ffff8decf4cd4000 0000000000000050 00000000520cd409
Sep 3 11:37:49 powerhouse kernel: [21394.510581] 00007fff6cd8d338 000055fb472021f0 00007fff6cd8d508 00007fff6cd8ebbb
Sep 3 11:37:49 powerhouse kernel: [21394.510582] Call Trace:
Sep 3 11:37:49 powerhouse kernel: [21394.510586] [<ffffffffbcc03290>] ? exit_to_usermode_loop+0xa0/0xc0
Sep 3 11:37:49 powerhouse kernel: [21394.510588] [<ffffffffbd1e8cb6>] ? system_call_fast_compare_end+0xc/0x96
Sep 3 11:37:49 powerhouse kernel: [21394.510588] Code: fe ff ff 41 f7 c4 00 02 00 00 48 c7 c5 f0 ff ff ff 0f 84 5c fe ff ff be 01 00 00 00 bf 03 00 00 00 e8 0c b3 f7 ff e9 b7 fe ff ff <0f> 0b e8 90 b4 f7 ff 0f 1f 44 00 00 31 c0 c3 0f 1f 84 00 00 00
Sep 3 11:37:49 powerhouse kernel: [21394.510605] RIP [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
Sep 3 11:37:49 powerhouse kernel: [21394.510607] RSP <ffff8decf4cd7ef0>
Sep 3 11:37:49 powerhouse kernel: [21394.510608] ---[ end trace 5b24b93b49e857eb ]---
Sep 3 11:37:49 powerhouse kernel: [21409.372738] ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -110
Sep 3 11:38:05 powerhouse kernel: [21425.406196] INFO: rcu_sched detected stalls on CPUs/tasks:
Sep 3 11:38:20 powerhouse kernel: [21425.406201] 4-...: (0 ticks this GP) idle=02d/140000000000000/0 softirq=277173/277173 fqs=8
Sep 3 11:38:20 powerhouse kernel: [21425.406202] (detected by 7, t=7721 jiffies, g=246559, c=246558, q=936)
Sep 3 11:38:20 powerhouse kernel: [21425.406204] Task dump for CPU 4:
Sep 3 11:38:20 powerhouse kernel: [21425.406206] rmmod R running task 0 8122 8121 0x00000008
Sep 3 11:38:20 powerhouse kernel: [21425.406209] 0000000000000002 ffff8decf4cd7e48 ffffffffbd3df853 0000000000000000
Sep 3 11:38:20 powerhouse kernel: [21425.406211] 0000000000000000 ffffffffbcccc3d3 0000000000000246 000000000000000b
Sep 3 11:38:20 powerhouse kernel: [21425.406214] ffffffffbcc289f8 0000000000000006 ffff8decf4cd7e48 0000000000000004
Sep 3 11:38:20 powerhouse kernel: [21425.406216] Call Trace:
Sep 3 11:38:20 powerhouse kernel: [21425.406222] [<ffffffffbcccc3d3>] ? kmsg_dump+0x93/0xb0
Sep 3 11:38:20 powerhouse kernel: [21425.406225] [<ffffffffbcc289f8>] ? oops_end+0x78/0xd0
Sep 3 11:38:20 powerhouse kernel: [21425.406228] [<ffffffffbcc26446>] ? do_error_trap+0x86/0x100
Sep 3 11:38:20 powerhouse kernel: [21425.406976] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
Sep 3 11:38:20 powerhouse kernel: [21425.406979] [<ffffffffbcdda242>] ? kmem_cache_alloc+0x122/0x530
Sep 3 11:38:20 powerhouse kernel: [21425.406982] [<ffffffffbd1e9a2e>] ? invalid_op+0x1e/0x30
Sep 3 11:38:20 powerhouse kernel: [21425.407276] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
Sep 3 11:38:20 powerhouse kernel: [21425.407277] perf: interrupt took too long (8612 > 2500), lowering kernel.perf_event_max_sample_rate to 23000
Sep 3 11:3Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Linux version 4.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)
Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 root=/dev/mapper/powerhouse--vg-root ro quiet
Obviously, I'm not certain the bug is in this kernel module or even has
anything to do with it, but I thought this was a good place to start. Advice
welcome, happy to help however I can, I am a software engineer but not very
experienced at kernel hacking.
Many thanks!
-Carl
--
Carl Myers
PGP Key ID 3537595B
PGP Key fingerprint 9365 0FAF 721B 992A 0A20 1E0D C795 2955 3537 595B
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 8/10] ath9k: Use ARRAY_SIZE macro
From: Thomas Meyer @ 2017-09-03 12:19 UTC (permalink / raw)
To: kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1504439110050-939061377-0-diffsplit-thomas@m3y3r.de>
Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 3dbfd86ebe36..c2e210c0a770 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -15,6 +15,7 @@
*/
#include <asm/unaligned.h>
+#include <linux/kernel.h>
#include "hw.h"
#include "ar9003_phy.h"
#include "ar9003_eeprom.h"
@@ -2946,14 +2947,12 @@ static const struct ar9300_eeprom *ar9300_eep_templates[] = {
static const struct ar9300_eeprom *ar9003_eeprom_struct_find_by_id(int id)
{
-#define N_LOOP (sizeof(ar9300_eep_templates) / sizeof(ar9300_eep_templates[0]))
int it;
- for (it = 0; it < N_LOOP; it++)
+ for (it = 0; it < ARRAY_SIZE(ar9300_eep_templates); it++)
if (ar9300_eep_templates[it]->templateVersion == id)
return ar9300_eep_templates[it];
return NULL;
-#undef N_LOOP
}
static int ath9k_hw_ar9300_check_eeprom(struct ath_hw *ah)
^ permalink raw reply related
* Re: Sequence Number Issue for QoS frames in 3352 SOC
From: Stanislaw Gruszka @ 2017-09-02 8:30 UTC (permalink / raw)
To: Nishank aggarwal; +Cc: linux-wireless, Helmut Schaa
In-Reply-To: <CAGb8t=s+KYFnCxgMbyhGS9trujA+xdAiEwLNVEZyocHSSb-PNg@mail.gmail.com>
On Fri, Sep 01, 2017 at 04:18:36PM +0530, Nishank aggarwal wrote:
> *This is Nishank Aggarwal having 4 years of Experience in Linux Device
> Driver Development . I would like to discuss one issue i am facing in my
> current project related to WLAN 802.11 e Qos data frame.*
> *We are using 3352 SOC openwrt where i am getting one issue " STA
> re-transmitting the frames with incremented sequence number.
> <https://github.com/VivintInnovationJDM/ges-openwrt/issues/33>"*
This link seems to be wrong.
> *for Qos data frame, I paste some of the examples of sniffer logs captured.*
>
> 226269 2017-07-04 11
> <callto:226269%202017-07-04%2011>:46:42.358904 3c:4f:2d:6c:a9:e7 Netgear_3d:d5:cd QoS
> Data, SN=15, FN=0, Flags=.p..TC 15
>
> 226272 2017-07-04 11
> <callto:226272%202017-07-04%2011>:46:42.358904 3c:4f:2d:6c:a9:e7 Netgear_3d:d5:cd QoS
> Data, SN=16, FN=0, Flags=.p..R..TC 16 Frame is being
> retransmitted226279 2017-07-04 11
> <callto:226279%202017-07-04%2011>:46:42.366403 3c:4f:2d:6c:a9:e7 Netgear_3d:d5:cd QoS
> Data, SN=17, FN=0, Flags=.p..R..TC 17 Frame is being retransmitted
>
> *I know QoS data frames are generated in mac layer but i am not aware
> about where re-transmission of QoS data frames is taken care. I would
> like to know how the re-transmission frame are generated for the QoS data
> in the 3352 SOC. *
Data frames are retransmitted by the hardware. If sequence numbers
are incorrectly increased, it can be hardware or firmware bug,
but is also possible that some HW register is not correctly
programmed by the driver.
Stanislaw
^ permalink raw reply
* Re: RT2870 failure in kernel 4.12.8
From: Stanislaw Gruszka @ 2017-09-02 8:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: Larry Finger, Helmut Schaa, linux-wireless
In-Reply-To: <87y3pymqw2.fsf@purkki.adurom.net>
On Fri, Sep 01, 2017 at 05:31:57PM +0300, Kalle Valo wrote:
> Stanislaw Gruszka <sgruszka@redhat.com> writes:
>
> > On Thu, Aug 31, 2017 at 10:33:28AM -0500, Larry Finger wrote:
> >> Should the patch to wireless-drivers be annotated with a Stable reference so
> >> that it is added to 4.12 and 4.13?
> >
> > According to Documentation/networking/netdev-FAQ.txt networking patches
> > should not be marked cc:stable, instead a decent commit log should
> > be written describing a bugfix. Which I believe it is done for
> > this patch.
>
> But that's for net and net-next trees, not for wireless trees. With
> wireless patches we use "Cc: stable@..." references.
Oh, ok. I was confused by below part of
Documentation/process/stable-kernel-rules.rst
(because wireless drivers are located in drivers/net/)
- If the patch covers files in net/ or drivers/net please follow netdev stable
submission guidelines as described in
Documentation/networking/netdev-FAQ.txt
Thanks
Stanislaw
^ permalink raw reply
* [PATCH] iwlwifi: mvm: initialize status in iwl_mvm_add_int_sta_common()
From: Luca Coelho @ 2017-09-02 8:13 UTC (permalink / raw)
To: dan.carpenter; +Cc: shaul.triebitz, kvalo, linux-wireless, Luca Coelho
In-Reply-To: <20170901083022.t6e2zlrqfyebrf5t@mwanda>
From: Luca Coelho <luciano.coelho@intel.com>
We always need to initialize the status argument to the success case
before calling iwl_mvm_send_cmd_status() or
iwl_mvm_send_cmd_pdu_status() (which calls the former) otherwise we
may get an uninitialized value back. In this case, we use
ADD_STA_SUCCESS as success.
Fixes: 732d06e9d9cf ("iwlwifi: mvm: add station before allocating a queue")
Reported by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 411a2055dc45..b476c365d9b4 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -1285,7 +1285,7 @@ static int iwl_mvm_add_int_sta_common(struct iwl_mvm *mvm,
{
struct iwl_mvm_add_sta_cmd cmd;
int ret;
- u32 status;
+ u32 status = ADD_STA_SUCCESS;
lockdep_assert_held(&mvm->mutex);
--
2.14.1
^ permalink raw reply related
* Re: [bug report] iwlwifi: mvm: add station before allocating a queue
From: Coelho, Luciano @ 2017-09-02 8:03 UTC (permalink / raw)
To: Triebitz, Shaul, dan.carpenter@oracle.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20170901083022.t6e2zlrqfyebrf5t@mwanda>
T24gRnJpLCAyMDE3LTA5LTAxIGF0IDExOjMwICswMzAwLCBEYW4gQ2FycGVudGVyIHdyb3RlOg0K
PiBIZWxsbyBTaGF1bCBUcmllYml0eiwNCj4gDQo+IFRoZSBwYXRjaCA3MzJkMDZlOWQ5Y2Y6ICJp
d2x3aWZpOiBtdm06IGFkZCBzdGF0aW9uIGJlZm9yZSBhbGxvY2F0aW5nDQo+IGEgcXVldWUiIGZy
b20gSnVsIDEwLCAyMDE3LCBsZWFkcyB0byB0aGUgZm9sbG93aW5nIHN0YXRpYyBjaGVja2VyDQo+
IHdhcm5pbmc6DQo+IA0KPiAJZHJpdmVycy9uZXQvd2lyZWxlc3MvaW50ZWwvaXdsd2lmaS9tdm0v
c3RhLmM6MTMxMiBpd2xfbXZtX2FkZF9pbnRfc3RhX2NvbW1vbigpDQo+IAllcnJvcjogdW5pbml0
aWFsaXplZCBzeW1ib2wgJ3N0YXR1cycuDQo+IA0KPiBkcml2ZXJzL25ldC93aXJlbGVzcy9pbnRl
bC9pd2x3aWZpL212bS9zdGEuYw0KPiAgIDEyODEgIHN0YXRpYyBpbnQgaXdsX212bV9hZGRfaW50
X3N0YV9jb21tb24oc3RydWN0IGl3bF9tdm0gKm12bSwNCj4gICAxMjgyICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBpd2xfbXZtX2ludF9zdGEgKnN0YSwNCj4g
ICAxMjgzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHU4ICph
ZGRyLA0KPiAgIDEyODQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdTE2
IG1hY19pZCwgdTE2IGNvbG9yKQ0KPiAgIDEyODUgIHsNCj4gICAxMjg2ICAgICAgICAgIHN0cnVj
dCBpd2xfbXZtX2FkZF9zdGFfY21kIGNtZDsNCj4gICAxMjg3ICAgICAgICAgIGludCByZXQ7DQo+
ICAgMTI4OCAgICAgICAgICB1MzIgc3RhdHVzOw0KPiAgICAgICAgICAgICAgICAgXl5eXl5eXl5e
Xg0KPiAgIDEyODkgIA0KPiAgIDEyOTAgICAgICAgICAgbG9ja2RlcF9hc3NlcnRfaGVsZCgmbXZt
LT5tdXRleCk7DQo+ICAgMTI5MSAgDQo+ICAgMTI5MiAgICAgICAgICBtZW1zZXQoJmNtZCwgMCwg
c2l6ZW9mKGNtZCkpOw0KPiAgIDEyOTMgICAgICAgICAgY21kLnN0YV9pZCA9IHN0YS0+c3RhX2lk
Ow0KPiAgIDEyOTQgICAgICAgICAgY21kLm1hY19pZF9uX2NvbG9yID0gY3B1X3RvX2xlMzIoRldf
Q01EX0lEX0FORF9DT0xPUihtYWNfaWQsDQo+ICAgMTI5NSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbG9yKSk7DQo+ICAgMTI5
NiAgICAgICAgICBpZiAoZndfaGFzX2FwaSgmbXZtLT5mdy0+dWNvZGVfY2FwYSwgSVdMX1VDT0RF
X1RMVl9BUElfU1RBX1RZUEUpKQ0KPiAgIDEyOTcgICAgICAgICAgICAgICAgICBjbWQuc3RhdGlv
bl90eXBlID0gc3RhLT50eXBlOw0KPiAgIDEyOTggIA0KPiAgIDEyOTkgICAgICAgICAgaWYgKCFp
d2xfbXZtX2hhc19uZXdfdHhfYXBpKG12bSkpDQo+ICAgMTMwMCAgICAgICAgICAgICAgICAgIGNt
ZC50ZmRfcXVldWVfbXNrID0gY3B1X3RvX2xlMzIoc3RhLT50ZmRfcXVldWVfbXNrKTsNCj4gICAx
MzAxICAgICAgICAgIGNtZC50aWRfZGlzYWJsZV90eCA9IGNwdV90b19sZTE2KDB4ZmZmZik7DQo+
ICAgMTMwMiAgDQo+ICAgMTMwMyAgICAgICAgICBpZiAoYWRkcikNCj4gICAxMzA0ICAgICAgICAg
ICAgICAgICAgbWVtY3B5KGNtZC5hZGRyLCBhZGRyLCBFVEhfQUxFTik7DQo+ICAgMTMwNSAgDQo+
ICAgMTMwNiAgICAgICAgICByZXQgPSBpd2xfbXZtX3NlbmRfY21kX3BkdV9zdGF0dXMobXZtLCBB
RERfU1RBLA0KPiAgIDEzMDcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGl3bF9tdm1fYWRkX3N0YV9jbWRfc2l6ZShtdm0pLA0KPiAgIDEzMDggICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZjbWQsICZzdGF0dXMpOw0KPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl4N
Cj4gICAxMzA5ICAgICAgICAgIGlmIChyZXQpDQo+ICAgMTMxMCAgICAgICAgICAgICAgICAgIHJl
dHVybiByZXQ7DQo+ICAgMTMxMSAgDQo+ICAgMTMxMiAgICAgICAgICBzd2l0Y2ggKHN0YXR1cyAm
IElXTF9BRERfU1RBX1NUQVRVU19NQVNLKSB7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIF5e
Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ICAgMTMxMyAgICAgICAgICBjYXNlIEFE
RF9TVEFfU1VDQ0VTUzoNCj4gICAxMzE0ICAgICAgICAgICAgICAgICAgSVdMX0RFQlVHX0lORk8o
bXZtLCAiSW50ZXJuYWwgc3RhdGlvbiBhZGRlZC5cbiIpOw0KPiAgIDEzMTUgICAgICAgICAgICAg
ICAgICByZXR1cm4gMDsNCj4gICAxMzE2ICAgICAgICAgIGRlZmF1bHQ6DQo+ICAgMTMxNyAgICAg
ICAgICAgICAgICAgIHJldCA9IC1FSU87DQo+ICAgMTMxOCAgICAgICAgICAgICAgICAgIElXTF9F
UlIobXZtLCAiQWRkIGludGVybmFsIHN0YXRpb24gZmFpbGVkLCBzdGF0dXM9MHgleFxuIiwNCj4g
ICAxMzE5ICAgICAgICAgICAgICAgICAgICAgICAgICBzdGF0dXMpOw0KPiAgIDEzMjAgICAgICAg
ICAgICAgICAgICBicmVhazsNCj4gICAxMzIxICAgICAgICAgIH0NCj4gICAxMzIyICAgICAgICAg
IHJldHVybiByZXQ7DQo+ICAgMTMyMyAgfQ0KPiANCj4gVGhlIHByb2JsZW0gaGVyZSBpcyB0aGlz
IGNvZGUgZnJvbSBpd2xfbXZtX3NlbmRfY21kX3N0YXR1cygpDQo+IA0KPiBkcml2ZXJzL25ldC93
aXJlbGVzcy9pbnRlbC9pd2x3aWZpL212bS91dGlscy5jDQo+ICAgIDE1NyAgICAgICAgICBjbWQt
PmZsYWdzIHw9IENNRF9XQU5UX1NLQjsNCj4gICAgMTU4ICANCj4gICAgMTU5ICAgICAgICAgIHJl
dCA9IGl3bF90cmFuc19zZW5kX2NtZChtdm0tPnRyYW5zLCBjbWQpOw0KPiAgICAxNjAgICAgICAg
ICAgaWYgKHJldCA9PSAtRVJGS0lMTCkgew0KPiAgICAxNjEgICAgICAgICAgICAgICAgICAvKg0K
PiAgICAxNjIgICAgICAgICAgICAgICAgICAgKiBUaGUgY29tbWFuZCBmYWlsZWQgYmVjYXVzZSBv
ZiBSRktJTEwsIGRvbid0IHVwZGF0ZQ0KPiAgICAxNjMgICAgICAgICAgICAgICAgICAgKiB0aGUg
c3RhdHVzLCBsZWF2ZSBpdCBhcyBzdWNjZXNzIGFuZCByZXR1cm4gMC4NCj4gICAgMTY0ICAgICAg
ICAgICAgICAgICAgICovDQo+ICAgIDE2NSAgICAgICAgICAgICAgICAgIHJldHVybiAwOw0KPiAN
Cj4gV2UgcmV0dXJuIHplcm8gd2l0aG91dCBzZXR0aW5nICJzdGF0dXMiLiAgU2hvdWxkbid0IHdl
IHNldCAqc3RhdHVzID0gMDs/DQo+IA0KPiAgICAxNjYgICAgICAgICAgfSBlbHNlIGlmIChyZXQp
IHsNCj4gICAgMTY3ICAgICAgICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4gICAgMTY4ICAgICAg
ICAgIH0NCj4gICAgMTY5ICANCj4gICAgMTcwICAgICAgICAgIHBrdCA9IGNtZC0+cmVzcF9wa3Q7
DQoNClRoZSBjYWxsZXIgc2hvdWxkIHNldCB0aGUgc3RhdHVzIHRvICJzdWNjZXNzIiBiZWZvcmUg
Y2FsbGluZyB0aGlzDQpmdW5jdGlvbi4gIEluIHNvbWUgY2FzZXMgc3VjY2VzcyBpcyBub3QgemVy
byAoZS5nLiB3ZSB1c2UNCkFERF9TVEFfU1VDQ0VTUywgd2hpY2ggaXMgMSwgaW4gc2V2ZXJhbCBw
bGFjZXMpLg0KDQpJJ2xsIHNlbmQgYSBmaXggc3BlY2lmaWMgZm9yIHRoaXMgcGF0Y2ggYW5kIGFu
IGFkZGl0aW9uYWwgb25lIGZvciBvdGhlcg0KcGxhY2VzIHdoZXJlIHdlIGFsc28gY2FsbCB0aGlz
IGZ1bmN0aW9uIHdpdGhvdXQgaW5pdGlhbGl6aW5nIHN0YXR1cy4NCg0KVGhhbmtzIGZvciByZXBv
cnRpbmchDQoNCi0tDQpDaGVlcnMsDQpMdWNhLg==
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices
From: Ian W MORRISON @ 2017-09-02 7:15 UTC (permalink / raw)
To: Arend van Spriel; +Cc: kvalo, Ian Molton, open list:TI WILINK WIRELES...
In-Reply-To: <7481b892-511f-4696-bf3f-82b1bec50abf@broadcom.com>
On 2 September 2017 at 06:04, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 31-08-17 00:51, Ian W MORRISON wrote:
>>
>> The firmware feature check introduced for multi-scheduled scan is also
>> failing for bcm4345 devices resulting in a firmware crash.
>> The reason for this crash has not yet been root cause so this patch avoids
>> the feature check for those device as a short-term fix.
>
>
> Thanks. This is one of the few devices that I actually do not have on my
> desk.
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>
>> Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan
>> feature")
>> Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
>> ---
>> v2: Fixed tabs being replaced by spaces in patch submission
>> Tested on MINIX NEO Z83-4 and MINIX NEO Z83-4 Pro devices.
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
Thanks. This patch of course is required to fix the '4.13 REGRESSION'
for brcm4345 sdio wifi with 4.13-rc1 through 4.13-rc7 as v4.12.10 is
the last working release. If you want me to test anything specific on
this device let me know.
^ permalink raw reply
* Re: Problem with the wifi
From: Paolo Bettini @ 2017-09-02 7:13 UTC (permalink / raw)
To: Arend van Spriel, Larry Finger; +Cc: linux-wireless
In-Reply-To: <593b1d88-25fa-5d99-b74e-8e0c535243e1@broadcom.com>
Arend van Spriel ha scritto:
> On 09-08-17 18:40, Larry Finger wrote:
>> On 08/08/2017 04:10 AM, Arend van Spriel wrote:
>>> + linux-wireless
>>> + Larry
>>>
>>> please keep linux-wireless in this thread.
>>>
>>> On 08-08-17 08:21, Paolo Bettini wrote:
>>>> Arend van Spriel ha scritto:
>>>>> + linux-wireless On 07-08-17 21:38, Paolo Bettini wrote:
>>>>>> Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One
>>>>>> problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6
>>>>>> linux id or Broadcom AP6212 for windows....i installed deb package
>>>>>> firmware-brcm80211 and nvram sdio txt in /lib/firmware/brcm,
>>>>>> reloaded
>>>>>> bcrmfmac module but nothing the card seems invisible or dead i don't
>>>>>> know if is a problem of firmware or my system cannot detect the sdio
>>>>>> card ...do you know something about this problematic ?
>>>>> As always a kernel log could help or output from dmesg command. Also
>>>>> can you run following commands: $ ls /sys/bus/sdio/devices $ cat
>>>>> /sys/bus/sdio/devices/*/modalias Regards, Arend
>>>> paolo@paolo:~$ ls /sys/bus/sdio/devices
>>>> mmc1:0001:1
>>>> paolo@paolo:~$
>>>>
>>>>
>>>> paolo@paolo:~$ cat /sys/bus/sdio/devices/*/modalias sdio:c07v024CdB723
>>>> paolo@paolo:~$ sorry for previous mail ....ls was from another
>>>> pc....:-[
>>>> it seems the system see only the card where the system is installed
>>>
>>> Hi Paolo,
>>>
>>> Interesting. Now if Google search is correct the vendor id for this
>>> device indicates this is a Realtek (v024C) WLAN (c07) device. So what
>>> makes you say its linux id is 02d0:a9a6?
>>>
>>> In upstream linux I do not see any SDIO device drivers in realtek
>>> folder. Maybe Larry can provide clue/hint if a driver for this
>>> device is
>>> publicly available somewhere.
>>
>> Paolo,
>>
>> The only Realtek SDIO device in common distribution is the RTL8723BS,
>> which has been packaged with some Intel processors, and may now be
>> part of other SBC's. This driver has been in staging since V4.12. It
>> handles SDIO Vendor code 0x024c with device codes 0x0523, 0x0623,
>> 0x0626, and 0xb723. If your device is one of these, then you only
>> need to build a kernel with this driver enabled.
>
> He has device id 0xb723:
>
> paolo@paolo:~$ cat /sys/bus/sdio/devices/*/modalias sdio:c07v024CdB723
>
> So that driver should at least try to probe his device.
>
> Regards,
> Arend
>
I built my own kernel in the debian way , very simple and amusing , i
removed some modules not interesting , i set to M rtl8723bs and all ok
!!! only a bit long the building with my dual core ,The bluetooth needs
rtk_hciattach of Larry Finger , however strange the new debian kernels
above all 4.13rc have not set rtl8723bs module.
Best regards
rtk_hciattach
^ permalink raw reply
* [PATCH V2 9/9] qtnfmac: do not report channel changes until wiphy is registered
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/event.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c b/drivers/net/wireless/quantenna/qtnfmac/event.c
index b1acc24..7481d5b 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -368,6 +368,9 @@ qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
return -EINVAL;
}
+ if (!wiphy->registered)
+ return 0;
+
qlink_chandef_q2cfg(wiphy, &data->chan, &chandef);
if (!cfg80211_chandef_valid(&chandef)) {
--
2.9.5
^ permalink raw reply related
* [PATCH V2 8/9] qtnfmac: remove unused mac::status field
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
It is no longer used.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/commands.c | 1 -
drivers/net/wireless/quantenna/qtnfmac/core.h | 5 -----
drivers/net/wireless/quantenna/qtnfmac/event.c | 2 --
3 files changed, 8 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 42f7e1d..8f95f98 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -2337,7 +2337,6 @@ int qtnf_cmd_send_chan_switch(struct qtnf_vif *vif,
switch (res_code) {
case QLINK_CMD_RESULT_OK:
- mac->status |= QTNF_MAC_CSA_ACTIVE;
ret = 0;
break;
case QLINK_CMD_RESULT_ENOTFOUND:
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 521ce09..2cd0150 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -89,10 +89,6 @@ enum qtnf_sta_state {
QTNF_STA_CONNECTED
};
-enum qtnf_mac_status {
- QTNF_MAC_CSA_ACTIVE = BIT(0)
-};
-
struct qtnf_vif {
struct wireless_dev wdev;
u8 vifid;
@@ -141,7 +137,6 @@ struct qtnf_wmac {
u8 macid;
u8 wiphy_registered;
u8 macaddr[ETH_ALEN];
- u32 status;
struct qtnf_bus *bus;
struct qtnf_mac_info macinfo;
struct qtnf_vif iflist[QTNF_MAX_INTF];
diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c b/drivers/net/wireless/quantenna/qtnfmac/event.c
index 77563b0..b1acc24 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -381,8 +381,6 @@ qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
mac->macid, chandef.chan->hw_value, chandef.center_freq1,
chandef.center_freq2, chandef.width);
- mac->status &= ~QTNF_MAC_CSA_ACTIVE;
-
memcpy(&mac->chandef, &chandef, sizeof(mac->chandef));
for (i = 0; i < QTNF_MAX_INTF; i++) {
--
2.9.5
^ permalink raw reply related
* [PATCH V2 7/9] qtnfmac: do not cache CSA chandef info
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
It is never used for anything useful, and all logic is handled by
either WiFi card or higher layers.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 12 ------------
drivers/net/wireless/quantenna/qtnfmac/commands.c | 2 --
drivers/net/wireless/quantenna/qtnfmac/core.h | 1 -
drivers/net/wireless/quantenna/qtnfmac/event.c | 8 +-------
4 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 30f8be5..262e8cf 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -809,7 +809,6 @@ qtnf_get_channel(struct wiphy *wiphy, struct wireless_dev *wdev,
static int qtnf_channel_switch(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_csa_settings *params)
{
- struct qtnf_wmac *mac = wiphy_priv(wiphy);
struct qtnf_vif *vif = qtnf_netdev_get_priv(dev);
int ret;
@@ -830,17 +829,6 @@ static int qtnf_channel_switch(struct wiphy *wiphy, struct net_device *dev,
return -EOPNOTSUPP;
}
- if (vif->vifid != 0) {
- if (!(mac->status & QTNF_MAC_CSA_ACTIVE))
- return -EOPNOTSUPP;
-
- if (!cfg80211_chandef_identical(¶ms->chandef,
- &mac->csa_chandef))
- return -EINVAL;
-
- return 0;
- }
-
if (!cfg80211_chandef_valid(¶ms->chandef)) {
pr_err("%s: invalid channel\n", dev->name);
return -EINVAL;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 0138dad..42f7e1d 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -2337,8 +2337,6 @@ int qtnf_cmd_send_chan_switch(struct qtnf_vif *vif,
switch (res_code) {
case QLINK_CMD_RESULT_OK:
- memcpy(&mac->csa_chandef, ¶ms->chandef,
- sizeof(mac->csa_chandef));
mac->status |= QTNF_MAC_CSA_ACTIVE;
ret = 0;
break;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 066fcd1..521ce09 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -147,7 +147,6 @@ struct qtnf_wmac {
struct qtnf_vif iflist[QTNF_MAX_INTF];
struct cfg80211_scan_request *scan_req;
struct cfg80211_chan_def chandef;
- struct cfg80211_chan_def csa_chandef;
struct mutex mac_lock; /* lock during wmac speicific ops */
struct timer_list scan_timeout;
};
diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c b/drivers/net/wireless/quantenna/qtnfmac/event.c
index df58e83..77563b0 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -381,13 +381,7 @@ qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
mac->macid, chandef.chan->hw_value, chandef.center_freq1,
chandef.center_freq2, chandef.width);
- if (mac->status & QTNF_MAC_CSA_ACTIVE) {
- mac->status &= ~QTNF_MAC_CSA_ACTIVE;
- if (chandef.chan->hw_value != mac->csa_chandef.chan->hw_value)
- pr_warn("unexpected switch to %u during CSA to %u\n",
- chandef.chan->hw_value,
- mac->csa_chandef.chan->hw_value);
- }
+ mac->status &= ~QTNF_MAC_CSA_ACTIVE;
memcpy(&mac->chandef, &chandef, sizeof(mac->chandef));
--
2.9.5
^ permalink raw reply related
* [PATCH V2 6/9] qtnfmac: pass VIF info to SendChannel command
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 2 +-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 5 +++--
drivers/net/wireless/quantenna/qtnfmac/commands.h | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 4590f30..30f8be5 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -846,7 +846,7 @@ static int qtnf_channel_switch(struct wiphy *wiphy, struct net_device *dev,
return -EINVAL;
}
- ret = qtnf_cmd_send_chan_switch(mac, params);
+ ret = qtnf_cmd_send_chan_switch(vif, params);
if (ret)
pr_warn("%s: failed to switch to channel (%u)\n",
dev->name, params->chandef.chan->hw_value);
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index c55bae1..0138dad 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -2306,15 +2306,16 @@ int qtnf_cmd_get_chan_stats(struct qtnf_wmac *mac, u16 channel,
return ret;
}
-int qtnf_cmd_send_chan_switch(struct qtnf_wmac *mac,
+int qtnf_cmd_send_chan_switch(struct qtnf_vif *vif,
struct cfg80211_csa_settings *params)
{
+ struct qtnf_wmac *mac = vif->mac;
struct qlink_cmd_chan_switch *cmd;
struct sk_buff *cmd_skb;
u16 res_code = QLINK_CMD_RESULT_OK;
int ret;
- cmd_skb = qtnf_cmd_alloc_new_cmdskb(mac->macid, 0x0,
+ cmd_skb = qtnf_cmd_alloc_new_cmdskb(mac->macid, vif->vifid,
QLINK_CMD_CHAN_SWITCH,
sizeof(*cmd));
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.h b/drivers/net/wireless/quantenna/qtnfmac/commands.h
index e1bcb83..8a5a82c 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.h
@@ -73,7 +73,7 @@ int qtnf_cmd_send_updown_intf(struct qtnf_vif *vif,
int qtnf_cmd_reg_notify(struct qtnf_bus *bus, struct regulatory_request *req);
int qtnf_cmd_get_chan_stats(struct qtnf_wmac *mac, u16 channel,
struct qtnf_chan_stats *stats);
-int qtnf_cmd_send_chan_switch(struct qtnf_wmac *mac,
+int qtnf_cmd_send_chan_switch(struct qtnf_vif *vif,
struct cfg80211_csa_settings *params);
int qtnf_cmd_get_channel(struct qtnf_vif *vif, struct cfg80211_chan_def *chdef);
--
2.9.5
^ permalink raw reply related
* [PATCH V2 5/9] qtnfmac: let wifi card handle channel switch request to the same chan
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 17b323e..4590f30 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -846,11 +846,6 @@ static int qtnf_channel_switch(struct wiphy *wiphy, struct net_device *dev,
return -EINVAL;
}
- if (cfg80211_chandef_identical(¶ms->chandef, &mac->chandef)) {
- pr_err("%s: switch request to the same channel\n", dev->name);
- return -EALREADY;
- }
-
ret = qtnf_cmd_send_chan_switch(mac, params);
if (ret)
pr_warn("%s: failed to switch to channel (%u)\n",
--
2.9.5
^ permalink raw reply related
* [PATCH V2 4/9] qtnfmac: do not cache channel info from "connect" command
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
This makes no sense because real operational channel is choosen based
on AP operation, not on what STA is configured to.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 15 +--------------
drivers/net/wireless/quantenna/qtnfmac/commands.c | 6 ++++--
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 0ef1285..17b323e 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -613,8 +613,6 @@ qtnf_connect(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_connect_params *sme)
{
struct qtnf_vif *vif = qtnf_netdev_get_priv(dev);
- struct qtnf_wmac *mac = wiphy_priv(wiphy);
- struct cfg80211_chan_def chandef;
struct qtnf_bss_config *bss_cfg;
int ret;
@@ -627,18 +625,6 @@ qtnf_connect(struct wiphy *wiphy, struct net_device *dev,
bss_cfg = &vif->bss_cfg;
memset(bss_cfg, 0, sizeof(*bss_cfg));
- if (sme->channel) {
- /* FIXME: need to set proper nl80211_channel_type value */
- cfg80211_chandef_create(&chandef, sme->channel,
- NL80211_CHAN_HT20);
- /* fall-back to minimal safe chandef description */
- if (!cfg80211_chandef_valid(&chandef))
- cfg80211_chandef_create(&chandef, sme->channel,
- NL80211_CHAN_HT20);
-
- memcpy(&mac->chandef, &chandef, sizeof(mac->chandef));
- }
-
bss_cfg->ssid_len = sme->ssid_len;
memcpy(&bss_cfg->ssid, sme->ssid, bss_cfg->ssid_len);
bss_cfg->auth_type = sme->auth_type;
@@ -663,6 +649,7 @@ qtnf_connect(struct wiphy *wiphy, struct net_device *dev,
bss_cfg->connect_flags |= QLINK_STA_CONNECT_USE_RRM;
memcpy(&bss_cfg->crypto, &sme->crypto, sizeof(bss_cfg->crypto));
+
if (sme->bssid)
ether_addr_copy(bss_cfg->bssid, sme->bssid);
else
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 806b88b..c55bae1 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -2055,8 +2055,10 @@ int qtnf_cmd_send_connect(struct qtnf_vif *vif,
ether_addr_copy(cmd->bssid, bss_cfg->bssid);
- if (vif->mac->chandef.chan)
- cmd->channel = cpu_to_le16(vif->mac->chandef.chan->hw_value);
+ if (sme->channel)
+ cmd->channel = cpu_to_le16(sme->channel->hw_value);
+ else
+ cmd->channel = 0;
cmd->bg_scan_period = cpu_to_le16(bss_cfg->bg_scan_period);
--
2.9.5
^ permalink raw reply related
* [PATCH V2 3/9] qtnfmac: retrieve current channel info from EP
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Do not try to cache current operational channel info in driver, this
is a potential source of synchronization issues + driver does not
really need that info.
Introduce GET_CHANNEL command and process it appropriately.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 35 +++++++++------------
drivers/net/wireless/quantenna/qtnfmac/commands.c | 38 +++++++++++++++++++++++
drivers/net/wireless/quantenna/qtnfmac/commands.h | 1 +
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 11 +++++++
4 files changed, 64 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 856fa6e..0ef1285 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -793,37 +793,30 @@ qtnf_get_channel(struct wiphy *wiphy, struct wireless_dev *wdev,
struct qtnf_wmac *mac = wiphy_priv(wiphy);
struct net_device *ndev = wdev->netdev;
struct qtnf_vif *vif;
+ int ret;
if (!ndev)
return -ENODEV;
vif = qtnf_netdev_get_priv(wdev->netdev);
- switch (vif->wdev.iftype) {
- case NL80211_IFTYPE_STATION:
- if (vif->sta_state == QTNF_STA_DISCONNECTED) {
- pr_warn("%s: STA disconnected\n", ndev->name);
- return -ENODATA;
- }
- break;
- case NL80211_IFTYPE_AP:
- if (!(vif->bss_status & QTNF_STATE_AP_START)) {
- pr_warn("%s: AP not started\n", ndev->name);
- return -ENODATA;
- }
- break;
- default:
- pr_err("unsupported vif type (%d)\n", vif->wdev.iftype);
- return -ENODATA;
+ ret = qtnf_cmd_get_channel(vif, chandef);
+ if (ret) {
+ pr_err("%s: failed to get channel: %d\n", ndev->name, ret);
+ goto out;
}
- if (!cfg80211_chandef_valid(&mac->chandef)) {
- pr_err("invalid channel settings on %s\n", ndev->name);
- return -ENODATA;
+ if (!cfg80211_chandef_valid(chandef)) {
+ pr_err("%s: bad chan freq1=%u freq2=%u bw=%u\n", ndev->name,
+ chandef->center_freq1, chandef->center_freq2,
+ chandef->width);
+ ret = -ENODATA;
}
- memcpy(chandef, &mac->chandef, sizeof(*chandef));
- return 0;
+ memcpy(&mac->chandef, chandef, sizeof(mac->chandef));
+
+out:
+ return ret;
}
static int qtnf_channel_switch(struct wiphy *wiphy, struct net_device *dev,
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 4206886..806b88b 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -2358,3 +2358,41 @@ int qtnf_cmd_send_chan_switch(struct qtnf_wmac *mac,
qtnf_bus_unlock(mac->bus);
return ret;
}
+
+int qtnf_cmd_get_channel(struct qtnf_vif *vif, struct cfg80211_chan_def *chdef)
+{
+ struct qtnf_bus *bus = vif->mac->bus;
+ const struct qlink_resp_channel_get *resp;
+ struct sk_buff *cmd_skb;
+ struct sk_buff *resp_skb = NULL;
+ u16 res_code = QLINK_CMD_RESULT_OK;
+ int ret;
+
+ cmd_skb = qtnf_cmd_alloc_new_cmdskb(vif->mac->macid, vif->vifid,
+ QLINK_CMD_CHAN_GET,
+ sizeof(struct qlink_cmd));
+ if (unlikely(!cmd_skb))
+ return -ENOMEM;
+
+ qtnf_bus_lock(bus);
+
+ ret = qtnf_cmd_send_with_reply(bus, cmd_skb, &resp_skb, &res_code,
+ sizeof(*resp), NULL);
+
+ qtnf_bus_unlock(bus);
+
+ if (unlikely(ret))
+ goto out;
+
+ if (unlikely(res_code != QLINK_CMD_RESULT_OK)) {
+ ret = -ENODATA;
+ goto out;
+ }
+
+ resp = (const struct qlink_resp_channel_get *)resp_skb->data;
+ qlink_chandef_q2cfg(priv_to_wiphy(vif->mac), &resp->chan, chdef);
+
+out:
+ consume_skb(resp_skb);
+ return ret;
+}
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.h b/drivers/net/wireless/quantenna/qtnfmac/commands.h
index 783b203..e1bcb83 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.h
@@ -75,5 +75,6 @@ int qtnf_cmd_get_chan_stats(struct qtnf_wmac *mac, u16 channel,
struct qtnf_chan_stats *stats);
int qtnf_cmd_send_chan_switch(struct qtnf_wmac *mac,
struct cfg80211_csa_settings *params);
+int qtnf_cmd_get_channel(struct qtnf_vif *vif, struct cfg80211_chan_def *chdef);
#endif /* QLINK_COMMANDS_H_ */
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index 5936854..fb88f3e 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -169,6 +169,7 @@ enum qlink_cmd_type {
QLINK_CMD_REG_NOTIFY = 0x0019,
QLINK_CMD_CHANS_INFO_GET = 0x001A,
QLINK_CMD_CHAN_SWITCH = 0x001B,
+ QLINK_CMD_CHAN_GET = 0x001C,
QLINK_CMD_CONFIG_AP = 0x0020,
QLINK_CMD_START_AP = 0x0021,
QLINK_CMD_STOP_AP = 0x0022,
@@ -694,6 +695,16 @@ struct qlink_resp_get_chan_stats {
u8 info[0];
} __packed;
+/**
+ * struct qlink_resp_channel_get - response for QLINK_CMD_CHAN_GET command
+ *
+ * @chan: definition of current operating channel.
+ */
+struct qlink_resp_channel_get {
+ struct qlink_resp rhdr;
+ struct qlink_chandef chan;
+} __packed;
+
/* QLINK Events messages related definitions
*/
--
2.9.5
^ permalink raw reply related
* [PATCH V2 2/9] qtnfmac: make "Channel change" event report full channel info
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Specifically, it has to report center frequency, secondary center
frequency (for 80+80) and BW.
Introduce channel definition structure to qlink and modify channel
change event processing function accordingly.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/event.c | 29 ++++++------
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 18 +++++++-
.../net/wireless/quantenna/qtnfmac/qlink_util.c | 52 ++++++++++++++++++++++
.../net/wireless/quantenna/qtnfmac/qlink_util.h | 4 ++
4 files changed, 85 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c b/drivers/net/wireless/quantenna/qtnfmac/event.c
index 0fc2814..df58e83 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -25,6 +25,7 @@
#include "trans.h"
#include "util.h"
#include "event.h"
+#include "qlink_util.h"
static int
qtnf_event_handle_sta_assoc(struct qtnf_wmac *mac, struct qtnf_vif *vif,
@@ -359,39 +360,35 @@ qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
{
struct wiphy *wiphy = priv_to_wiphy(mac);
struct cfg80211_chan_def chandef;
- struct ieee80211_channel *chan;
struct qtnf_vif *vif;
- int freq;
int i;
if (len < sizeof(*data)) {
- pr_err("payload is too short\n");
+ pr_err("MAC%u: payload is too short\n", mac->macid);
return -EINVAL;
}
- freq = le32_to_cpu(data->freq);
- chan = ieee80211_get_channel(wiphy, freq);
- if (!chan) {
- pr_err("channel at %d MHz not found\n", freq);
+ qlink_chandef_q2cfg(wiphy, &data->chan, &chandef);
+
+ if (!cfg80211_chandef_valid(&chandef)) {
+ pr_err("MAC%u: bad channel f1=%u f2=%u bw=%u\n", mac->macid,
+ chandef.center_freq1, chandef.center_freq2,
+ chandef.width);
return -EINVAL;
}
- pr_debug("MAC%d switch to new channel %u MHz\n", mac->macid, freq);
+ pr_debug("MAC%d: new channel ieee=%u freq1=%u freq2=%u bw=%u\n",
+ mac->macid, chandef.chan->hw_value, chandef.center_freq1,
+ chandef.center_freq2, chandef.width);
if (mac->status & QTNF_MAC_CSA_ACTIVE) {
mac->status &= ~QTNF_MAC_CSA_ACTIVE;
- if (chan->hw_value != mac->csa_chandef.chan->hw_value)
+ if (chandef.chan->hw_value != mac->csa_chandef.chan->hw_value)
pr_warn("unexpected switch to %u during CSA to %u\n",
- chan->hw_value,
+ chandef.chan->hw_value,
mac->csa_chandef.chan->hw_value);
}
- /* FIXME: need to figure out proper nl80211_channel_type value */
- cfg80211_chandef_create(&chandef, chan, NL80211_CHAN_HT20);
- /* fall-back to minimal safe chandef description */
- if (!cfg80211_chandef_valid(&chandef))
- cfg80211_chandef_create(&chandef, chan, NL80211_CHAN_HT20);
-
memcpy(&mac->chandef, &chandef, sizeof(mac->chandef));
for (i = 0; i < QTNF_MAX_INTF; i++) {
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index a69fd470..5936854 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -118,6 +118,20 @@ enum qlink_channel_width {
QLINK_CHAN_WIDTH_160,
};
+/**
+ * struct qlink_chandef - qlink channel definition
+ *
+ * @center_freq1: center frequency of first segment
+ * @center_freq2: center frequency of second segment (80+80 only)
+ * @width: channel width, one of @enum qlink_channel_width
+ */
+struct qlink_chandef {
+ __le16 center_freq1;
+ __le16 center_freq2;
+ u8 width;
+ u8 rsvd[3];
+} __packed;
+
/* QLINK Command messages related definitions
*/
@@ -764,11 +778,11 @@ struct qlink_event_bss_leave {
/**
* struct qlink_event_freq_change - data for QLINK_EVENT_FREQ_CHANGE event
*
- * @freq: new operating frequency in MHz
+ * @chan: new operating channel definition
*/
struct qlink_event_freq_change {
struct qlink_event ehdr;
- __le32 freq;
+ struct qlink_chandef chan;
} __packed;
enum qlink_rxmgmt_flags {
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c b/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c
index 369b77d..3c1db5b 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c
@@ -75,3 +75,55 @@ u8 qlink_chan_width_mask_to_nl(u16 qlink_mask)
return result;
}
+
+static enum nl80211_chan_width qlink_chanwidth_to_nl(u8 qlw)
+{
+ switch (qlw) {
+ case QLINK_CHAN_WIDTH_20_NOHT:
+ return NL80211_CHAN_WIDTH_20_NOHT;
+ case QLINK_CHAN_WIDTH_20:
+ return NL80211_CHAN_WIDTH_20;
+ case QLINK_CHAN_WIDTH_40:
+ return NL80211_CHAN_WIDTH_40;
+ case QLINK_CHAN_WIDTH_80:
+ return NL80211_CHAN_WIDTH_80;
+ case QLINK_CHAN_WIDTH_80P80:
+ return NL80211_CHAN_WIDTH_80P80;
+ case QLINK_CHAN_WIDTH_160:
+ return NL80211_CHAN_WIDTH_160;
+ case QLINK_CHAN_WIDTH_5:
+ return NL80211_CHAN_WIDTH_5;
+ case QLINK_CHAN_WIDTH_10:
+ return NL80211_CHAN_WIDTH_10;
+ default:
+ return -1;
+ }
+}
+
+void qlink_chandef_q2cfg(struct wiphy *wiphy,
+ const struct qlink_chandef *qch,
+ struct cfg80211_chan_def *chdef)
+{
+ chdef->center_freq1 = le16_to_cpu(qch->center_freq1);
+ chdef->center_freq2 = le16_to_cpu(qch->center_freq2);
+ chdef->width = qlink_chanwidth_to_nl(qch->width);
+
+ switch (chdef->width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
+ chdef->chan = ieee80211_get_channel(wiphy, chdef->center_freq1);
+ break;
+ case NL80211_CHAN_WIDTH_40:
+ case NL80211_CHAN_WIDTH_80:
+ case NL80211_CHAN_WIDTH_80P80:
+ case NL80211_CHAN_WIDTH_160:
+ chdef->chan = ieee80211_get_channel(wiphy,
+ chdef->center_freq1 - 10);
+ break;
+ default:
+ chdef->chan = NULL;
+ break;
+ }
+}
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink_util.h b/drivers/net/wireless/quantenna/qtnfmac/qlink_util.h
index de06c1e..5e49a8a 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink_util.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink_util.h
@@ -19,6 +19,7 @@
#include <linux/types.h>
#include <linux/skbuff.h>
+#include <net/cfg80211.h>
#include "qlink.h"
@@ -62,5 +63,8 @@ static inline void qtnf_cmd_skb_put_tlv_u16(struct sk_buff *skb,
u16 qlink_iface_type_to_nl_mask(u16 qlink_type);
u8 qlink_chan_width_mask_to_nl(u16 qlink_mask);
+void qlink_chandef_q2cfg(struct wiphy *wiphy,
+ const struct qlink_chandef *qch,
+ struct cfg80211_chan_def *chdef);
#endif /* _QTN_FMAC_QLINK_UTIL_H_ */
--
2.9.5
^ permalink raw reply related
* [PATCH V2 1/9] qtnfmac: qlink: convert channel width from bitfiled to simple enum
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-1-igor.mitsyanko.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 16 ++++++++--------
drivers/net/wireless/quantenna/qtnfmac/qlink_util.c | 16 ++++++++--------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index a8242f6..a69fd470 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -108,14 +108,14 @@ enum qlink_sta_flags {
};
enum qlink_channel_width {
- QLINK_CHAN_WIDTH_5 = BIT(0),
- QLINK_CHAN_WIDTH_10 = BIT(1),
- QLINK_CHAN_WIDTH_20_NOHT = BIT(2),
- QLINK_CHAN_WIDTH_20 = BIT(3),
- QLINK_CHAN_WIDTH_40 = BIT(4),
- QLINK_CHAN_WIDTH_80 = BIT(5),
- QLINK_CHAN_WIDTH_80P80 = BIT(6),
- QLINK_CHAN_WIDTH_160 = BIT(7),
+ QLINK_CHAN_WIDTH_5 = 0,
+ QLINK_CHAN_WIDTH_10,
+ QLINK_CHAN_WIDTH_20_NOHT,
+ QLINK_CHAN_WIDTH_20,
+ QLINK_CHAN_WIDTH_40,
+ QLINK_CHAN_WIDTH_80,
+ QLINK_CHAN_WIDTH_80P80,
+ QLINK_CHAN_WIDTH_160,
};
/* QLINK Command messages related definitions
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c b/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c
index cf024c9..369b77d 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink_util.c
@@ -49,28 +49,28 @@ u8 qlink_chan_width_mask_to_nl(u16 qlink_mask)
{
u8 result = 0;
- if (qlink_mask & QLINK_CHAN_WIDTH_5)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_5))
result |= BIT(NL80211_CHAN_WIDTH_5);
- if (qlink_mask & QLINK_CHAN_WIDTH_10)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_10))
result |= BIT(NL80211_CHAN_WIDTH_10);
- if (qlink_mask & QLINK_CHAN_WIDTH_20_NOHT)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_20_NOHT))
result |= BIT(NL80211_CHAN_WIDTH_20_NOHT);
- if (qlink_mask & QLINK_CHAN_WIDTH_20)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_20))
result |= BIT(NL80211_CHAN_WIDTH_20);
- if (qlink_mask & QLINK_CHAN_WIDTH_40)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_40))
result |= BIT(NL80211_CHAN_WIDTH_40);
- if (qlink_mask & QLINK_CHAN_WIDTH_80)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_80))
result |= BIT(NL80211_CHAN_WIDTH_80);
- if (qlink_mask & QLINK_CHAN_WIDTH_80P80)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_80P80))
result |= BIT(NL80211_CHAN_WIDTH_80P80);
- if (qlink_mask & QLINK_CHAN_WIDTH_160)
+ if (qlink_mask & BIT(QLINK_CHAN_WIDTH_160))
result |= BIT(NL80211_CHAN_WIDTH_160);
return result;
--
2.9.5
^ permalink raw reply related
* [PATCH V2 0/9] qtnfmac: more info on current channel from device
From: igor.mitsyanko.os @ 2017-09-02 1:44 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, avinashp, johannes
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
This patchset has a goal to start using full current channel information
as reported by wireless device (specifically, center freq 1 and 2 and
operational BW).
It was part of bigger changeset when it was V1.
Changelist V1->V2:
PATCH 2:
- do not rename "chandef" local variable with no purpose
- report secondary center frequency in info messages
PATCH 3:
- report secondary center frequency in info messages
Igor Mitsyanko (9):
qtnfmac: qlink: convert channel width from bitfiled to simple enum
qtnfmac: make "Channel change" event report full channel info
qtnfmac: retrieve current channel info from EP
qtnfmac: do not cache channel info from "connect" command
qtnfmac: let wifi card handle channel switch request to the same chan
qtnfmac: pass VIF info to SendChannel command
qtnfmac: do not cache CSA chandef info
qtnfmac: remove unused mac::status field
qtnfmac: do not report channel changes until wiphy is registered
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 69 +++++-----------------
drivers/net/wireless/quantenna/qtnfmac/commands.c | 52 +++++++++++++---
drivers/net/wireless/quantenna/qtnfmac/commands.h | 3 +-
drivers/net/wireless/quantenna/qtnfmac/core.h | 6 --
drivers/net/wireless/quantenna/qtnfmac/event.c | 34 ++++-------
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 45 ++++++++++----
.../net/wireless/quantenna/qtnfmac/qlink_util.c | 68 ++++++++++++++++++---
.../net/wireless/quantenna/qtnfmac/qlink_util.h | 4 ++
8 files changed, 175 insertions(+), 106 deletions(-)
--
2.9.5
^ permalink raw reply
* Re: [v3,1/2] ath10k: add the PCI PM core suspend/resume ops
From: Ryan Hsu @ 2017-09-01 23:13 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <f4652c401e1f462d89b4611afe9bd623@euamsexm01a.eu.qualcomm.com>
T24gMDgvMzEvMjAxNyAwNTo1MiBBTSwgS2FsbGUgVmFsbyB3cm90ZToNCg0KPiBUaGlzIGhhZCBh
IHdhcm5pbmc6DQo+DQo+IGRyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9hdGgxMGsvcGNpLmM6MzY1
MToxOiB3YXJuaW5nOiBzeW1ib2wgJ2F0aDEwa19wY2lfcG1fb3BzJyB3YXMgbm90IGRlY2xhcmVk
LiBTaG91bGQgaXQgYmUgc3RhdGljPw0KPg0KPiBJIGZpeGVkIGl0IGluIHRoZSBwZW5kaW5nIGJy
YW5jaCBieSBtYWtpbmcgaXQgc3RhdGljOg0KPg0KPiBzdGF0aWMgU0lNUExFX0RFVl9QTV9PUFMo
YXRoMTBrX3BjaV9wbV9vcHMsDQo+IAkJCSBhdGgxMGtfcGNpX3BtX3N1c3BlbmQsDQo+IAkJCSBh
dGgxMGtfcGNpX3BtX3Jlc3VtZSk7DQo+DQo+IFBsZWFzZSByZXZpZXcuDQo+DQoNClllcyBhbmQg
dGhhbmtzIQ0KDQotLSANClJ5YW4gSHN1DQo=
^ permalink raw reply
* Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
From: Arend van Spriel @ 2017-09-01 22:01 UTC (permalink / raw)
To: Rob Herring
Cc: Antony Antony, Chen-Yu Tsai, Kalle Valo, Mark Rutland,
Icenowy Zheng, devicetree, Hans de Goede, linux-wireless,
Maxime Ripard
In-Reply-To: <CAL_JsqLsnXYfyix3KLkEYguWAe-Wqcb9Nd22jM8HM2dnw4Frog@mail.gmail.com>
On 01-09-17 23:38, Rob Herring wrote:
> On Fri, Sep 1, 2017 at 2:10 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 01-09-17 18:49, Rob Herring wrote:
>>>
>>> On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
>>>>
>>>> hi,
>>>>
>>>> On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
>>>>>
>>>>> On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@phenome.org>
>>>>> wrote:
>>>>
>>>>
>>>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>>> +++
>>>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>>> @@ -6,7 +6,9 @@ connects the device to the system.
>>>>>>
>>>>>> Required properties:
>>>>>>
>>>>>> - - compatible : Should be "brcm,bcm4329-fmac".
>>>>>> + - compatible : should be one of the following:
>>>>>> + * "brcm,bcm4329-fmac"
>>>>>> + * "brcm,bcm43430-fmac"
>>>>>
>>>>>
>>>>> You updated the bindings, but not the driver. So it's not actually
>>>>> going to work. More specifically, OOB interrupts won't work.
>>>>>
>>>>
>>>> understood, ignore this patch for now. Thanks Chen-Yu.
>>>>
>>>>> IIRC, The compatible string for this particular case, as it was
>>>>> originally proposed, only serves as a placeholder for the driver
>>>>> to check against. None of the instances in sunxi device trees
>>>>> match the actual chip model. Actual model matching is done
>>>>> through SDIO, as you've already seen.
>>>>
>>>>
>>>> yes it seems SDIO driveer code is smarter, once it initialize
>>>> brcm,bcm4329-fmac it ignore the DT info and read the chip details to
>>>> locate
>>>> firmware file.
>>>>
>>>> I also noticed other boards using bcm4329-fmac in similar situations.
>>>> https://patchwork.kernel.org/patch/9739181/
>>>>
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
>>>>
>>>> I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see
>>>> where
>>>> it goes.
>>>
>>>
>>> Adding the compatible or instead of? The former would be better. You
>>> should still have the actual chip in case you do have some difference to
>>> handle.
>>
>>
>> Hi Rob,
>>
>> Actually the Broadcom wifi chips themselves are discoverable. So once the
>> driver has access to the register space of the device it can determine the
>> actual chip, its revision, and exactly what cores (and their revision) are
>> present in the chip. Hence there is a single compatible string as there is
>> no need to convey the same information through device tree data.
>
> So if a chip has different power on/off sequencing you can discover that?
>
> I realize that most often you don't need it, but a more specific
> compatible is there in case you do and so it doesn't require a DTB
> update to handle some difference. But you can keep using one
> compatible because I can't really enforce any of that.
For SDIO chips the power sequencing is defined by power-seq-* in
bindings/mmc and handled by the MMC stack itself. So the wifi driver is
not dealing with that.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
From: Rob Herring @ 2017-09-01 21:38 UTC (permalink / raw)
To: Arend van Spriel
Cc: Antony Antony, Chen-Yu Tsai, Kalle Valo, Mark Rutland,
Icenowy Zheng, devicetree, Hans de Goede, linux-wireless,
Maxime Ripard
In-Reply-To: <bb53a79e-8045-3c9b-8c98-8d4815c3b57a@broadcom.com>
On Fri, Sep 1, 2017 at 2:10 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 01-09-17 18:49, Rob Herring wrote:
>>
>> On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
>>>
>>> hi,
>>>
>>> On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
>>>>
>>>> On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@phenome.org>
>>>> wrote:
>>>
>>>
>>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>> +++
>>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>> @@ -6,7 +6,9 @@ connects the device to the system.
>>>>>
>>>>> Required properties:
>>>>>
>>>>> - - compatible : Should be "brcm,bcm4329-fmac".
>>>>> + - compatible : should be one of the following:
>>>>> + * "brcm,bcm4329-fmac"
>>>>> + * "brcm,bcm43430-fmac"
>>>>
>>>>
>>>> You updated the bindings, but not the driver. So it's not actually
>>>> going to work. More specifically, OOB interrupts won't work.
>>>>
>>>
>>> understood, ignore this patch for now. Thanks Chen-Yu.
>>>
>>>> IIRC, The compatible string for this particular case, as it was
>>>> originally proposed, only serves as a placeholder for the driver
>>>> to check against. None of the instances in sunxi device trees
>>>> match the actual chip model. Actual model matching is done
>>>> through SDIO, as you've already seen.
>>>
>>>
>>> yes it seems SDIO driveer code is smarter, once it initialize
>>> brcm,bcm4329-fmac it ignore the DT info and read the chip details to
>>> locate
>>> firmware file.
>>>
>>> I also noticed other boards using bcm4329-fmac in similar situations.
>>> https://patchwork.kernel.org/patch/9739181/
>>>
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
>>>
>>> I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see
>>> where
>>> it goes.
>>
>>
>> Adding the compatible or instead of? The former would be better. You
>> should still have the actual chip in case you do have some difference to
>> handle.
>
>
> Hi Rob,
>
> Actually the Broadcom wifi chips themselves are discoverable. So once the
> driver has access to the register space of the device it can determine the
> actual chip, its revision, and exactly what cores (and their revision) are
> present in the chip. Hence there is a single compatible string as there is
> no need to convey the same information through device tree data.
So if a chip has different power on/off sequencing you can discover that?
I realize that most often you don't need it, but a more specific
compatible is there in case you do and so it doesn't require a DTB
update to handle some difference. But you can keep using one
compatible because I can't really enforce any of that.
Rob
^ 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