Re: Troubleshooting mwl8k driver issue
On Mon, Jun 06, 2016 at 09:51:46AM +0300, Lennert Buytenhek wrote: > There's a bunch of bad-looking stuff in the posted dmesgs, such as: > > [ 10.983657] pci :00:01.0: enabling device (0140 -> 0142) > [ 11.972069] ieee80211 phy0: Command RF_ANTENNA error 0x2 > [ 11.977455] ieee80211 phy0: failed to set # of RX antennas > [ 11.993318] ieee80211 phy0: Command RF_ANTENNA error 0x2 > [ 11.998713] ieee80211 phy0: failed to set # of TX antennas > [ 12.004243] ieee80211 phy0: 88w8366 v48, c8d719177244, STA firmware 4.1.0.3 > > And: > > [ 22.517451] :02:00.0: unable to load firmware helper image > [ 22.523399] ieee80211 phy1: Cannot start firmware > [ 22.528230] ieee80211 phy1: Trying to reload the firmware again > [ 23.016669] ieee80211 phy1: 88w8366 v7, c8d719177246, AP firmware 5.2.8.17 I've attached my startup dmesg output, I am seeing some of those messages. > Is the behavior consistent per device across boots? I.e. does device > X always work on every boot while device Y never works at all? Yes. > For starters, could you post lspci -n output? 00:01.0 0604: 11ab:6282 (rev 01) 00:02.0 0604: 11ab:6282 (rev 01) 01:00.0 0200: 11ab:2a41 02:00.0 0200: 11ab:2a42 > Also, do you see the same behavior with older kernels, or have you > only tried 4.4? I saw it on kernel 3.18 as well. As an aside I semi-bricked my router and I'm currently unable to flash new images - unfortunate, as I prepped an OpenWRT build with debug logging. I feel committed to seeing this through though so I have another device ordered but I will be unable to test new builds until it gets here in a week or so. -- David Gilman :DG< http://gilslotd.com [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.4.7 (openwrt@0e997fc2ad25) (gcc version 5.3.0 (OpenWrt GCC 5.3.0 r49377) ) #1 Sun May 22 08:20:37 UTC 2016 [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine model: Linksys EA3500 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 16384 [0.00] free_area_init_node: node 0, pgdat c057d838, node_mem_map c3f7a000 [0.00] Normal zone: 128 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 16384 pages, LIFO batch:3 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: console=ttyS0,115200 mtdparts=nand_mtd:512k(uboot)ro,16k@512k(u_env),16k@528k(s_env),20m@2m(kernel),20m@2m(rootfs)fs,20m@22m(alt_kernel),20m@22m(alt_rootfs)fs,22m@42m(syscfg) root=/dev/mtdblock6 ro rootfstype=jffs2 serial_number=12C10606503967 uuid=9E782CBBA2A839EF4B650308C7E22720 hw_version=RGWM-C5_0GA device_mac=C0:56:27:BA:65:BD factory_date=2015/06/24 wps_pin=74717897 [0.00] PID hash table entries: 256 (order: -2, 1024 bytes) [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Memory: 58956K/65536K available (3946K kernel code, 135K rwdata, 1444K rodata, 168K init, 197K bss, 6580K reserved, 0K cma-reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xc480 - 0xff80 ( 944 MB) [0.00] lowmem : 0xc000 - 0xc400 ( 64 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc054bdc4 (5392 kB) [0.00] .init : 0xc054c000 - 0xc0576000 ( 168 kB) [0.00] .data : 0xc0576000 - 0xc0597fac ( 136 kB) [0.00].bss : 0xc0597fac - 0xc05c959c ( 198 kB) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] clocksource: orion_clocksource: mask: 0x max_cycles: 0x, max_idle_ns: 9556302233 ns [0.10] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns [0.98] Calibrating delay loop... 795.44 BogoMIPS (lpj=3977216) [0.040090] pid_max: default: 32768 minimum: 301 [0.040217] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.040238] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.040825] CPU: Testing write buffer coherency: ok [0.041209] Setting up static identity map for 0x81e0 - 0x821c [0.041558] mvebu-soc-id: MVEBU SoC ID=0x6282, Rev=0x1 [0.047290] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.047429] pinctrl core: initialized pinctrl subsystem [0.048746] NET: Registered protocol family 16 [0.049248] DMA: prealloca
[PATCH] wlcore: sdio: Fix crash on wlcore_probe_of when failing to parse/map irq
pdev_data pointer is being freed with kfree but the pointer is not dynamic
allocated.
Signed-off-by: Bruno Herrera
---
drivers/net/wireless/ti/wlcore/sdio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index c172da5..5839acb 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -241,7 +241,6 @@ static int wlcore_probe_of(struct device *dev, int *irq,
*irq = irq_of_parse_and_map(np, 0);
if (!*irq) {
dev_err(dev, "No irq in platform data\n");
- kfree(pdev_data);
return -EINVAL;
}
--
2.7.4 (Apple Git-66)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Any reason to allow MGT TID to be paused by power-save?
I'm trying to track down a tricky problem with a Mac book and power save with my ath10k firmware. At least part of the issue is that when the Mac sleeps, it goes into power-save state as far as AP is concerned, and then it simply turns itself off. When it wakes up a short time later, it then tries to scan and re-associate. But, if hostapd hasn't timed out the station (due to longer idle timer), then STA still is treated as being in power-save in the firmware. It appears that this causes mgt-frames (probe responses) not be sent back out of the firmware, so Mac gives up fairly quickly. I fixed at least some of this by forcing a power-save wake on receipt of probe requests and auth requests, but some issues remain for one reason or another. One thing that came to mind: Is it *ever* a good idea to pause a mgt-tid due to power-save? A second non-pausable TID also exists in the firmware...maybe all mgt frames should use that? But if so, then why have a mgt tid at all? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86: Add early quirk to reset Apple AirPort card
On Sun, May 29, 2016 at 01:35:28AM +0200, Lukas Wunner wrote: > The EFI firmware on Macs contains a full-fledged network stack for > downloading OS X images from osrecovery.apple.com. Unfortunately > on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331 > wireless card on every boot and leaves it enabled even after > ExitBootServices has been called. The card continues to assert its IRQ > line, causing spurious interrupts if the IRQ is shared. It also corrupts > memory by DMAing received packets, allowing for remote code execution > over the air. This only stops when a driver is loaded for the wireless > card, which may be never if the driver is not installed or blacklisted. > ... > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301 > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781 > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916 > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16 > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819 > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621 > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5 > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130 > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732 I think I saw mail about this being applied via the x86 tree. Let me know if I need to do anything more here. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4.2.y-ckt 029/206] ath9k: Add a module parameter to invert LED polarity.
4.2.8-ckt12 -stable review patch. If anyone has any objections, please let me know. ---8< From: "Vittorio Gambaletta (VittGam)" commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream. The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Kamal Mostafa --- drivers/net/wireless/ath/ath9k/init.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index fc6dc52..6a571d8 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -49,6 +49,10 @@ int ath9k_led_blink; module_param_named(blink, ath9k_led_blink, int, 0444); MODULE_PARM_DESC(blink, "Enable LED blink on activity"); +static int ath9k_led_active_high = -1; +module_param_named(led_active_high, ath9k_led_active_high, int, 0444); +MODULE_PARM_DESC(led_active_high, "Invert LED polarity"); + static int ath9k_btcoex_enable; module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444); MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence"); @@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, if (ret) return ret; + if (ath9k_led_active_high != -1) + ah->config.led_active_high = ath9k_led_active_high == 1; + /* * Enable WLAN/BT RX Antenna diversity only when: * -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4.2.y-ckt 030/206] ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
4.2.8-ckt12 -stable review patch. If anyone has any objections, please let me
know.
---8<
From: "Vittorio Gambaletta (VittGam)"
commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream.
The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
(active high instead of active low).
The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.
Cc:
Cc:
Cc:
Signed-off-by: Vittorio Gambaletta
Signed-off-by: Kalle Valo
Signed-off-by: Kamal Mostafa
---
drivers/net/wireless/ath/ath9k/pci.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c
b/drivers/net/wireless/ath/ath9k/pci.c
index e6fef1b..7cdaf40 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -28,6 +28,16 @@ static const struct pci_device_id ath_pci_id_table[] = {
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */
{ PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
+
+#ifdef CONFIG_ATH9K_PCOEM
+ /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+0x0029,
+PCI_VENDOR_ID_ATHEROS,
+0x2096),
+ .driver_data = ATH9K_PCI_LED_ACT_HI },
+#endif
+
{ PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
#ifdef CONFIG_ATH9K_PCOEM
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] brcmfmac: rework function picking free BSS index
On 26-05-16 01:44, Rafał Miłecki wrote:
> The old implementation was overcomplicated and slightly bugged in some
> corner cases.
>
> Consider following state of BSS-es (limited to 6 for simplification):
> drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
> drvr->iflist[1]: (null)
> drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }
> drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, }
> drvr->iflist[4]: (null)
> drvr->iflist[5]: (null)
> In such case the next AP interface should bsscfgidx 4 (we don't use 1 as
> it's reserved for P2P).
>
> With old code the loop iterations were following:
> [ifidx = 0] [bsscfgidx = 2] [highest = 2]
> [ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true
> [ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1
> [ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1
> [ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true
> [ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true
> There were 2 obvious problems:
> 1) Having empty BSS at index 1 was resulting in available being always
>set to true, even if we would run out of BSS-es.
> 2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver
>not being able to create the 4th AP interface.
>
> New code is simpler, placed in file where it's really used, handles
> running out of free BSS-es and allows using 4 interfaces at the same
> time. It also looks for the first free BSS instead of one after the last
> in use. It works well with current driver (which doesn't allow deleting
> interfaces) and should be future proof (if we ever allow deleting).
>
> Signed-off-by: Rafał Miłecki
> ---
> .../broadcom/brcm80211/brcmfmac/cfg80211.c | 17 ++-
> .../wireless/broadcom/brcm80211/brcmfmac/core.c| 24
> --
> .../wireless/broadcom/brcm80211/brcmfmac/core.h| 1 -
> 3 files changed, 16 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 3d09d23..d00eef8 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -541,6 +541,21 @@ brcmf_cfg80211_update_proto_addr_mode(struct
> wireless_dev *wdev)
> ADDR_INDIRECT);
> }
>
> +static int brcmf_get_first_free_bsscfgidx(struct brcmf_pub *drvr)
> +{
> + int bsscfgidx;
> +
> + for (bsscfgidx = 0; bsscfgidx < BRCMF_MAX_IFS; bsscfgidx++) {
> + /* bsscfgidx 1 is reserved for legacy P2P */
Hi Rafał,
A bit late as the patch is already applied, but this reserved index is
no longer needed as we removed all trickery that was build on the
assumption that the P2P_DEVICE interface was always in bsscfgidx 1.
Hence this could be removed.
Regards,
Arend
> + if (bsscfgidx == 1)
> + continue;
> + if (!drvr->iflist[bsscfgidx])
> + return bsscfgidx;
> + }
> +
> + return -ENOMEM;
> +}
> +
> static int brcmf_cfg80211_request_ap_if(struct brcmf_if *ifp)
> {
> struct brcmf_mbss_ssid_le mbss_ssid_le;
> @@ -548,7 +563,7 @@ static int brcmf_cfg80211_request_ap_if(struct brcmf_if
> *ifp)
> int err;
>
> memset(&mbss_ssid_le, 0, sizeof(mbss_ssid_le));
> - bsscfgidx = brcmf_get_next_free_bsscfgidx(ifp->drvr);
> + bsscfgidx = brcmf_get_first_free_bsscfgidx(ifp->drvr);
> if (bsscfgidx < 0)
> return bsscfgidx;
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index b590499..6a76480 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -753,30 +753,6 @@ void brcmf_remove_interface(struct brcmf_if *ifp)
> brcmf_del_if(ifp->drvr, ifp->bsscfgidx);
> }
>
> -int brcmf_get_next_free_bsscfgidx(struct brcmf_pub *drvr)
> -{
> - int ifidx;
> - int bsscfgidx;
> - bool available;
> - int highest;
> -
> - available = false;
> - bsscfgidx = 2;
> - highest = 2;
> - for (ifidx = 0; ifidx < BRCMF_MAX_IFS; ifidx++) {
> - if (drvr->iflist[ifidx]) {
> - if (drvr->iflist[ifidx]->bsscfgidx == bsscfgidx)
> - bsscfgidx = highest + 1;
> - else if (drvr->iflist[ifidx]->bsscfgidx > highest)
> - highest = drvr->iflist[ifidx]->bsscfgidx;
> - } else {
> - available = true;
> - }
> - }
> -
> - return available ? bsscfgidx : -ENOMEM;
> -}
> -
> #ifdef CONFIG_INET
> #define ARPOL_MAX_ENTRIES8
> static int brcmf_inetaddr_changed(struct notifier_block *nb,
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> b/drivers/net/wireless/broadcom/brc
Re: [PATCH] brcmfmac: slightly simplify building interface combinations
On 07-06-16 21:10, Rafał Miłecki wrote:
> This change reorders some operations in brcmf_setup_ifmodes in hope to
> make it simpler:
> 1) It allocates arrays right before filling them. This way it's easier
>to follow requested array length as it's immediately followed by
>code filling it. It's easier to check e.g. why we need 4 entries for
>P2P. Other than that it deduplicates some checks (e.g. for P2P).
> 2) It reorders code to first prepare limits and then define a new combo.
>Previously this was mixed (e.g. we were setting num of channels
>before preparing limits).
> 3) It modifies mbss code to use i variable just like other combos do.
Acked-by: Arend van Spriel
> Signed-off-by: Rafał Miłecki
> ---
> .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37
> ++
> 1 file changed, 16 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 4894eb7..33e682e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6300,29 +6300,15 @@ static int brcmf_setup_ifmodes(struct wiphy *wiphy,
> struct brcmf_if *ifp)
> if (!combo)
> goto err;
>
> - c0_limits = kcalloc(p2p ? 3 : 2, sizeof(*c0_limits), GFP_KERNEL);
> - if (!c0_limits)
> - goto err;
> -
> - if (p2p) {
> - p2p_limits = kcalloc(4, sizeof(*p2p_limits), GFP_KERNEL);
> - if (!p2p_limits)
> - goto err;
> - }
> -
> - if (mbss) {
> - mbss_limits = kcalloc(1, sizeof(*mbss_limits), GFP_KERNEL);
> - if (!mbss_limits)
> - goto err;
> - }
> -
> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
>BIT(NL80211_IFTYPE_ADHOC) |
>BIT(NL80211_IFTYPE_AP);
>
> c = 0;
> i = 0;
> - combo[c].num_different_channels = 1;
> + c0_limits = kcalloc(p2p ? 3 : 2, sizeof(*c0_limits), GFP_KERNEL);
> + if (!c0_limits)
> + goto err;
> c0_limits[i].max = 1;
> c0_limits[i++].types = BIT(NL80211_IFTYPE_STATION);
> if (p2p) {
> @@ -6340,6 +6326,7 @@ static int brcmf_setup_ifmodes(struct wiphy *wiphy,
> struct brcmf_if *ifp)
> c0_limits[i].max = 1;
> c0_limits[i++].types = BIT(NL80211_IFTYPE_AP);
> }
> + combo[c].num_different_channels = 1;
> combo[c].max_interfaces = i;
> combo[c].n_limits = i;
> combo[c].limits = c0_limits;
> @@ -6347,7 +6334,9 @@ static int brcmf_setup_ifmodes(struct wiphy *wiphy,
> struct brcmf_if *ifp)
> if (p2p) {
> c++;
> i = 0;
> - combo[c].num_different_channels = 1;
> + p2p_limits = kcalloc(4, sizeof(*p2p_limits), GFP_KERNEL);
> + if (!p2p_limits)
> + goto err;
> p2p_limits[i].max = 1;
> p2p_limits[i++].types = BIT(NL80211_IFTYPE_STATION);
> p2p_limits[i].max = 1;
> @@ -6356,6 +6345,7 @@ static int brcmf_setup_ifmodes(struct wiphy *wiphy,
> struct brcmf_if *ifp)
> p2p_limits[i++].types = BIT(NL80211_IFTYPE_P2P_CLIENT);
> p2p_limits[i].max = 1;
> p2p_limits[i++].types = BIT(NL80211_IFTYPE_P2P_DEVICE);
> + combo[c].num_different_channels = 1;
> combo[c].max_interfaces = i;
> combo[c].n_limits = i;
> combo[c].limits = p2p_limits;
> @@ -6363,14 +6353,19 @@ static int brcmf_setup_ifmodes(struct wiphy *wiphy,
> struct brcmf_if *ifp)
>
> if (mbss) {
> c++;
> + i = 0;
> + mbss_limits = kcalloc(1, sizeof(*mbss_limits), GFP_KERNEL);
> + if (!mbss_limits)
> + goto err;
> + mbss_limits[i].max = 4;
> + mbss_limits[i++].types = BIT(NL80211_IFTYPE_AP);
> combo[c].beacon_int_infra_match = true;
> combo[c].num_different_channels = 1;
> - mbss_limits[0].max = 4;
> - mbss_limits[0].types = BIT(NL80211_IFTYPE_AP);
> combo[c].max_interfaces = 4;
> - combo[c].n_limits = 1;
> + combo[c].n_limits = i;
> combo[c].limits = mbss_limits;
> }
> +
> wiphy->n_iface_combinations = n_combos;
> wiphy->iface_combinations = combo;
> return 0;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull-request: mac80211 2016-06-09
From: Johannes Berg Date: Thu, 9 Jun 2016 14:47:57 +0200 > Here are two more fixes for the current cycle, please pull. Pulled, thanks Johannes. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] rtl8xxxu bugfix and minor updates
From: Jes Sorensen Hi, A couple of simple patches from my current queue. The most important one is from Colin Ian King fixing the use of a wrong variable. That one should probably go into v4.7. The others are fine for the next round. Cheers, Jes Andy Shevchenko (1): rtl8xxxu: tuse %*ph to dump buffers Colin Ian King (1): rtl8xxxu: fix typo on variable name, compare against correct variable Jes Sorensen (2): rtl8xxxu: Add bit definitions for REG_USB_SPECIAL_OPTION rtl8xxxu: Add additional documentation for RX DMA registers drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 9 ++--- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 11 +++ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 ++--- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 14 +++--- 4 files changed, 18 insertions(+), 25 deletions(-) -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] rtl8xxxu: fix typo on variable name, compare against correct variable
From: Colin Ian King
path_b_ok is being assigned but immediately after path_a_ok is being
compared to the value 0x03. This appears to be a typo on the
variable name, compare path_b_ok instead.
Signed-off-by: Colin Ian King
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index 65c079a..5b825fa 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1144,7 +1144,7 @@ static void rtl8192eu_phy_iqcalibrate(struct
rtl8xxxu_priv *priv,
for (i = 0; i < retry; i++) {
path_b_ok = rtl8192eu_rx_iqk_path_b(priv);
- if (path_a_ok == 0x03) {
+ if (path_b_ok == 0x03) {
val32 = rtl8xxxu_read32(priv,
REG_RX_POWER_BEFORE_IQK_B_2);
result[t][6] = (val32 >> 16) & 0x3ff;
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] rtl8xxxu: tuse %*ph to dump buffers
From: Andy Shevchenko
Use %*ph specifier to dump small buffers in hex format instead of doing this
byte-by-byte.
Signed-off-by: Andy Shevchenko
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 9 ++---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 9 ++---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 ++---
3 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
index 2c86b55..eefb7ca 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
@@ -413,13 +413,8 @@ static int rtl8192cu_parse_efuse(struct rtl8xxxu_priv
*priv)
dev_info(&priv->udev->dev,
"%s: dumping efuse (0x%02zx bytes):\n",
__func__, sizeof(struct rtl8192cu_efuse));
- for (i = 0; i < sizeof(struct rtl8192cu_efuse); i += 8) {
- dev_info(&priv->udev->dev, "%02x: "
-"%02x %02x %02x %02x %02x %02x %02x %02x\n", i,
-raw[i], raw[i + 1], raw[i + 2],
-raw[i + 3], raw[i + 4], raw[i + 5],
-raw[i + 6], raw[i + 7]);
- }
+ for (i = 0; i < sizeof(struct rtl8192cu_efuse); i += 8)
+ dev_info(&priv->udev->dev, "%02x: %8ph\n", i, &raw[i]);
}
return 0;
}
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index fe19ace..65c079a 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -622,13 +622,8 @@ static int rtl8192eu_parse_efuse(struct rtl8xxxu_priv
*priv)
dev_info(&priv->udev->dev,
"%s: dumping efuse (0x%02zx bytes):\n",
__func__, sizeof(struct rtl8192eu_efuse));
- for (i = 0; i < sizeof(struct rtl8192eu_efuse); i += 8) {
- dev_info(&priv->udev->dev, "%02x: "
-"%02x %02x %02x %02x %02x %02x %02x %02x\n", i,
-raw[i], raw[i + 1], raw[i + 2],
-raw[i + 3], raw[i + 4], raw[i + 5],
-raw[i + 6], raw[i + 7]);
- }
+ for (i = 0; i < sizeof(struct rtl8192eu_efuse); i += 8)
+ dev_info(&priv->udev->dev, "%02x: %8ph\n", i, &raw[i]);
}
return 0;
}
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 4186e7c..9d45afb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -466,13 +466,8 @@ static int rtl8723bu_parse_efuse(struct rtl8xxxu_priv
*priv)
dev_info(&priv->udev->dev,
"%s: dumping efuse (0x%02zx bytes):\n",
__func__, sizeof(struct rtl8723bu_efuse));
- for (i = 0; i < sizeof(struct rtl8723bu_efuse); i += 8) {
- dev_info(&priv->udev->dev, "%02x: "
-"%02x %02x %02x %02x %02x %02x %02x %02x\n", i,
-raw[i], raw[i + 1], raw[i + 2],
-raw[i + 3], raw[i + 4], raw[i + 5],
-raw[i + 6], raw[i + 7]);
- }
+ for (i = 0; i < sizeof(struct rtl8723bu_efuse); i += 8)
+ dev_info(&priv->udev->dev, "%02x: %8ph\n", i, &raw[i]);
}
return 0;
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] rtl8xxxu: Add additional documentation for RX DMA registers
From: Jes Sorensen
This also renames REG_USB_AGG_{TO,TH} to REG_USB_AGG_{TIMEOUT,THRESH}
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
index bff883c..921c565 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
@@ -405,7 +405,11 @@
#define REG_DWBCN1_CTRL_8723B 0x0228
/* 0x0280 ~ 0x02FF RXDMA Configuration */
-#define REG_RXDMA_AGG_PG_TH0x0280
+#define REG_RXDMA_AGG_PG_TH0x0280 /* 0-7 : USB DMA size bits
+ 8-14: USB DMA timeout
+ 15 : Aggregation enable
+Only seems to be used
+on 8723bu/8192eu */
#define RXDMA_USB_AGG_ENABLE BIT(31)
#define REG_RXPKT_NUM 0x0284
#define RXPKT_NUM_RXDMA_IDLE BIT(17)
@@ -1058,8 +1062,8 @@
0: Use int, 1: use bulk */
#define REG_USB_HRPWM 0xfe58
#define REG_USB_DMA_AGG_TO 0xfe5b
-#define REG_USB_AGG_TO 0xfe5c
-#define REG_USB_AGG_TH 0xfe5d
+#define REG_USB_AGG_TIMEOUT0xfe5c
+#define REG_USB_AGG_THRESH 0xfe5d
#define REG_NORMAL_SIE_VID 0xfe60 /* 0xfe60 - 0xfe61 */
#define REG_NORMAL_SIE_PID 0xfe62 /* 0xfe62 - 0xfe63 */
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] rtl8xxxu: Add bit definitions for REG_USB_SPECIAL_OPTION
From: Jes Sorensen Documentation for enabling USB aggregation and whether to select interrupt or bulk delivery of interrupt events. Signed-off-by: Jes Sorensen --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h index b0e0c64..bff883c 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h @@ -1052,6 +1052,10 @@ #define USB_HIMR_ROK BIT(0) /* Receive DMA OK Interrupt */ #define REG_USB_SPECIAL_OPTION 0xfe55 +#define USB_SPEC_USB_AGG_ENABLE BIT(3) /* Enable USB aggregation */ +#define USB_SPEC_INT_BULK_SELECT BIT(4) /* Use interrupt endpoint to + deliver interrupt packet. + 0: Use int, 1: use bulk */ #define REG_USB_HRPWM 0xfe58 #define REG_USB_DMA_AGG_TO 0xfe5b #define REG_USB_AGG_TO 0xfe5c -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcmfmac: rework function picking free BSS index
On 9 June 2016 at 18:30, Kalle Valo wrote:
> Kalle Valo writes:
>
>> Rafał Miłecki wrote:
>>> The old implementation was overcomplicated and slightly bugged in some
>>> corner cases.
>>>
>>> Consider following state of BSS-es (limited to 6 for simplification):
>>> drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
>>> drvr->iflist[1]: (null)
>>> drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }
>>> drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, }
>>> drvr->iflist[4]: (null)
>>> drvr->iflist[5]: (null)
>>> In such case the next AP interface should bsscfgidx 4 (we don't use 1 as
>>> it's reserved for P2P).
>>>
>>> With old code the loop iterations were following:
>>> [ifidx = 0] [bsscfgidx = 2] [highest = 2]
>>> [ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true
>>> [ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1
>>> [ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1
>>> [ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true
>>> [ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true
>>> There were 2 obvious problems:
>>> 1) Having empty BSS at index 1 was resulting in available being always
>>>set to true, even if we would run out of BSS-es.
>>> 2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver
>>>not being able to create the 4th AP interface.
>>>
>>> New code is simpler, placed in file where it's really used, handles
>>> running out of free BSS-es and allows using 4 interfaces at the same
>>> time. It also looks for the first free BSS instead of one after the last
>>> in use. It works well with current driver (which doesn't allow deleting
>>> interfaces) and should be future proof (if we ever allow deleting).
>>>
>>> Signed-off-by: Rafał Miłecki
>>
>> Thanks, 1 patch applied to wireless-drivers-next.git:
>>
>> d02fb8f14b2d brcmfmac: rework function picking free BSS index
>
> Now that patchwork.kernel.org is finally updated and I fixed my python
> script, this is the first time I applied a patch using UTF-8 charset
> directly from patchwork. As it's not exactly easy to get UTF-8 support
> right in python, I would very much like to hear if there any issues
> either with the commit below or the email above.
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=d02fb8f14b2d
Look fine, thanks!
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcmfmac: rework function picking free BSS index
Kalle Valo writes:
> Rafał Miłecki wrote:
>> The old implementation was overcomplicated and slightly bugged in some
>> corner cases.
>>
>> Consider following state of BSS-es (limited to 6 for simplification):
>> drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
>> drvr->iflist[1]: (null)
>> drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }
>> drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, }
>> drvr->iflist[4]: (null)
>> drvr->iflist[5]: (null)
>> In such case the next AP interface should bsscfgidx 4 (we don't use 1 as
>> it's reserved for P2P).
>>
>> With old code the loop iterations were following:
>> [ifidx = 0] [bsscfgidx = 2] [highest = 2]
>> [ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true
>> [ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1
>> [ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1
>> [ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true
>> [ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true
>> There were 2 obvious problems:
>> 1) Having empty BSS at index 1 was resulting in available being always
>>set to true, even if we would run out of BSS-es.
>> 2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver
>>not being able to create the 4th AP interface.
>>
>> New code is simpler, placed in file where it's really used, handles
>> running out of free BSS-es and allows using 4 interfaces at the same
>> time. It also looks for the first free BSS instead of one after the last
>> in use. It works well with current driver (which doesn't allow deleting
>> interfaces) and should be future proof (if we ever allow deleting).
>>
>> Signed-off-by: Rafał Miłecki
>
> Thanks, 1 patch applied to wireless-drivers-next.git:
>
> d02fb8f14b2d brcmfmac: rework function picking free BSS index
Now that patchwork.kernel.org is finally updated and I fixed my python
script, this is the first time I applied a patch using UTF-8 charset
directly from patchwork. As it's not exactly easy to get UTF-8 support
right in python, I would very much like to hear if there any issues
either with the commit below or the email above.
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=d02fb8f14b2d
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcmfmac: rework function picking free BSS index
Rafał Miłecki wrote:
> The old implementation was overcomplicated and slightly bugged in some
> corner cases.
>
> Consider following state of BSS-es (limited to 6 for simplification):
> drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
> drvr->iflist[1]: (null)
> drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }
> drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, }
> drvr->iflist[4]: (null)
> drvr->iflist[5]: (null)
> In such case the next AP interface should bsscfgidx 4 (we don't use 1 as
> it's reserved for P2P).
>
> With old code the loop iterations were following:
> [ifidx = 0] [bsscfgidx = 2] [highest = 2]
> [ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true
> [ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1
> [ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1
> [ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true
> [ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true
> There were 2 obvious problems:
> 1) Having empty BSS at index 1 was resulting in available being always
>set to true, even if we would run out of BSS-es.
> 2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver
>not being able to create the 4th AP interface.
>
> New code is simpler, placed in file where it's really used, handles
> running out of free BSS-es and allows using 4 interfaces at the same
> time. It also looks for the first free BSS instead of one after the last
> in use. It works well with current driver (which doesn't allow deleting
> interfaces) and should be future proof (if we ever allow deleting).
>
> Signed-off-by: Rafał Miłecki
Thanks, 1 patch applied to wireless-drivers-next.git:
d02fb8f14b2d brcmfmac: rework function picking free BSS index
--
Sent by pwcli
https://patchwork.kernel.org/patch/9136421/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/2] mmc: API for accessing host supported maximum segment count and size
Hi Shawn,
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Wednesday, June 08, 2016 7:31 AM
> To: Amitkumar Karwar; linux-wireless@vger.kernel.org
> Cc: Nishant Sarmukadam; Wei-Ning Huang; linux-...@vger.kernel.org; Cathy
> Luo; Xinming Hu; shawn@rock-chips.com
> Subject: Re: [PATCH v3 1/2] mmc: API for accessing host supported
> maximum segment count and size
>
> Hi
>
> On 2016-6-6 19:53, Amitkumar Karwar wrote:
> > From: Xinming Hu
> >
> > sdio device drivers need be able to get the host supported max_segs
> > and max_seg_size, so that they know the buffer size to allocate while
> > utilizing the scatter/gather DMA buffer list.
> >
> > This patch provides API for this purpose.
> >
> > Signed-off-by: Xinming Hu
> > Signed-off-by: Amitkumar Karwar
> > ---
> > v2: v2 was submitted with minor improvement like replacing BUG_ON()
> > with WARN_ON()
> > v3: Addressed below review comments from Ulf Hansson
> > a) In v3, patch has been split into two separate patches.
> > b) Patch 1/2 introduces an API to fetch max_seg_size and max_segs
> > c) Replaced WARN_ON() with proper error code when sg_ptr->length
> is invalid
> > d) Instead of duplicating the code in mmc_io_rw_extended(), extra
> bool parameter
> > has been added to this function and used it in new APIs for
> SG.
> > ---
> > drivers/mmc/core/sdio_io.c | 27
> ++
> > .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 6 ++---
> > include/linux/mmc/sdio_func.h | 3 +++
> > 3 files changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> > index 78cb4d5..a546c89 100644
> > --- a/drivers/mmc/core/sdio_io.c
> > +++ b/drivers/mmc/core/sdio_io.c
> > @@ -720,3 +720,30 @@ int sdio_set_host_pm_flags(struct sdio_func
> *func, mmc_pm_flag_t flags)
> > return 0;
> > }
> > EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
> > +
> > +/**
> > + * sdio_get_host_max_seg_size - get host maximum segment size
> > + * @func: SDIO function attached to host
> > + */
> > +unsigned int sdio_get_host_max_seg_size(struct sdio_func *func) {
> > + WARN_ON(!func);
> > + WARN_ON(!func->card);
> > +
> > + return func->card->host->max_seg_size; }
> > +EXPORT_SYMBOL_GPL(sdio_get_host_max_seg_size);
> > +
> > +/**
> > + * sdio_get_host_max_seg_count - get host maximum segment count
> > + * @func: SDIO function attached to host
> > + */
> > +unsigned short sdio_get_host_max_seg_count(struct sdio_func *func) {
> > + WARN_ON(!func);
> > + WARN_ON(!func->card);
> > +
>
> I believe these two WARN_ON may be called too late because ...
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>
> void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiodev)
>
> func = sdiodev->func[2];
> host = func->card->host;
>
> you have unconditionally thought it should be ready.
>
Yes. The WARN_ONs in this patch are redundant. We will remove them and submit
updated version.
Below is the function call flow.
brcmf_sdio_probe() -> brcmf_sdio_probe_attach() -> brcmf_sdiod_sgtable_alloc()
Looks like is sdiodev->func[2] is ready in brcmf_sdio_probe() itself.
It contains below line.
bus->blocksize = bus->sdiodev->func[2]->cur_blksize;
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ath9k_htc firmware
> Here is one example how you can add new command to firmware: > https://github.com/olerem/open-ath9k-htc-firmware/commit >> /c73c159303e30a28e2d3dc05ba0d2d15504e5fad Thanks for the example. Seems clear as to how it works. Currently I'm looking at anything to do with these tables, which I'll be at it for the next month or so. Going back to the original question I see that the reason that I didn't find very much in terms of traffic on EP0 is that there isn't very much traffic on EP0 so that answers that. Currently the real problem that I'm having is that I can't open a USBLIB FD out in userland while the kernel driver is attached. I can talk to the stick without the driver but while the driver is attached it blocks the access and I would very much like to disable that block. Bruce -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[4.2.y-ckt stable] Patch "ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards." has been added to the 4.2.y-ckt tree
This is a note to let you know that I have just added a patch titled
ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
to the linux-4.2.y-queue branch of the 4.2.y-ckt extended stable tree
which can be found at:
https://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt/log/?h=linux-4.2.y-queue
This patch is scheduled to be released in version 4.2.8-ckt12.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 4.2.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
---8<
>From b2ad7e11502a0c9ac8044b167751ea629fff98db Mon Sep 17 00:00:00 2001
From: "Vittorio Gambaletta (VittGam)"
Date: Mon, 11 Apr 2016 04:48:55 +0200
Subject: ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream.
The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
(active high instead of active low).
The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.
Cc:
Cc:
Cc:
Signed-off-by: Vittorio Gambaletta
Signed-off-by: Kalle Valo
Signed-off-by: Kamal Mostafa
---
drivers/net/wireless/ath/ath9k/pci.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c
b/drivers/net/wireless/ath/ath9k/pci.c
index e6fef1b..7cdaf40 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -28,6 +28,16 @@ static const struct pci_device_id ath_pci_id_table[] = {
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */
{ PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
+
+#ifdef CONFIG_ATH9K_PCOEM
+ /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+0x0029,
+PCI_VENDOR_ID_ATHEROS,
+0x2096),
+ .driver_data = ATH9K_PCI_LED_ACT_HI },
+#endif
+
{ PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
#ifdef CONFIG_ATH9K_PCOEM
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[4.2.y-ckt stable] Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.2.y-ckt tree
This is a note to let you know that I have just added a patch titled ath9k: Add a module parameter to invert LED polarity. to the linux-4.2.y-queue branch of the 4.2.y-ckt extended stable tree which can be found at: https://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt/log/?h=linux-4.2.y-queue This patch is scheduled to be released in version 4.2.8-ckt12. If you, or anyone else, feels it should not be added to this tree, please reply to this email. For more information about the 4.2.y-ckt tree, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable Thanks. -Kamal ---8< >From 3ed74d9334a27b8c8bac6c721c3f484a9a2694a8 Mon Sep 17 00:00:00 2001 From: "Vittorio Gambaletta (VittGam)" Date: Mon, 11 Apr 2016 04:48:54 +0200 Subject: ath9k: Add a module parameter to invert LED polarity. commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream. The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Kamal Mostafa --- drivers/net/wireless/ath/ath9k/init.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index fc6dc52..6a571d8 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -49,6 +49,10 @@ int ath9k_led_blink; module_param_named(blink, ath9k_led_blink, int, 0444); MODULE_PARM_DESC(blink, "Enable LED blink on activity"); +static int ath9k_led_active_high = -1; +module_param_named(led_active_high, ath9k_led_active_high, int, 0444); +MODULE_PARM_DESC(led_active_high, "Invert LED polarity"); + static int ath9k_btcoex_enable; module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444); MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence"); @@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, if (ret) return ret; + if (ath9k_led_active_high != -1) + ah->config.led_active_high = ath9k_led_active_high == 1; + /* * Enable WLAN/BT RX Antenna diversity only when: * -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing
> From: Julian Calaby [mailto:julian.cal...@gmail.com] > Sent: Thursday, June 02, 2016 4:44 AM > To: Javier Martinez Canillas; Xinming Hu > Cc: linux-ker...@vger.kernel.org; Amitkumar Karwar; Kalle Valo; netdev; > linux-wireless; Nishant Sarmukadam > Subject: Re: [PATCH 7/8] mwifiex: don't print an error if an optional DT > property is missing > > Hi Javier, > > On Wed, Jun 1, 2016 at 11:51 PM, Javier Martinez Canillas > wrote: > > Hello Julian, > > > > Thanks a lot for your feedback and reviews. > > > > On 06/01/2016 12:20 AM, Julian Calaby wrote: > >> Hi All, > >> > >> On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas > >> wrote: > >>> The > >>> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT > >>> binding document say that the "interrupts" property in the child > node is optional. So the property being missed shouldn't be treated as > an error. > >> > >> Have you checked whether it is truly optional? I.e. nothing else > >> breaks if this property isn't set? > >> > > > > That's what the DT binding says and the IRQ is only used as a wakeup > > source during system suspend, it is not used during runtime. And that > > is why the > > mwifiex_sdio_probe_of() function does not fail if the IRQ is missing. > > Awesome, that's what I wanted to know. > > > Now, I just got to that conclusion by reading the binding docs, the > > message in the commits that introduced this and the driver code. > > Xinming Hu should comment on how critical this feature is for systems > that needs to be wakeup. > > Xinming, could you review this also? > Yes. IRQ is the optional parameter. System has a flexibility to not use it, but it still can configure other device tree parameters. The patch looks good. Regards, Amitkumar
RE: [PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function
> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com] > Sent: Friday, May 27, 2016 7:48 PM > To: linux-ker...@vger.kernel.org > Cc: Xinming Hu; Javier Martinez Canillas; Amitkumar Karwar; Kalle Valo; > net...@vger.kernel.org; linux-wireless@vger.kernel.org; Nishant > Sarmukadam > Subject: [PATCH 0/8] mwifiex: Fix some error handling issues in > mwifiex_sdio_probe() function > > Hello, > > While booting a system with a mwifiex WiFi card, I noticed the following > missleading error message: > > [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available > > This error only applies to platforms that define a child node for the > SDIO device, but it's currently shown even in platforms that don't have > a child node defined. > > So this series fixes this issue and others I found in the .probe > function (mostly related to error handling and the error path) while > looking at it. > > Best regards, > Javier > > > Javier Martinez Canillas (8): > mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node > mwifiex: propagate sdio_enable_func() errno code in > mwifiex_sdio_probe() > mwifiex: propagate mwifiex_add_card() errno code in > mwifiex_sdio_probe() > mwifiex: consolidate mwifiex_sdio_probe() error paths > mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe() > mwifiex: check if mwifiex_sdio_probe_of() fails and return error > mwifiex: don't print an error if an optional DT property is missing > mwifiex: use better message and error code when OF node doesn't match > > drivers/net/wireless/marvell/mwifiex/sdio.c | 46 ++ > --- > 1 file changed, 28 insertions(+), 18 deletions(-) > Thanks for fixing the error handling code. These patches look fine to me. Acked-by: Amitkumar Karwar Regards, Amitkumar -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: Remove unneccessary WARN_ON_ONCE in rx during ACS
From: Mohammed Shafi Shajakhan
The below warning message seems to hit occasionally with the following
combination (IPQ4019 + ACS scan) where we receive packets as a self peer
when hostapd does ACS when we bring up AP mode . ath10k has the below
fall back mechanism to fetch current operating channel in rx (it will
check for the next channel tracking variable if the current one is NULL)
[scan channel] --> [rx channel] --> [peer channel] -->
[vdev channel] --> [any vdev channel] --> [target oper channel]
'scan channel' and 'target operating channel' are directly fetched from
firmware events. All the others should be updated by mac80211.
During ACS scan we wouldn't have a valid channel context
assigned from mac80211 ('ar->rx_channel'), and also relying on
('ar->scan_channel') is not helpful (it becomes NULL when it goes to
BSS channel and also when the scan event is completed). In short we
cannot always rely on these two channel tracking variables.
'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of
the current operating even while we are doing ACS scan and etc. Hence
remove this un-necessary warning message and continue with
target_operating channel. At the worst case scenario when the target
operating channel is invalid (NULL) we already have an ath10k warning
message to notify we really don't have a proper channel configured in
rx to update the rx status("no channel configured; ignoring frame(s)!")
WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803
[] (warn_slowpath_null) from []
(ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core])
[] (ath10k_htt_rx_h_channel [ath10k_core]) from
[] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core])
[] (ath10k_htt_rx_h_ppdu [ath10k_core]) from
[] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core])
[] (ath10k_htt_txrx_compl_task [ath10k_core])
Fixes:3b0499e9ce42 ("ath10k: reduce warning messages during rx without proper
channel context")
Signed-off-by: Mohammed Shafi Shajakhan
---
[updated commit log - Michal Kazior]
drivers/net/wireless/ath/ath10k/htt_rx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7bf1909..aa44c09 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -748,7 +748,7 @@ ath10k_htt_rx_h_peer_channel(struct ath10k *ar, struct
htt_rx_desc *rxd)
if (WARN_ON_ONCE(!arvif))
return NULL;
- if (WARN_ON_ONCE(ath10k_mac_vif_chan(arvif->vif, &def)))
+ if (ath10k_mac_vif_chan(arvif->vif, &def))
return NULL;
return def.chan;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] mwifiex: fix race condition when downloading firmware
> From: Wei-Ning Huang [mailto:wnhu...@chromium.org]
> Sent: Friday, May 27, 2016 5:58 PM
> To: Linux-Wireless
> Cc: LKML; Amitkumar Karwar; djku...@chromium.org; Wei-Ning Huang
> Subject: [PATCH v2] mwifiex: fix race condition when downloading
> firmware
>
> The action 'check for winner' and 'download firmware' should be an
> atomic action. This is true for btmrvl driver but not mwmfiex, which
> cause firmware download to fail when the following scenario happens:
>
> 1) mwifiex check winner status: true
> 2) btmrvl check winner status: true, and start downloading firmware
> 3) mwifiex tries to download firmware, but failed because btmrvl is
> already downloading.
>
> This won't happen if 1) and 3) is an atomic action. This patch adds
> sdio_claim/release_host call around those two actions to make sure it's
> atomic.
>
> Signed-off-by: Wei-Ning Huang
> ---
> drivers/net/wireless/marvell/mwifiex/init.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c
> b/drivers/net/wireless/marvell/mwifiex/init.c
> index 78c532f..7703438 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -24,6 +24,7 @@
> #include "main.h"
> #include "wmm.h"
> #include "11n.h"
> +#include "sdio.h"
>
> /*
> * This function adds a BSS priority table to the table list.
> @@ -737,16 +738,20 @@ mwifiex_shutdown_drv(struct mwifiex_adapter
> *adapter) int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
> struct mwifiex_fw_image *pmfw)
> {
> + struct sdio_mmc_card *card = adapter->card;
> int ret;
> u32 poll_num = 1;
>
> + if (adapter->iface_type == MWIFIEX_SDIO)
> + sdio_claim_host(card->func);
> +
> if (adapter->if_ops.check_fw_status) {
> /* check if firmware is already running */
> ret = adapter->if_ops.check_fw_status(adapter, poll_num);
> if (!ret) {
> mwifiex_dbg(adapter, MSG,
> "WLAN FW already running! Skip FW dnld\n");
> - return 0;
> + goto release_host;
> }
> }
>
> @@ -759,7 +764,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
> if (ret) {
> mwifiex_dbg(adapter, MSG,
> "WLAN read winner status failed!\n");
> - return ret;
> + goto release_host;
> }
>
> if (!adapter->winner) {
> @@ -775,7 +780,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
> if (ret) {
> mwifiex_dbg(adapter, ERROR,
> "prog_fw failed ret=%#x\n", ret);
> - return ret;
> + goto release_host;
> }
> }
>
> @@ -785,6 +790,9 @@ poll_fw:
> if (ret)
> mwifiex_dbg(adapter, ERROR,
> "FW failed to be active in time\n");
> +release_host:
> + if (adapter->iface_type == MWIFIEX_SDIO)
> + sdio_release_host(card->func);
>
> return ret;
> }
> --
> 2.1.2
Patch looks fine to me.
Acked-by: Amitkumar Karwar
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ath10k: Fix crash during card removal
From: Mohammed Shafi Shajakhan
Usually when the firmware crashes we check for the value
'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with
disabling the irq and dumping firmware 'crash dump'. Now
when the PCI card is unplugged from the device the PCI controller
seems to generate a spurious interrupt after some time which
was as treated a firmware crash and resulting in the below race
condition (and eventually crashing the system)
ath10k_core_unregister -> ath10k_core_free_board_files
.. device unplug spurious interrupt .
ath10k_pci_taklet -> ath10k_pci_fw_crashed_dump ...etc
Clearly even after the firmware board files related data structure
is freed up we are getting a spurious interrupt from PCI with 0xfff
in the 'FW_INDICATOR_ADDRESS' resulting in scheduling of the pci tasklet
and doing a crash dump, printing f/w board related info resulting in the
below crash. Fix this by detecting this spurious interrupt in ath10k PCI
irq handler itself and return IRQ_NONE. Thanks to Michal Kazior for
helping us conclude the most appropriate fix.
Call trace:
EIP is at ath10k_debug_print_board_info+0x39/0xb0
[ath10k_core]
EAX: EBX: d4de15a0 ECX: EDX: 0064
ESI: f615ddd0 EDI: f853 EBP: f615de3c ESP: f615ddbc
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 80050033 CR2: 0004 CR3: 01c0a000 CR4: 06f0
Stack:
f615ddd0 0064 f8b4ecdd 00412f4e
Call Trace:
[] ath10k_print_driver_info+0x17/0x30
[ath10k_core]
[] ath10k_pci_fw_crashed_dump+0x7a/0xe0
[ath10k_pci]
[] ath10k_pci_tasklet+0x70/0x90 [ath10k_pci]
[] tasklet_action+0x9e/0xb0
Cc: Michal Kazior
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath10k/pci.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 8133d7b..ce6269f 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2198,6 +2198,14 @@ static void ath10k_pci_fw_crashed_clear(struct ath10k
*ar)
ath10k_pci_write32(ar, FW_INDICATOR_ADDRESS, val);
}
+static bool ath10k_pci_has_device_gone(struct ath10k *ar)
+{
+ u32 val;
+
+ val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+ return (val == 0x);
+}
+
/* this function effectively clears target memory controller assert line */
static void ath10k_pci_warm_reset_si0(struct ath10k *ar)
{
@@ -2591,6 +2599,9 @@ static irqreturn_t ath10k_pci_interrupt_handler(int irq,
void *arg)
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
int ret;
+ if (ath10k_pci_has_device_gone(ar))
+ return IRQ_NONE;
+
ret = ath10k_pci_force_wake(ar);
if (ret) {
ath10k_warn(ar, "failed to wake device up on irq: %d\n", ret);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mwifiex: remove misleading GFP_DMA flag in buffer allocations
> From: Mathias Krause [mailto:mini...@googlemail.com]
> Sent: Saturday, May 21, 2016 7:14 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; linux-wireless@vger.kernel.org
> Cc: Kalle Valo; Dennis Wassenberg; Mathias Krause; Xinming Hu; Brad
> Spengler; PaX Team
> Subject: [PATCH] mwifiex: remove misleading GFP_DMA flag in buffer
> allocations
>
> The GFP_DMA flag is obviously misunderstood in the mwifiex driver. It's
> meant for legacy ISA DMA memory mappings only -- the lower 16MB on x86.
> That doesn't apply to PCIe or SDIO devices, I guess.
>
> Remove the GFP_DMA flag to reduce the need to place the socket buffer
> allocation into the low mem DMA area, which might already be in use by
> other drivers.
>
> This misuse was flagged by the PaX USERCOPY feature by chance, as it
> detected the user copy operation from a DMA buffer in the recvfrom()
> syscall path.
>
> Signed-off-by: Mathias Krause
> Tested-by: Dennis Wassenberg
> Cc: Amitkumar Karwar
> Cc: Nishant Sarmukadam
> Cc: Xinming Hu
> Cc: Kalle Valo
> Cc: Brad Spengler
> Cc: PaX Team
> ---
>
> This should go on top of wireless-drivers-next.git as it's an extension
> of commit 00c547804968 ("mwifiex: remove redundant GFP_DMA flag").
>
> drivers/net/wireless/marvell/mwifiex/11n_aggr.c |2 +-
> drivers/net/wireless/marvell/mwifiex/pcie.c |4 ++--
> drivers/net/wireless/marvell/mwifiex/sdio.c |4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
> b/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
> index 1efef3b8273d..dc49c3de1f25 100644
> --- a/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
> +++ b/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
> @@ -184,7 +184,7 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private
> *priv,
>
> tx_info_src = MWIFIEX_SKB_TXCB(skb_src);
> skb_aggr = mwifiex_alloc_dma_align_buf(adapter->tx_buf_size,
> -GFP_ATOMIC | GFP_DMA);
> +GFP_ATOMIC);
> if (!skb_aggr) {
> spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
> ra_list_flags);
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 0c7937eb6b77..adcf08bb14d5 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -507,7 +507,7 @@ static int mwifiex_init_rxq_ring(struct
> mwifiex_adapter *adapter)
> for (i = 0; i < MWIFIEX_MAX_TXRX_BD; i++) {
> /* Allocate skb here so that firmware can DMA data from it
> */
> skb = mwifiex_alloc_dma_align_buf(MWIFIEX_RX_DATA_BUF_SIZE,
> - GFP_KERNEL | GFP_DMA);
> + GFP_KERNEL);
> if (!skb) {
> mwifiex_dbg(adapter, ERROR,
> "Unable to allocate skb for RX ring.\n"); @@
> -1319,7 +1319,7 @@ static int mwifiex_pcie_process_recv_data(struct
> mwifiex_adapter *adapter)
> }
>
> skb_tmp =
> mwifiex_alloc_dma_align_buf(MWIFIEX_RX_DATA_BUF_SIZE,
> - GFP_KERNEL | GFP_DMA);
> + GFP_KERNEL);
> if (!skb_tmp) {
> mwifiex_dbg(adapter, ERROR,
> "Unable to allocate skb.\n");
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
> b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index bdc51ffd43ec..674465e0d837 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -1492,7 +1492,7 @@ rx_curr_single:
> mwifiex_dbg(adapter, INFO, "info: RX: port: %d, rx_len:
> %d\n",
> port, rx_len);
>
> - skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL |
> GFP_DMA);
> + skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL);
> if (!skb) {
> mwifiex_dbg(adapter, ERROR,
> "single skb allocated fail,\t"
> @@ -1597,7 +1597,7 @@ static int mwifiex_process_int_status(struct
> mwifiex_adapter *adapter)
> rx_len = (u16) (rx_blocks * MWIFIEX_SDIO_BLOCK_SIZE);
> mwifiex_dbg(adapter, INFO, "info: rx_len = %d\n", rx_len);
>
> - skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL |
> GFP_DMA);
> + skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL);
> if (!skb)
> return -1;
>
> --
> 1.7.10.4
Acked-by: Amitkumar Karwar
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.htm
RE: [PATCH 1/1] mwifiex: illegal assignment
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, May 18, 2016 4:32 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: Xinming Hu; Cathy Luo; linux-wireless@vger.kernel.org;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org; Heinrich
> Schuchardt
> Subject: [PATCH 1/1] mwifiex: illegal assignment
>
> Variable adapter is incorrectly initialized.
>
> Fixes: bf00dc22bc7a ("mwifiex: AMSDU Rx frame handling in AP mode")
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> index 666e91a..bf5660e 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> @@ -272,7 +272,7 @@ int mwifiex_handle_uap_rx_forward(struct
> mwifiex_private *priv, int mwifiex_uap_recv_packet(struct
> mwifiex_private *priv,
> struct sk_buff *skb)
> {
> - struct mwifiex_adapter *adapter = adapter;
> + struct mwifiex_adapter *adapter = priv->adapter;
> struct mwifiex_sta_node *src_node;
> struct ethhdr *p_ethhdr;
> struct sk_buff *skb_uap;
> --
> 2.1.4
Acked-by: Amitkumar Karwar
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
pull-request: mac80211-next 2016-06-09
Hi Dave, Here's my first set of changes for -next. The only exciting part are the changes from Michał to integrate FQ/codel into mac80211's software queues to improve cross-station latency and finally solve much of the latency issues so many people have spent so much time talking about, but never actually working on fixing until he did :) Can I ask you to pull net into net-next, preferably before merging this? I have a patch that is unsafe without a fix that I submitted through mac80211 previously (last time, not the pull request a few minutes ago), and I'd prefer not to have that in our -next trees without the fix. If you merge net into net-next before this pull request I can fast-forward mac80211-next to this merge later. Let me know if there's any problem. Thanks, johannes The following changes since commit 07b75260ebc2c789724c594d7eaf0194fa47b3be: Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus (2016-05-19 10:02:26 -0700) 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-2016-06-09 for you to fetch changes up to 5caa328e3811b7cfa33fd02c93280ffa622deb0e: mac80211: implement codel on fair queuing flows (2016-06-09 11:45:10 +0200) For the next cycle, we have the following: * the biggest change is Michał's work on integrating FQ/codel with the mac80211 internal software queues * cfg80211 connect result gets clarified for the "no connection at all" case * advertisement of per-interface type capabilities, in case they differ (which makes a lot of sense for some capabilities) * most of the nl80211 & hwsim unprivileged namespace operation changes * human-readable VHT capabilities in debugfs * some other cleanups, like spelling Ben Greear (1): mac80211: add vht cap decode to debugfs Johannes Berg (2): wext: reformat struct/union declarations nl80211: clarify nl80211_set_reg() success path Jouni Malinen (1): cfg80211: Allow cfg80211_connect_result() errors to be distinguished Kanchanapally, Vidyullatha (1): cfg80211: Advertise extended capabilities per interface type to userspace Kirtika Ruchandani (2): nl80211: Fix spelling nl80211: Fix checkpatch warnings about blank lines Martin Willi (2): nl80211: Allow privileged operations from user namespaces mac80211_hwsim: Allow managing radios from non-initial namespaces Michal Kazior (4): mac80211: skip netdev queue control with software queuing mac80211: implement fair queueing per txq mac80211: add debug knobs for fair queuing mac80211: implement codel on fair queuing flows Documentation/DocBook/80211.tmpl | 1 + drivers/net/wireless/mac80211_hwsim.c | 97 ++- include/net/cfg80211.h| 81 -- include/net/mac80211.h| 18 ++- include/uapi/linux/nl80211.h | 14 +- include/uapi/linux/wireless.h | 63 +++- net/mac80211/agg-tx.c | 8 +- net/mac80211/debugfs.c| 173 net/mac80211/debugfs_sta.c| 78 - net/mac80211/ieee80211_i.h| 31 +++- net/mac80211/iface.c | 26 ++- net/mac80211/main.c | 10 +- net/mac80211/rx.c | 2 +- net/mac80211/sta_info.c | 14 +- net/mac80211/tx.c | 292 +- net/mac80211/util.c | 34 +--- net/wireless/core.c | 30 net/wireless/core.h | 4 +- net/wireless/nl80211.c| 232 --- net/wireless/nl80211.h| 2 +- net/wireless/sme.c| 8 +- 21 files changed, 955 insertions(+), 263 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull-request: mac80211 2016-06-09
Hi Dave, Here are two more fixes for the current cycle, please pull. Let me know if there's any problem. Thanks, johannes The following changes since commit 6fe04128f158c5ad27e7504bfdf1b12e63331bc9: mac80211: fix fast_tx header alignment (2016-05-31 12:14:04 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-06-09 for you to fetch changes up to 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724: wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel (2016-06-09 09:56:11 +0200) Two more fixes for now: * a fix for a long-standing iwpriv 32/64 compat issue * two fairly recently introduced (4.6) warning asking for symmetric operations are erroneous and I remove them Johannes Berg (1): cfg80211: remove get/set antenna and tx power warnings Prasun Maiti (1): wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel net/wireless/core.c | 2 -- net/wireless/wext-core.c | 25 +++-- 2 files changed, 23 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger
On Thu, 2016-05-19 at 09:16 +0200, Pavel Machek wrote: > > In the original situation, without these patches, userspace has to > > have a list of all LEDs that are supposed to indicate airplane > > mode. > Well, that's situation for many LEDs. That doesn't make it a *good* situation though. > > With this patch only (without patch 2/3), userspace can look up the > > default trigger, but then has to change it, causing the necessary > > information to be lost immediately when you actually use it - that > > also seems like a bad idea. > We should not store "what kind of led this is" in a trigger. That's pretty much what I'm arguing though. > LED > subsystem seems to use suffix of LED name to do that. So if we > standartize, lets say "::rfkill" suffix for this, it should work and > follow existing practice. [...] > There is one -- suffix in the LED name. I don't really think that's a good way, and it doesn't seem to be used universally, but I suppose it's good enough. João, that means you should send a patch to add the ::rfkill suffix. And Pavel should send a patch to document the practice and the existing suffixes with their meaning ;-) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ath9k: Expose tsf_adjustment in mac80211 tsf getters and setters.
Benjamin Berg writes: > From: Benjamin Berg > > Signed-off-by: Benjamin Berg Why? Does this help with mesh or what? Remember that the most important part of the commit log is to answer the question "Why?". -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ath9k: Use tsf offset helper in ath9k_hw_reset
Benjamin Berg writes: > From: Benjamin Berg > > Not much of a change. Only small fix is that we don't assume that > exactly 1.5ms have passed for the second AR91xx SoC TSF setting. > > Signed-off-by: Benjamin Berg Why we don't need that 1.5 ms delta anymore? It would be good to document that in the commit log in case someone else wonders why that change was made. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ath9k: Handle channel context in get_/set_/reset_tsf
Benjamin Berg writes: > From: Benjamin Berg > > Signed-off-by: Benjamin Berg Please avoid empty commit logs, it's just unfriendly to everyone. It doesn't take long for you to answer "Why?" in the log. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 3/5] mac80211: add debug knobs for fair queuing
On Thu, 2016-05-05 at 13:00 +0200, Michal Kazior wrote: > This adds a few debugfs entries and a module > parameter to make it easier to test, debug and > experiment. > I removed the module parameter, I don't really like that. Maybe it can be replaced by a mac80211 debugfs file, that already exists when mac80211 is loaded, outside the context of a device, so it can be set before loading the driver? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 0/5] mac80211: implement fq_codel
Applied 1-4, with the changes and comments on 5 noted in separate emails. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 5/5] mac80211: add debug knobs for codel
> +++ b/net/mac80211/debugfs.c > @@ -126,13 +126,31 @@ static int aqm_open(struct inode *inode, struct > file *file) > "R fq_overlimit %u\n" > "R fq_collisions %u\n" > "RW fq_limit %u\n" > - "RW fq_quantum %u\n", > + "RW fq_quantum %u\n" > + "R codel_maxpacket %u\n" > + "R codel_drop_count %u\n" > It seems to me that this needs to adjust the length of the buffer that's allocated. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] nl80211: clarify nl80211_set_reg() success path
From: Johannes Berg Setting rd to NULL to avoid freeing it, just to be able to return from the function in a single place, doesn't make much sense. Return the set_regdom() return value directly. Signed-off-by: Johannes Berg --- net/wireless/nl80211.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 0d7db10c782f..c503e96bfd5a 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -5836,10 +5836,8 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info) } } - r = set_regdom(rd, REGD_SOURCE_CRDA); - /* set_regdom took ownership */ - rd = NULL; - + /* set_regdom takes ownership of rd */ + return set_regdom(rd, REGD_SOURCE_CRDA); bad_reg: kfree(rd); return r; -- 2.8.0.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: avoid possible memleak on nl80211_set_reg
> > > +++ b/net/wireless/nl80211.c > > > @@ -5839,10 +5839,11 @@ static int nl80211_set_reg(struct sk_buff > > > *skb, struct genl_info *info) > > > > > > r = set_regdom(rd, REGD_SOURCE_CRDA); > > > /* set_regdom took ownership */ > > > - rd = NULL; > > > > > > bad_reg: > > > kfree(rd); > > > + rd = NULL; > > To this I can only say: what? > The patch is bad, but the confusion starts with the original code > (ab)using kfree() behaviour by setting rd to NULL. Personally, I do > not like it, but prefer it over bugs ;-) > Yeah, fair enough. I'll make the following patch: - r = set_regdom(rd, REGD_SOURCE_CRDA); - /* set_regdom took ownership */ - rd = NULL; + /* set_regdom takes ownership of rd */ + return set_regdom(rd, REGD_SOURCE_CRDA); johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: avoid possible memleak on nl80211_set_reg
On 9-6-2016 9:58, Johannes Berg wrote: > On Mon, 2016-06-06 at 16:56 +0200, Eduardo Abinader wrote: >> Setting NULL just after freeing regdomain. >> >> Signed-off-by: Eduardo Abinader >> --- >> net/wireless/nl80211.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c >> index d120449..39d107d 100644 >> --- a/net/wireless/nl80211.c >> +++ b/net/wireless/nl80211.c >> @@ -5839,10 +5839,11 @@ static int nl80211_set_reg(struct sk_buff >> *skb, struct genl_info *info) >> >> r = set_regdom(rd, REGD_SOURCE_CRDA); >> /* set_regdom took ownership */ >> -rd = NULL; >> >> bad_reg: >> kfree(rd); >> +rd = NULL; > > To this I can only say: what? The patch is bad, but the confusion starts with the original code (ab)using kfree() behaviour by setting rd to NULL. Personally, I do not like it, but prefer it over bugs ;-) Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iw: support and enable separate build dir
On Wed, 2016-06-01 at 11:40 +0300, maxin.j...@gmail.com wrote: > From: "Maxin B. John" > > Support separation of SRCDIR and OBJDIR > Doesn't seem to work: $ mkdir /tmp/obj $ make clean $ make OBJDIR=/tmp/obj [...] GEN version.c CC version.o cc: error: version.c: No such file or directory cc: fatal error: no input files compilation terminated. Makefile:104: recipe for target 'version.o' failed make: *** [version.o] Error 1 $ ls *.o event.o genl.o ibss.o info.o interface.o iw.o mesh.o mpath.o mpp.o ocb.o phy.o reg.o scan.o station.o survey.o util.o (object files are in the wrong place too) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] wext: reformat struct/union declarations
From: Johannes Berg
Everytime I need to look for these, my usual strategy fails
because it assumes the right formatting. Fix the formatting
here to make it consistent with the rest of the kernel.
Signed-off-by: Johannes Berg
---
include/uapi/linux/wireless.h | 63 +++
1 file changed, 22 insertions(+), 41 deletions(-)
diff --git a/include/uapi/linux/wireless.h b/include/uapi/linux/wireless.h
index c1592e3e4036..d9ecd7c6d691 100644
--- a/include/uapi/linux/wireless.h
+++ b/include/uapi/linux/wireless.h
@@ -670,8 +670,7 @@
/*
* Generic format for most parameters that fit in an int
*/
-struct iw_param
-{
+struct iw_param {
__s32value; /* The value of the parameter itself */
__u8 fixed; /* Hardware should not use auto select */
__u8 disabled; /* Disable the feature */
@@ -682,8 +681,7 @@ struct iw_param
* For all data larger than 16 octets, we need to use a
* pointer to memory allocated in user space.
*/
-struct iw_point
-{
+struct iw_point {
void __user *pointer; /* Pointer to the data (in user space) */
__u16length; /* number of fields or size in bytes */
__u16flags; /* Optional params */
@@ -698,8 +696,7 @@ struct iw_point
* of 10 to get 'm' lower than 10^9, with 'm'= f / (10^'e')...
* The power of 10 is in 'e', the result of the division is in 'm'.
*/
-struct iw_freq
-{
+struct iw_freq {
__s32 m; /* Mantissa */
__s16 e; /* Exponent */
__u8i; /* List index (when in range struct) */
@@ -709,8 +706,7 @@ struct iw_freq
/*
* Quality of the link
*/
-struct iw_quality
-{
+struct iw_quality {
__u8qual; /* link quality (%retries, SNR,
%missed beacons or better...) */
__u8level; /* signal level (dBm) */
@@ -725,8 +721,7 @@ struct iw_quality
* is already pretty exhaustive, and you should use that first.
* This is only additional stats...
*/
-struct iw_discarded
-{
+struct iw_discarded {
__u32 nwid; /* Rx : Wrong nwid/essid */
__u32 code; /* Rx : Unable to code/decode (WEP) */
__u32 fragment; /* Rx : Can't perform MAC reassembly */
@@ -738,16 +733,14 @@ structiw_discarded
* Packet/Time period missed in the wireless adapter due to
* "wireless" specific problems...
*/
-struct iw_missed
-{
+struct iw_missed {
__u32 beacon; /* Missed beacons/superframe */
};
/*
* Quality range (for spy threshold)
*/
-struct iw_thrspy
-{
+struct iw_thrspy {
struct sockaddr addr; /* Source address (hw/mac) */
struct iw_quality qual; /* Quality of the link */
struct iw_quality low;/* Low threshold */
@@ -765,8 +758,7 @@ struct iw_thrspy
* Especially, scan results are required to include an entry for the
* current BSS if the driver is in Managed mode and associated with an AP.
*/
-struct iw_scan_req
-{
+struct iw_scan_req {
__u8scan_type; /* IW_SCAN_TYPE_{ACTIVE,PASSIVE} */
__u8essid_len;
__u8num_channels; /* num entries in channel_list;
@@ -827,8 +819,7 @@ struct iw_scan_req
* RX_SEQ_VALID for SIOCGIWENCODEEXT are optional, but can be useful for
* debugging/testing.
*/
-struct iw_encode_ext
-{
+struct iw_encode_ext {
__u32 ext_flags; /* IW_ENCODE_EXT_* */
__u8tx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */
__u8rx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */
@@ -841,8 +832,7 @@ struct iw_encode_ext
};
/* SIOCSIWMLME data */
-struct iw_mlme
-{
+struct iw_mlme {
__u16 cmd; /* IW_MLME_* */
__u16 reason_code;
struct sockaddr addr;
@@ -855,16 +845,14 @@ structiw_mlme
#define IW_PMKID_LEN 16
-struct iw_pmksa
-{
+struct iw_pmksa {
__u32 cmd; /* IW_PMKSA_* */
struct sockaddr bssid;
__u8pmkid[IW_PMKID_LEN];
};
/* IWEVMICHAELMICFAILURE data */
-struct iw_michaelmicfailure
-{
+struct iw_michaelmicfailure {
__u32 flags;
struct sockaddr src_addr;
__u8tsc[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */
@@ -872,8 +860,7 @@ struct iw_michaelmicfailure
/* IWEVPMKIDCAND data */
#define IW_PMKID_CAND_PREAUTH 0x0001 /* RNS pre-authentication enabled */
-struct iw_pmkid_cand
-{
+struct iw_pmkid_cand {
__u32 flags; /* IW_PMKID_CAND_* */
__u32 index; /* the smaller the index, the higher the
* priority */
@@ -884,8 +871,7 @@ struc
Re: [PATCH v2 3/3] mwifiex: add get_antenna support for cfg80211
2016-06-06 19:02 GMT+02:00 Javier Martinez Canillas :
> From: Shengzhen Li
>
> Since commit de3bb771f471 ("cfg80211: add more warnings for inconsistent
> ops") the wireless core warns if a driver implements a cfg80211 callback
> but doesn't implements the inverse operation.
>
> The mwifiex driver defines a .set_antenna handler but not a .get_antenna
> so this not only makes the core to print a warning when creating a new
> wiphy but also the antenna isn't reported to user-space apps such as iw.
>
> This patch queries the antenna to the firmware so is properly reported to
> user-space. With this patch, the wireless core does not warn anymore and:
>
> $ iw phy phy0 info | grep Antennas
> Available Antennas: TX 0x3 RX 0x3
> Configured Antennas: TX 0x3 RX 0x3
>
> Signed-off-by: Shengzhen Li
> Signed-off-by: Amitkumar Karwar
> [javier: expand the commit message]
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/net/wireless/marvell/mwifiex/cfg80211.c| 16 +++
> drivers/net/wireless/marvell/mwifiex/fw.h | 3 ++
> drivers/net/wireless/marvell/mwifiex/init.c| 2 +
> drivers/net/wireless/marvell/mwifiex/main.h| 2 +
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 50
> +++---
> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 10 +++--
> 6 files changed, 64 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index ff3f63ed95e1..ff1eefe5087b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -1819,6 +1819,21 @@ mwifiex_cfg80211_set_antenna(struct wiphy *wiphy, u32
> tx_ant, u32 rx_ant)
> HostCmd_ACT_GEN_SET, 0, &ant_cfg, true);
> }
>
> +static int
> +mwifiex_cfg80211_get_antenna(struct wiphy *wiphy, u32 *tx_ant, u32 *rx_ant)
> +{
> + struct mwifiex_adapter *adapter = mwifiex_cfg80211_get_adapter(wiphy);
> + struct mwifiex_private *priv = mwifiex_get_priv(adapter,
> + MWIFIEX_BSS_ROLE_ANY);
> + mwifiex_send_cmd(priv, HostCmd_CMD_RF_ANTENNA,
> +HostCmd_ACT_GEN_GET, 0, NULL, true);
> +
> + *tx_ant = priv->tx_ant;
> + *rx_ant = priv->rx_ant;
> +
> + return 0;
> +}
> +
> /* cfg80211 operation handler for stop ap.
> * Function stops BSS running at uAP interface.
> */
> @@ -3962,6 +3977,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
> .change_beacon = mwifiex_cfg80211_change_beacon,
> .set_cqm_rssi_config = mwifiex_cfg80211_set_cqm_rssi_config,
> .set_antenna = mwifiex_cfg80211_set_antenna,
> + .get_antenna = mwifiex_cfg80211_get_antenna,
> .del_station = mwifiex_cfg80211_del_station,
> .sched_scan_start = mwifiex_cfg80211_sched_scan_start,
> .sched_scan_stop = mwifiex_cfg80211_sched_scan_stop,
> diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h
> b/drivers/net/wireless/marvell/mwifiex/fw.h
> index 8e4145abdbfa..cef72343f5b6 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -462,6 +462,9 @@ enum P2P_MODES {
> #define HostCmd_ACT_SET_RX 0x0001
> #define HostCmd_ACT_SET_TX 0x0002
> #define HostCmd_ACT_SET_BOTH0x0003
> +#define HostCmd_ACT_GET_RX 0x0004
> +#define HostCmd_ACT_GET_TX 0x0008
> +#define HostCmd_ACT_GET_BOTH0x000c
>
> #define RF_ANTENNA_AUTO 0x
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c
> b/drivers/net/wireless/marvell/mwifiex/init.c
> index 78c532f0d286..fbaf49056746 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -110,6 +110,8 @@ int mwifiex_init_priv(struct mwifiex_private *priv)
> priv->tx_power_level = 0;
> priv->max_tx_power_level = 0;
> priv->min_tx_power_level = 0;
> + priv->tx_ant = 0;
> + priv->rx_ant = 0;
> priv->tx_rate = 0;
> priv->rxpd_htinfo = 0;
> priv->rxpd_rate = 0;
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h
> b/drivers/net/wireless/marvell/mwifiex/main.h
> index 79c28cfb7780..2ae7ff74e1c6 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -533,6 +533,8 @@ struct mwifiex_private {
> u16 tx_power_level;
> u8 max_tx_power_level;
> u8 min_tx_power_level;
> + u32 tx_ant;
> + u32 rx_ant;
> u8 tx_rate;
> u8 tx_htinfo;
> u8 rxpd_htinfo;
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574b1698..8c658495bf66 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marve
Re: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station ioctl file
2016-06-06 19:02 GMT+02:00 Javier Martinez Canillas :
> From: Shengzhen Li
>
> Most cfg80211 operations are just a wrappers to functions defined in the
> sta_ioctl.c file, so for consistency move the .get_tx_power logic there.
>
> Signed-off-by: Shengzhen Li
> Signed-off-by: Amitkumar Karwar
> [javier: update the subject line and commit message]
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 +++---
> drivers/net/wireless/marvell/mwifiex/main.h | 2 ++
> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 18 ++
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index b17f3d09a2c7..ff3f63ed95e1 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -385,18 +385,10 @@ mwifiex_cfg80211_get_tx_power(struct wiphy *wiphy,
> int *dbm)
> {
> struct mwifiex_adapter *adapter = mwifiex_cfg80211_get_adapter(wiphy);
> - struct mwifiex_private *priv = mwifiex_get_priv(adapter,
> - MWIFIEX_BSS_ROLE_ANY);
> - int ret = mwifiex_send_cmd(priv, HostCmd_CMD_RF_TX_PWR,
> - HostCmd_ACT_GEN_GET, 0, NULL, true);
> -
> - if (ret < 0)
> - return ret;
> -
> - /* tx_power_level is set in HostCmd_CMD_RF_TX_PWR command handler */
> - *dbm = priv->tx_power_level;
> + struct mwifiex_private *priv;
>
> - return 0;
> + priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
> + return mwifiex_get_tx_power(priv, dbm);
> }
>
> /*
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h
> b/drivers/net/wireless/marvell/mwifiex/main.h
> index 0207af00be42..79c28cfb7780 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -1464,6 +1464,8 @@ int mwifiex_drv_get_driver_version(struct
> mwifiex_adapter *adapter,
> int mwifiex_set_tx_power(struct mwifiex_private *priv,
> struct mwifiex_power_cfg *power_cfg);
>
> +int mwifiex_get_tx_power(struct mwifiex_private *priv, int *dbm);
> +
> int mwifiex_main_process(struct mwifiex_adapter *);
>
> int mwifiex_queue_tx_pkt(struct mwifiex_private *priv, struct sk_buff *skb);
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
> b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
> index 8e0862657122..70ff9b805b5b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
> @@ -775,6 +775,24 @@ int mwifiex_set_tx_power(struct mwifiex_private *priv,
> }
>
> /*
> + * IOCTL request handler to get tx power configuration.
> + *
> + * This function prepares the correct firmware command and
> + * issues it.
> + */
> +int mwifiex_get_tx_power(struct mwifiex_private *priv, int *dbm)
> +{
> + int ret;
> +
> + ret = mwifiex_send_cmd(priv, HostCmd_CMD_TXPWR_CFG,
> + HostCmd_ACT_GEN_GET, 0, NULL, true);
> +
> + *dbm = priv->tx_power_level;
> +
> + return ret;
> +}
> +
> +/*
> * IOCTL request handler to get power save mode.
> *
> * This function prepares the correct firmware command and
> --
> 2.5.5
>
Tested-by: Enric Balletbo i Serra
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] mwifiex: add a cfg80211 .get_tx_power operation callback
2016-06-06 19:02 GMT+02:00 Javier Martinez Canillas :
> The mwifiex driver implements a cfg80211 .set_tx_power operation handler
> but doesn't have the inverse .get_tx_power callback.
>
> This not only has the effect that the Tx power can't be reported to user
> space tools such as iwconfig and iwlist but also that the wireless core
> prints a warning when a new wiphy is created due an cfg80211 operation
> being implemented without its counterpart.
>
> After this patch, the Tx power is properly reported to user-space tools:
>
> $ iwlist mlan0 txpower
> mlan0 unknown transmit-power information.
>
> Current Tx-Power=13 dBm (19 mW)
>
> and also the following warning isn't shown anymore on the driver probe:
>
> WARNING: CPU: 3 PID: 127 at net/wireless/core.c:366 wiphy_new_nm+0x66c/0x6ac
> Modules linked in: mwifiex_sdio mwifiex
> CPU: 3 PID: 127 Comm: kworker/3:1 Tainted: GW
> 4.7.0-rc1-next-20160531-6-g569df5b983f3
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> Workqueue: events request_firmware_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x88/0x9c)
> [] (dump_stack) from [] (__warn+0xe8/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] (wiphy_new_nm+0x66c/0x6ac)
> [] (wiphy_new_nm) from []
> (mwifiex_register_cfg80211+0x28/0x3f0 [mwifiex])
> [] (mwifiex_register_cfg80211 [mwifiex]) from []
> (mwifiex_fw_dpc+0x2b0/0x474 [mwifiex])
> [] (mwifiex_fw_dpc [mwifiex]) from []
> (request_firmware_work_func+0x30/0x58)
> [] (request_firmware_work_func) from []
> (process_one_work+0x124/0x338)
> [] (process_one_work) from [] (worker_thread+0x38/0x4d4)
> [] (worker_thread) from [] (kthread+0xdc/0xf4)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index ff948a92..b17f3d09a2c7 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -377,6 +377,29 @@ mwifiex_cfg80211_set_tx_power(struct wiphy *wiphy,
> }
>
> /*
> + * CFG802.11 operation handler to get Tx power.
> + */
> +static int
> +mwifiex_cfg80211_get_tx_power(struct wiphy *wiphy,
> + struct wireless_dev *wdev,
> + int *dbm)
> +{
> + struct mwifiex_adapter *adapter = mwifiex_cfg80211_get_adapter(wiphy);
> + struct mwifiex_private *priv = mwifiex_get_priv(adapter,
> + MWIFIEX_BSS_ROLE_ANY);
> + int ret = mwifiex_send_cmd(priv, HostCmd_CMD_RF_TX_PWR,
> + HostCmd_ACT_GEN_GET, 0, NULL, true);
> +
> + if (ret < 0)
> + return ret;
> +
> + /* tx_power_level is set in HostCmd_CMD_RF_TX_PWR command handler */
> + *dbm = priv->tx_power_level;
> +
> + return 0;
> +}
> +
> +/*
> * CFG802.11 operation handler to set Power Save option.
> *
> * The timeout value, if provided, is currently ignored.
> @@ -3940,6 +3963,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
> .set_default_key = mwifiex_cfg80211_set_default_key,
> .set_power_mgmt = mwifiex_cfg80211_set_power_mgmt,
> .set_tx_power = mwifiex_cfg80211_set_tx_power,
> + .get_tx_power = mwifiex_cfg80211_get_tx_power,
> .set_bitrate_mask = mwifiex_cfg80211_set_bitrate_mask,
> .start_ap = mwifiex_cfg80211_start_ap,
> .stop_ap = mwifiex_cfg80211_stop_ap,
> --
> 2.5.5
>
This fixes the WARN_ON and makes things work, thanks.
Tested-by: Enric Balletbo i Serra
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: avoid possible memleak on nl80211_set_reg
On Mon, 2016-06-06 at 16:56 +0200, Eduardo Abinader wrote: > Setting NULL just after freeing regdomain. > > Signed-off-by: Eduardo Abinader > --- > net/wireless/nl80211.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c > index d120449..39d107d 100644 > --- a/net/wireless/nl80211.c > +++ b/net/wireless/nl80211.c > @@ -5839,10 +5839,11 @@ static int nl80211_set_reg(struct sk_buff > *skb, struct genl_info *info) > > r = set_regdom(rd, REGD_SOURCE_CRDA); > /* set_regdom took ownership */ > - rd = NULL; > > bad_reg: > kfree(rd); > + rd = NULL; To this I can only say: what? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
On Mon, 2016-06-06 at 20:04 +0530, Prasun Maiti wrote: > iwpriv app uses iw_point structure to send data to Kernel. The > iw_point > structure holds a pointer. For compatibility Kernel converts the > pointer > as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers > may use iw_handler_def.private_args to populate iwpriv commands > instead > of iw_handler_def.private. For those case, the IOCTLs from > SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path > ndo_do_ioctl(). > Accordingly when the filled up iw_point structure comes from 32 bit > iwpriv to 64 bit Kernel, Kernel will not convert the pointer and > sends > it to driver. So, the driver may get the invalid data. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ath10k/QCA9980 - Issues introduced in wireless testing 2016-05
Dear All, I am using LEDE on my IPQ806x (QCA9980) system (Archer C2600). With compat-wireless-2016-05-12, I observed traces attached below. The router is unstable and eventually reboots by itself (randomly). Upon reverting to compat-wireless-2016-01, the issue disappears. Nothing else is changed (software-wise or hardware). This was confirmed with other users. A new compile with the fixes below: https://git.lede-project.org/?p=lede/nbd/staging.git;a=commit;h=858e26f3c0fc11231f25497cbb2ddca1e5f101e0 Did not solve the problem. Please let me know if I need to provide any further information. [ cut here ] WARNING: CPU: 0 PID: 558 at compat-wireless-2016-05-12/net/mac80211/rx.c:4068 ieee80211_rx_napi+0x8c/0x8a4 [mac80211]() Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_fWed May 25 21:21:57 2016 kern.warn kernel: [24187.498347] CPU: 0 PID: 558 Comm: hostapd Tainted: GW 4.4.11 #2 Hardware name: Qualcomm (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x88/0x9c) [] (dump_stack) from [] (warn_slowpath_common+0x94/0xb0) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null) from [] (ieee80211_rx_napi+0x8c/0x8a4 [mac80211]) [] (ieee80211_rx_napi [mac80211]) from [] (ath10k_htt_t2h_msg_handler+0x92c/0x988 [ath10k_core]) [] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [] (ath10k_htt_txrx_compl_task+0x9bc/0x117c [ath10k_core]) [] (ath10k_htt_txrx_compl_task [ath10k_core]) from [] (tasklet_action+0xb8/0x144) [] (tasklet_action) from [] (__do_softirq+0xe0/0x21c) [] (__do_softirq) from [] (do_softirq.part.2+0x28/0x30) [] (do_softirq.part.2) from [] (__local_bh_enable_ip+0xb4/0x104) [] (__local_bh_enable_ip) from [] (packet_poll+0xc0/0x100) [] (packet_poll) from [] (sock_poll+0xec/0xf8) [] (sock_poll) from [] (do_select+0x2f8/0x62c) [] (do_select) from [] (core_sys_select+0x294/0x424) [] (core_sys_select) from [] (SyS_select+0x104/0x130) [] (SyS_select) from [] (ret_fast_syscall+0x0/0x3c) ---[ end trace e55b94e0d302fcd8 ]--- Regards, A. Benz -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cfg80211: remove get/set antenna and tx power warnings
From: Johannes Berg
Since set_tx_power and set_antenna are frequently implemented
without the matching get_tx_power/get_antenna, we shouldn't
have added warnings for those. Remove them.
The remaining ones are correct and need to be implemented
symmetrically for correct operation.
Cc: sta...@vger.kernel.org
Fixes: de3bb771f471 ("cfg80211: add more warnings for inconsistent ops")
Signed-off-by: Johannes Berg
---
net/wireless/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index d25c82bc1bbe..ecca3896b9f7 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -363,8 +363,6 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops,
int sizeof_priv,
WARN_ON(ops->remain_on_channel && !ops->cancel_remain_on_channel);
WARN_ON(ops->tdls_channel_switch && !ops->tdls_cancel_channel_switch);
WARN_ON(ops->add_tx_ts && !ops->del_tx_ts);
- WARN_ON(ops->set_tx_power && !ops->get_tx_power);
- WARN_ON(ops->set_antenna && !ops->get_antenna);
alloc_size = sizeof(*rdev) + sizeof_priv;
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add .set_antenna callback in ath6kl driver to fix wireless core warns
Prasun Maiti writes:
> Since add more warnings for inconsistent ops in cfg80211, the wireless
> core warns if a driver implements a cfg80211 callback but doesn't
> implements the inverse operation. The ath6kl driver implements a cfg80211
> .get_antenna operation handler but doesn't have the inverse .set_antenna
> callback. So, it makes warning.
>
> To remove this warning, add .set_antenna callback in ath6kl driver which
> is unimplemented.
>
> Signed-off-by: Prasun Maiti
[...]
> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> @@ -3231,6 +3231,16 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct
> wireless_dev *wdev,
> wait, buf, len, no_cck);
> }
>
> +static int ath6kl_set_antenna(struct wiphy *wiphy,
> + u32 tx_ant, u32 rx_ant)
> +{
> + /*
> + * Note: This callback should be implement when firmware support this
> + * command.
> + */
> + return 0;
> +}
> +
> static int ath6kl_get_antenna(struct wiphy *wiphy,
> u32 *tx_ant, u32 *rx_ant)
> {
> @@ -3456,6 +3466,7 @@ static struct cfg80211_ops ath6kl_cfg80211_ops = {
> .cancel_remain_on_channel = ath6kl_cancel_remain_on_channel,
> .mgmt_tx = ath6kl_mgmt_tx,
> .mgmt_frame_register = ath6kl_mgmt_frame_register,
> + .set_antenna = ath6kl_set_antenna,
Now we are claiming that ath6kl supports set antenna command but it
actually doesn't do anything, I don't like that. I would rather look at
why cfg80211 issues the warning and is it really necessary.
--
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
