brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
Hey guys, I'm afraid I hit another brcmfmac bug. First of all, I implemented a trivial workaround for the previous bug reported in the: brcmfmac: one faulty "iw interface add" command breaks in-firmware BSS state See my workaround in OpenWrt git: http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=0e6c9bd9556eea98b476ad371d64d8d16e3a9f9c So now OpenWrt's user space calls using "iw" tool don't trigger brcmfmac BSSes bug anymore. I can successfully use one AP interface per device. The problem appears when trying to use more than 1 interface. It gets created correctly, but setting its MAC fails. It results in wlan0-1 having the same MAC as wlan0 and finally having two networks (SSIDs) using the same MAC. That obviously doesn't work. The error I see is: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 with -52 meaning BCME_IE_NOTFOUND. -- Rafał [ 17.014251] brcmfmac :01:00.0: enabling device (0140 -> 0142) [ 17.028974] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 17.036950] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 17.044939] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 17.052922] cfg80211: (517 KHz - 525 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 17.062363] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 17.071805] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 17.079859] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 17.087842] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [ 17.867533] brcmfmac :01:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2 [ 17.877408] brcmfmac :01:00.0: Falling back to user helper [ 17.892499] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: map pages failed [ 17.901084] brcmfmac: brcmf_fw_request_nvram_done: Found platform NVRAM (19204 B) [ 18.163675] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar 3 2015 04:46:51 version 7.35.177.33 (r538052) FWID 01-c8317c80 [ 18.184345] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 203.691845] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists [ 203.698361] brcmfmac: brcmf_add_if: ignore IF event [ 203.866214] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists [ 203.872750] brcmfmac: brcmf_add_if: ignore IF event [ 203.932492] brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 [ 204.088635] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists [ 204.095205] brcmfmac: brcmf_add_if: ignore IF event hostapd.conf Description: Binary data
[PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
There's already a generic implementation so use that instead. --- I'm not sure if the driver usage of atomic_or?() is correct in terms of storage size of @val for 64 bit arches. Assuming LP64 programming model for linux on say x86_64: atomic_or() callers in this driver use long (sana 64 bit) storage and pass it to atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ? --- Cc: Brett Rudley Cc: Arend van Spriel Cc: "Franky (Zhenhui) Lin" Cc: Hante Meuleman Cc: Kalle Valo Cc: Pieter-Paul Giesberts Cc: Daniel Kim Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-l...@broadcom.com Cc: Peter Zijlstra Cc: Ingo Molnar Cc: net...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Vineet Gupta --- drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c index d36f5f3d931b..f990e3d0e696 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c @@ -2564,15 +2564,6 @@ static inline void brcmf_sdio_clrintr(struct brcmf_sdio *bus) } } -static void atomic_orr(int val, atomic_t *v) -{ - int old_val; - - old_val = atomic_read(v); - while (atomic_cmpxchg(v, old_val, val | old_val) != old_val) - old_val = atomic_read(v); -} - static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus) { struct brcmf_core *buscore; @@ -2595,7 +2586,7 @@ static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus) if (val) { brcmf_sdiod_regwl(bus->sdiodev, addr, val, &ret); bus->sdcnt.f1regdata++; - atomic_orr(val, &bus->intstatus); + atomic_or(val, &bus->intstatus); } return ret; @@ -2712,7 +2703,7 @@ static void brcmf_sdio_dpc(struct brcmf_sdio *bus) /* Keep still-pending events for next scheduling */ if (intstatus) - atomic_orr(intstatus, &bus->intstatus); + atomic_or(intstatus, &bus->intstatus); brcmf_sdio_clrintr(bus); -- 1.9.1 -- 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/2] ath10k: ensure pktlog disable cmd reaches fw before pdev suspend
Found incorrect sequence in ath10k_core_stop() where wmi pktlog disable cmd is passed from ath10k_debug_stop() to firmware immediately after wmi pdev suspend cmd. Firmware will not accept any wmi cmd after receiving wmi pdev suspend cmd. Fix this issue in ath10k_core_stop() by moving ath10k_debug_stop() just before sending pdev suspend cmd. So that pktlog disable cmd will get passed before pdev suspend cmd. Signed-off-by: Raja Mani --- drivers/net/wireless/ath/ath10k/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index f79fa6c..6d19d3d 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -1368,13 +1368,13 @@ int ath10k_wait_for_suspend(struct ath10k *ar, u32 suspend_opt) void ath10k_core_stop(struct ath10k *ar) { lockdep_assert_held(&ar->conf_mutex); + ath10k_debug_stop(ar); /* try to suspend target */ if (ar->state != ATH10K_STATE_RESTARTING && ar->state != ATH10K_STATE_UTF) ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR); - ath10k_debug_stop(ar); ath10k_hif_stop(ar); ath10k_htt_tx_free(&ar->htt); ath10k_htt_rx_free(&ar->htt); -- 1.8.1.2 -- 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/2] ath10k: free collected fw stats memory if .pull_fw_stats fails
If .pull_fw_stats() fails for some reason while processing fw stats event, collected pdev/vdev/peer stats just before the failure should be freed. This is unlikely to happen, just code review catch. Signed-off-by: Raja Mani --- drivers/net/wireless/ath/ath10k/debug.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c index edf6047..fc6852c 100644 --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -321,7 +321,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb) ret = ath10k_wmi_pull_fw_stats(ar, skb, &stats); if (ret) { ath10k_warn(ar, "failed to pull fw stats: %d\n", ret); - goto unlock; + goto free; } /* Stat data may exceed htc-wmi buffer limit. In such case firmware @@ -384,7 +384,6 @@ free: ath10k_debug_fw_stats_vdevs_free(&stats.vdevs); ath10k_debug_fw_stats_peers_free(&stats.peers); -unlock: spin_unlock_bh(&ar->data_lock); } -- 1.8.1.2 -- 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] ath9k: fix moredata flag endianness in cabq tx
While compiling ath9k with some extra flags I've found that: ath9k/xmit.c +2473 ## 16: warning: restricted __le16 degrades to integer ath9k/xmit.c +2474 ## 36: warning: invalid assignment: &= ath9k/xmit.c +2474 ## 36:left side has type restricted __le16 ath9k/xmit.c +2474 ## 36:right side has type int There's no way for frame ftype/stype to be mistreated as the offending 'moredata' flag when considering cab queue. This could've however theoretically led sometimes to increased power consumption on connected stations as they would keep their Rx active waiting for frames that would never come. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath9k/xmit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 3ad79bb4f2c2..d8cc45106f85 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -2470,8 +2470,8 @@ void ath_tx_cabq(struct ieee80211_hw *hw, struct ieee80211_vif *vif, bf = list_first_entry(&bf_q, struct ath_buf, list); hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data; - if (hdr->frame_control & IEEE80211_FCTL_MOREDATA) { - hdr->frame_control &= ~IEEE80211_FCTL_MOREDATA; + if (hdr->frame_control & cpu_to_le16(IEEE80211_FCTL_MOREDATA)) { + hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_MOREDATA); dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, sizeof(*hdr), DMA_TO_DEVICE); } -- 2.1.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: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
On 9 July 2015 at 09:07, Rafał Miłecki wrote: > The problem appears when trying to use more than 1 interface. It gets > created correctly, but setting its MAC fails. It results in wlan0-1 > having the same MAC as wlan0 and finally having two networks (SSIDs) > using the same MAC. That obviously doesn't work. > > The error I see is: > brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 > with -52 meaning BCME_IE_NOTFOUND. I managed to find/guess what exactly BCM43602 firmware rejects. It doesn't like 2 MAC addresses that differ by the locally administrated bit only. In my case it was 00:23:6a:a3:7d:95 + 02:23:6a:a3:7d:95. When I change MAC addresses to some other combination, e.g.: 00:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96 02:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96 it works correctly. Any idea why Broadcom driver/firmware team decided to reject MAC address that differ by locally administrated bit only from the already used one? I don't think there is anything wrong with that in general. Is there a chance to release fixed firmware? -- 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
[PATCH 0/6] ath10k: random fixes 2015-07-09
I've done most of the patches while testing P2P but they aren't limited to that scope. There are no inter-dependencies within the patchset so single patches should be easily cherry-pickable in case, e.g. some patches raise concerns or are decided to be dropped during review. Michal Kazior (6): ath10k: don't set cck/ofdm scan flags ath10k: limit multi-vif ps more aggresivelly ath10k: fix hw roc expiration notifcation ath10k: update vdev ps state on start ath10k: fix per-vif queue locking ath10k: tweak interface combinations drivers/net/wireless/ath/ath10k/core.h| 1 + drivers/net/wireless/ath/ath10k/mac.c | 115 ++ drivers/net/wireless/ath/ath10k/mac.h | 6 +- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 32 +++-- drivers/net/wireless/ath/ath10k/wmi.c | 1 - 5 files changed, 99 insertions(+), 56 deletions(-) -- 2.1.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 3/6] ath10k: fix hw roc expiration notifcation
The expiration function must not be called when roc is explicitly cancelled by mac80211. However since fcf9844636be ("ath10k: fix hw roc expiration") the notification was never sent when roc actually expired. This fixes some P2P connection setup issues. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/core.h | 1 + drivers/net/wireless/ath/ath10k/mac.c | 12 +--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 2e5c935579c4..78e07051b897 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -633,6 +633,7 @@ struct ath10k { bool is_roc; int vdev_id; int roc_freq; + bool roc_notify; } scan; struct { diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 115889cb0ff6..a060b7708f4a 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3449,14 +3449,13 @@ void __ath10k_scan_finish(struct ath10k *ar) case ATH10K_SCAN_IDLE: break; case ATH10K_SCAN_RUNNING: - if (ar->scan.is_roc) - ieee80211_remain_on_channel_expired(ar->hw); - /* fall through */ case ATH10K_SCAN_ABORTING: if (!ar->scan.is_roc) ieee80211_scan_completed(ar->hw, (ar->scan.state == ATH10K_SCAN_ABORTING)); + else if (ar->scan.roc_notify) + ieee80211_remain_on_channel_expired(ar->hw); /* fall through */ case ATH10K_SCAN_STARTING: ar->scan.state = ATH10K_SCAN_IDLE; @@ -5459,6 +5458,7 @@ static int ath10k_remain_on_channel(struct ieee80211_hw *hw, ar->scan.is_roc = true; ar->scan.vdev_id = arvif->vdev_id; ar->scan.roc_freq = chan->center_freq; + ar->scan.roc_notify = true; ret = 0; break; case ATH10K_SCAN_STARTING: @@ -5522,7 +5522,13 @@ static int ath10k_cancel_remain_on_channel(struct ieee80211_hw *hw) struct ath10k *ar = hw->priv; mutex_lock(&ar->conf_mutex); + + spin_lock_bh(&ar->data_lock); + ar->scan.roc_notify = false; + spin_unlock_bh(&ar->data_lock); + ath10k_scan_abort(ar); + mutex_unlock(&ar->conf_mutex); cancel_delayed_work_sync(&ar->scan.timeout); -- 2.1.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 6/6] ath10k: tweak interface combinations
Concurrent AP/GO operation on different channels isn't really supported well by the firmware so it's better to remove it from being advertised. Also tune the way station and p2p client interface limits are expressed to allow station + 2x p2p client or station + p2p client + p2p go. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/mac.c | 39 ++- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 0ef568c36db9..c41b34843a82 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -6557,8 +6557,11 @@ static const struct ieee80211_iface_combination ath10k_10x_if_comb[] = { static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = { { .max = 2, - .types = BIT(NL80211_IFTYPE_STATION) | -BIT(NL80211_IFTYPE_AP) | + .types = BIT(NL80211_IFTYPE_STATION), + }, + { + .max = 2, + .types = BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_P2P_CLIENT) | BIT(NL80211_IFTYPE_P2P_GO), }, @@ -6568,6 +6571,26 @@ static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = { }, }; +static const struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = { + { + .max = 2, + .types = BIT(NL80211_IFTYPE_STATION), + }, + { + .max = 2, + .types = BIT(NL80211_IFTYPE_P2P_CLIENT), + }, + { + .max = 1, + .types = BIT(NL80211_IFTYPE_AP) | +BIT(NL80211_IFTYPE_P2P_GO), + }, + { + .max = 1, + .types = BIT(NL80211_IFTYPE_P2P_DEVICE), + }, +}; + static const struct ieee80211_iface_limit ath10k_tlv_if_limit_ibss[] = { { .max = 1, @@ -6586,7 +6609,7 @@ static struct ieee80211_iface_combination ath10k_tlv_if_comb[] = { { .limits = ath10k_tlv_if_limit, .num_different_channels = 1, - .max_interfaces = 3, + .max_interfaces = 4, .n_limits = ARRAY_SIZE(ath10k_tlv_if_limit), }, { @@ -6600,9 +6623,15 @@ static struct ieee80211_iface_combination ath10k_tlv_if_comb[] = { static struct ieee80211_iface_combination ath10k_tlv_qcs_if_comb[] = { { .limits = ath10k_tlv_if_limit, + .num_different_channels = 1, + .max_interfaces = 4, + .n_limits = ARRAY_SIZE(ath10k_tlv_if_limit), + }, + { + .limits = ath10k_tlv_qcs_if_limit, .num_different_channels = 2, - .max_interfaces = 3, - .n_limits = ARRAY_SIZE(ath10k_tlv_if_limit), + .max_interfaces = 4, + .n_limits = ARRAY_SIZE(ath10k_tlv_qcs_if_limit), }, { .limits = ath10k_tlv_if_limit_ibss, -- 2.1.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 1/6] ath10k: don't set cck/ofdm scan flags
mac80211 already does provide complete IEs for Probe Requests for hw scan and ath10k firmware was appending duplicate Supported Rates IEs unnecessarily. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/mac.c | 3 --- drivers/net/wireless/ath/ath10k/wmi.c | 1 - 2 files changed, 4 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index b5b74e84ad16..63c59593494e 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4641,9 +4641,6 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw, arg.vdev_id = arvif->vdev_id; arg.scan_id = ATH10K_SCAN_ID; - if (!req->no_cck) - arg.scan_ctrl_flags |= WMI_SCAN_ADD_CCK_RATES; - if (req->ie_len) { arg.ie_len = req->ie_len; memcpy(arg.ie, req->ie, arg.ie_len); diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index 638332e96931..0791a4336e80 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -5180,7 +5180,6 @@ void ath10k_wmi_start_scan_init(struct ath10k *ar, | WMI_SCAN_EVENT_BSS_CHANNEL | WMI_SCAN_EVENT_FOREIGN_CHANNEL | WMI_SCAN_EVENT_DEQUEUED; - arg->scan_ctrl_flags |= WMI_SCAN_ADD_OFDM_RATES; arg->scan_ctrl_flags |= WMI_SCAN_CHAN_STAT_EVENT; arg->n_bssids = 1; arg->bssids[0].bssid = "\xFF\xFF\xFF\xFF\xFF\xFF"; -- 2.1.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/6] ath10k: update vdev ps state on start
Psmode can be forcefully enabled when vdev isn't started. It isn't guaranteed that mac80211 will re-issue psmode setting after vdev is started unless actual bss_conf.ps value has changed. Even if this doesn't fix any problems now it may prevent future breakage. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/mac.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index a060b7708f4a..e25e6a8f44a5 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -6222,6 +6222,13 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw, arvif->is_started = true; + ret = ath10k_mac_vif_setup_ps(arvif); + if (ret) { + ath10k_warn(ar, "failed to update vdev %i ps: %d\n", + arvif->vdev_id, ret); + goto err_stop; + } + if (vif->type == NL80211_IFTYPE_MONITOR) { ret = ath10k_wmi_vdev_up(ar, arvif->vdev_id, 0, vif->addr); if (ret) { @@ -6239,6 +6246,7 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw, err_stop: ath10k_vdev_stop(arvif); arvif->is_started = false; + ath10k_mac_vif_setup_ps(arvif); err: mutex_unlock(&ar->conf_mutex); -- 2.1.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 2/6] ath10k: limit multi-vif ps more aggresivelly
Further testing proved that multi-channel AP+STA on QCA6174 with RM.2.0-00088 should have powersave force-disabled to avoid beacon misses/skipping on either side which in turn could disrupt communication. Since AP never has arvif->ps don't even bother checking it. Other combinations may be broken as well so disallow powersave with multivif outright unless firmware advertises otherwise. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/mac.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 63c59593494e..115889cb0ff6 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -1668,7 +1668,7 @@ static int ath10k_mac_vif_recalc_ps_poll_count(struct ath10k_vif *arvif) return 0; } -static int ath10k_mac_ps_vif_count(struct ath10k *ar) +static int ath10k_mac_num_vifs_started(struct ath10k *ar) { struct ath10k_vif *arvif; int num = 0; @@ -1676,7 +1676,7 @@ static int ath10k_mac_ps_vif_count(struct ath10k *ar) lockdep_assert_held(&ar->conf_mutex); list_for_each_entry(arvif, &ar->arvifs, list) - if (arvif->ps) + if (arvif->is_started) num++; return num; @@ -1700,7 +1700,7 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif) enable_ps = arvif->ps; - if (enable_ps && ath10k_mac_ps_vif_count(ar) > 1 && + if (enable_ps && ath10k_mac_num_vifs_started(ar) > 1 && !test_bit(ATH10K_FW_FEATURE_MULTI_VIF_PS_SUPPORT, ar->fw_features)) { ath10k_warn(ar, "refusing to enable ps on vdev %i: not supported by fw\n", -- 2.1.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 5/6] ath10k: fix per-vif queue locking
Whenever any vdev was supposed to be paused all Tx queues were stopped (except offchannel) instead of only these associated with the given vdev. This caused subtle issues with multi-channel/multi-vif scenarios, e.g. authentication of station vif could sometimes fail depending on fw tx pause request timing. Fixes: b4aa539dd8f2 ("ath10k: implement tx pause wmi event") Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/mac.c | 47 +-- drivers/net/wireless/ath/ath10k/mac.h | 6 ++-- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 32 + 3 files changed, 44 insertions(+), 41 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index e25e6a8f44a5..0ef568c36db9 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3034,38 +3034,16 @@ static void ath10k_mac_vif_handle_tx_pause(struct ath10k_vif *arvif, lockdep_assert_held(&ar->htt.tx_lock); - switch (pause_id) { - case WMI_TLV_TX_PAUSE_ID_MCC: - case WMI_TLV_TX_PAUSE_ID_P2P_CLI_NOA: - case WMI_TLV_TX_PAUSE_ID_P2P_GO_PS: - case WMI_TLV_TX_PAUSE_ID_AP_PS: - case WMI_TLV_TX_PAUSE_ID_IBSS_PS: - switch (action) { - case WMI_TLV_TX_PAUSE_ACTION_STOP: - ath10k_mac_vif_tx_lock(arvif, pause_id); - break; - case WMI_TLV_TX_PAUSE_ACTION_WAKE: - ath10k_mac_vif_tx_unlock(arvif, pause_id); - break; - default: - ath10k_warn(ar, "received unknown tx pause action %d on vdev %i, ignoring\n", - action, arvif->vdev_id); - break; - } + switch (action) { + case WMI_TLV_TX_PAUSE_ACTION_STOP: + ath10k_mac_vif_tx_lock(arvif, pause_id); + break; + case WMI_TLV_TX_PAUSE_ACTION_WAKE: + ath10k_mac_vif_tx_unlock(arvif, pause_id); break; - case WMI_TLV_TX_PAUSE_ID_AP_PEER_PS: - case WMI_TLV_TX_PAUSE_ID_AP_PEER_UAPSD: - case WMI_TLV_TX_PAUSE_ID_STA_ADD_BA: - case WMI_TLV_TX_PAUSE_ID_HOST: default: - /* FIXME: Some pause_ids aren't vdev specific. Instead they -* target peer_id and tid. Implementing these could improve -* traffic scheduling fairness across multiple connected -* stations in AP/IBSS modes. -*/ - ath10k_dbg(ar, ATH10K_DBG_MAC, - "mac ignoring unsupported tx pause vdev %i id %d\n", - arvif->vdev_id, pause_id); + ath10k_warn(ar, "received unknown tx pause action %d on vdev %i, ignoring\n", + action, arvif->vdev_id); break; } } @@ -3082,12 +3060,15 @@ static void ath10k_mac_handle_tx_pause_iter(void *data, u8 *mac, struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif); struct ath10k_mac_tx_pause *arg = data; + if (arvif->vdev_id != arg->vdev_id) + return; + ath10k_mac_vif_handle_tx_pause(arvif, arg->pause_id, arg->action); } -void ath10k_mac_handle_tx_pause(struct ath10k *ar, u32 vdev_id, - enum wmi_tlv_tx_pause_id pause_id, - enum wmi_tlv_tx_pause_action action) +void ath10k_mac_handle_tx_pause_vdev(struct ath10k *ar, u32 vdev_id, +enum wmi_tlv_tx_pause_id pause_id, +enum wmi_tlv_tx_pause_action action) { struct ath10k_mac_tx_pause arg = { .vdev_id = vdev_id, diff --git a/drivers/net/wireless/ath/ath10k/mac.h b/drivers/net/wireless/ath/ath10k/mac.h index b291f063705c..e3cefe4c7cfd 100644 --- a/drivers/net/wireless/ath/ath10k/mac.h +++ b/drivers/net/wireless/ath/ath10k/mac.h @@ -61,9 +61,9 @@ int ath10k_mac_vif_chan(struct ieee80211_vif *vif, void ath10k_mac_handle_beacon(struct ath10k *ar, struct sk_buff *skb); void ath10k_mac_handle_beacon_miss(struct ath10k *ar, u32 vdev_id); -void ath10k_mac_handle_tx_pause(struct ath10k *ar, u32 vdev_id, - enum wmi_tlv_tx_pause_id pause_id, - enum wmi_tlv_tx_pause_action action); +void ath10k_mac_handle_tx_pause_vdev(struct ath10k *ar, u32 vdev_id, +enum wmi_tlv_tx_pause_id pause_id, +enum wmi_tlv_tx_pause_action action); u8 ath10k_mac_hw_rate_to_idx(const struct ieee80211_supported_band *sband, u8 hw_rate); diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c index ced35a1e0675..4189d4a90ce0 100644 --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c +++ b/drivers/net/wireless/ath/ath
Re: [PATCH 11/13] wil6210: TSO implementation
On Wednesday, July 08, 2015 10:06:37 PM Emmanuel Grumbach wrote: > So your device is able to replicate and update the IP / TCP header? > I don't really follow what your device is able to do. > You seem to be cutting the frags so that their length sums up to mss. > Which hints that your device can't segment the buffer by itself. OTOH, > I don't see how you treat the IP / TCP header copy and modification. > Emmanuel: Yes, it is correct - hardware know to replicate IP/TCP header; and DMA written in such a way that I have to arrange fragments to sums up to MSS. So this code fragment is OK. We tested it with lots of traffic. However, after your comments for another code fragment, I found there is a way to do it better. I'll rework and send updated patch. Kalle: please drop this patch. The rest of patches should apply cleanly without this one. Thanks, Vladimir -- 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/2] ath9k: setup rxfilter when offchannel
Setup rxfiler correctly for offchannel ctx. This fix problem we didn't configure rxfilter, next didn't receive probe requests and next failed p2p_find. This was seen when ath9k loaded with use_chanctx=1 Signed-off-by: Janusz Dziedzic --- drivers/net/wireless/ath/ath9k/main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index 3de829f..b45084d 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c @@ -1468,6 +1468,7 @@ static void ath9k_configure_filter(struct ieee80211_hw *hw, spin_lock_bh(&sc->chan_lock); ath_for_each_chanctx(sc, ctx) ctx->rxfilter = *total_flags; + sc->offchannel.chan.rxfilter = *total_flags; spin_unlock_bh(&sc->chan_lock); ath9k_ps_wakeup(sc); -- 1.9.1 -- 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/2] ath9k: setup rxfilter for all chanctx
While mac80211 setup this per HW, set same rxfilter configuration for all chanctx. Signed-off-by: Janusz Dziedzic --- drivers/net/wireless/ath/ath9k/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index b7b77e0..3de829f 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c @@ -1459,13 +1459,15 @@ static void ath9k_configure_filter(struct ieee80211_hw *hw, u64 multicast) { struct ath_softc *sc = hw->priv; + struct ath_chanctx *ctx; u32 rfilt; changed_flags &= SUPPORTED_FILTERS; *total_flags &= SUPPORTED_FILTERS; spin_lock_bh(&sc->chan_lock); - sc->cur_chan->rxfilter = *total_flags; + ath_for_each_chanctx(sc, ctx) + ctx->rxfilter = *total_flags; spin_unlock_bh(&sc->chan_lock); ath9k_ps_wakeup(sc); -- 1.9.1 -- 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: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
On 9 July 2015 at 12:38, Rafał Miłecki wrote: > On 9 July 2015 at 09:07, Rafał Miłecki wrote: >> The problem appears when trying to use more than 1 interface. It gets >> created correctly, but setting its MAC fails. It results in wlan0-1 >> having the same MAC as wlan0 and finally having two networks (SSIDs) >> using the same MAC. That obviously doesn't work. >> >> The error I see is: >> brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 >> with -52 meaning BCME_IE_NOTFOUND. > > I managed to find/guess what exactly BCM43602 firmware rejects. It > doesn't like 2 MAC addresses that differ by the locally administrated > bit only. In my case it was 00:23:6a:a3:7d:95 + 02:23:6a:a3:7d:95. > > When I change MAC addresses to some other combination, e.g.: > 00:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96 > 02:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96 > it works correctly. Oh, it appeared to be more tricky. What BCM43602 firmware doesn't allow is using the same value in the last 2 bits for different BSSes. Few examples: 00:23:6a:a3:7d:90 + 00:23:6a:a3:7d:91 is GOOD 00:23:6a:a3:7d:90 + 00:23:6a:a3:7d:93 is GOOD 00:23:6a:a3:7d:90 + 00:23:6a:a3:7d:94 is BAD (last two bits are 0x0) 00:23:6a:a3:7d:92 + 00:23:6a:a3:7d:9a is BAD (last two bits are 0x2) What's weird, all other numbers can be used as you want: 00:23:6A:A3:7D:90 + 00:7D:A3:6A:23:92 is GOOD -- 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: [PATCH 11/13] wil6210: TSO implementation
On Thu, Jul 9, 2015 at 2:37 PM, Vladimir Kondratiev wrote: > On Wednesday, July 08, 2015 10:06:37 PM Emmanuel Grumbach wrote: >> So your device is able to replicate and update the IP / TCP header? >> I don't really follow what your device is able to do. >> You seem to be cutting the frags so that their length sums up to mss. >> Which hints that your device can't segment the buffer by itself. OTOH, >> I don't see how you treat the IP / TCP header copy and modification. >> > Emmanuel: > Yes, it is correct - hardware know to replicate IP/TCP header; and > DMA written in such a way that I have to arrange fragments to > sums up to MSS. Ok - thanks for clarifying this. > > So this code fragment is OK. We tested it with lots of traffic. > However, after your comments for another code fragment, > I found there is a way to do it better. I'll rework and send updated patch. > I am working on something similar but our hardware does nothing for us. I hope to send my version next week as an RFC. > Kalle: please drop this patch. The rest of patches should apply cleanly > without this one. > > Thanks, Vladimir -- 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: Association race when acting as AP?
On 7 July 2015 at 17:00, Jouni Malinen wrote: > On Thu, Jul 02, 2015 at 10:24:33AM +0200, Michal Kazior wrote: >> After looking into hostapd code I noticed something strange and I wonder if >> anyone else is already aware of this problem: >> >> 1. AP starts >> 2. STA->AP auth OTA >> 3. AP->STA auth OTA >> 4. STA->AP assoc req OTA >> 5. AP->STA assoc resp OTA >> 6. STA sends NullFunc with "STA will go to sleep" bit set >> 7. AP driver/device sees a frame from with unknown TA/SA and issues Deauth >> w/ Reason 7 >>(this Deauth doesn't originate from hostapd; it comes from the device FW >> in my case) > > If there is a driver or firmware design that sends these > Deauthentication frames on their own, they better be able to handle race > conditions and enable this functionality at the correct time.. At least one ath10k qca61x4 firmware seems to send Deauth when it gets a NullFunc from DA which doesn't have an internal peer entry. It doesn't seem to care whether peer is authenticated or associated though. Probably having none->auth, auth->assoc state transitions (instead of a single none->assoc) would be enough - at least for ath10k today. > Sure, > cfg80211 and hostapd may need modifications to make this work better, > but this needs to be done for things to work properly. There's a good > reason for hostapd having code to check the internal STA associated > flag before triggering deauthentication based on EVENT_RX_FROM_UNKNOWN > events.. > >> To me this looks like a race in hostapd. The station should be installed to >> driver _before_ sending Assoc Resp frame, not after. My quick-n-dirty hack >> seems to help: > > Adding a STA entry before sending Association Response frame would be > fine, but this change would do more: it would claim that STA entry to be > in associated state. That is not correct from the IEEE 802.11 standard > view point. On the AP side, a STA becomes associated when an ACK frame > to the (Re)Association Response frame is received by the AP. This seems pretty racy inherently. Driver/firmware actually needs to be aware of this requirement and make sure to avoid reordering Tx ACK processing and Rx. Since Tx/Rx engines are often (if not always?) independent of each other I imagine this could be a common problem across many devices today but perhaps not easily observable due to narrow time window this could happen in. Anyway - thank you for your great insight! Michał -- 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] brcmfmac: set wiphy's addr_mask to force using valid MACs
Broadcom's firmware requires every BSS to use MAC address with unique last 2 bits. Otherwise it rejects submitted MAC which results in: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 Set addr_mask properly to hint only last 2 bits can be modified. This isn't exactly true as all bits can be changed but that's the only way to force unique values in the last 2 bits. Signed-off-by: Rafał Miłecki --- drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c index d86d1f1..4ab1d92 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c @@ -6100,6 +6100,11 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr, return NULL; } memcpy(wiphy->perm_addr, drvr->mac, ETH_ALEN); + /* Firmware requires last 2 bits to contain unique value for every BSS. +* Unfortunately this will also disallow changing other bits (firmware +* supports it as long as last 2 bits are unique) but it's the only way. +*/ + wiphy->addr_mask[ETH_ALEN - 1] = 0x02; set_wiphy_dev(wiphy, busdev); cfg = wiphy_priv(wiphy); -- 1.8.4.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] net: wireless: reduce log level of CRDA related messages
With a basic Linux userspace, the messages "Calling CRDA to update world regulatory domain" appears 10 times after boot every second or so, followed by a final "Exceeded CRDA call max attempts. Not calling CRDA". For those of us not having the corresponding userspace parts, having those messages repeatedly displayed at boot time is a bit annoying, so this commit reduces their log level to pr_debug(). Signed-off-by: Thomas Petazzoni --- net/wireless/reg.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index d359e06..29134c8 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -544,15 +544,15 @@ static int call_crda(const char *alpha2) reg_regdb_query(alpha2); if (reg_crda_timeouts > REG_MAX_CRDA_TIMEOUTS) { - pr_info("Exceeded CRDA call max attempts. Not calling CRDA\n"); + pr_debug("Exceeded CRDA call max attempts. Not calling CRDA\n"); return -EINVAL; } if (!is_world_regdom((char *) alpha2)) - pr_info("Calling CRDA for country: %c%c\n", + pr_debug("Calling CRDA for country: %c%c\n", alpha2[0], alpha2[1]); else - pr_info("Calling CRDA to update world regulatory domain\n"); + pr_debug("Calling CRDA to update world regulatory domain\n"); return kobject_uevent_env(®_pdev->dev.kobj, KOBJ_CHANGE, env); } -- 2.4.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: Kernel BUG in rtl92s_phy_chk_fwcmd_iodone():<0-0> Set FW Cmd fail
On Tuesday, July 07, 2015 11:56:21 PM Szőts Ákos wrote: > I have an RTL8191SU 802.11n USB WLAN Adapter with rtl8192su driver. > Unfortunately, I have to turn it off and on sometimes to make it work. I use > NetworkManager with KDE 5 nm-applet in which I simply turn off the wireless > capability then on again. > > Once I did this, I got a kernel BUG. Here is the link for the full text: > http://paste.opensuse.org/view/simple/25089935 This message lets you know that a firmware command has timed out. A call trace is included to let you know what the driver was doing at the time. If this problem bothers you, the information from the trace should help to debug it and make a patch. > kernel: rtl8192s_common:rtl92s_phy_chk_fwcmd_iodone():<0-0> Set FW Cmd fail!! > kernel: [ cut here ] > kernel: WARNING: CPU: 3 PID: 1105 at > /home/aki/temp/rtl8192su/rtlwifi/rtl8192s/phy_common.c:1192 > rtl92s_phy_chk_fwcmd_iodone+0x65/0xb0 [rtl8192s_common]() > kernel: Modules linked in: rtl8192su(O) rtl8192s_common(O) rtl_usb(O) > rtlwifi(O)... > kernel: Call Trace: > kernel: [] dump_stack+0x4c/0x6e > kernel: [] warn_slowpath_common+0x8a/0xc0 > kernel: [] warn_slowpath_null+0x1a/0x20 > kernel: [] rtl92s_phy_chk_fwcmd_iodone+0x65/0xb0 > [rtl8192s_common] > kernel: [] _rtl92s_phy_set_fwcmd_io+0xe1/0x670 > [rtl8192s_common] > kernel: [] rtl92s_phy_set_fw_cmd+0xb9/0x7b0 > [rtl8192s_common] > kernel: [] rtl92s_phy_scan_operation_backup+0x3a/0x90 > [rtl8192s_common] > kernel: [] rtl_op_sw_scan_start+0xa9/0x170 [rtlwifi] Regards, Christian -- 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: wireless-regdb: update CA rules for 5600 - 5650 mHz
On Wed, Jul 08, 2015 at 12:19:18PM +0200, Zefir Kurtisi wrote: > My claim is that in its current state the regdb does not exactly formalize the > limitations given by regulatory for a simple reason: it uses channel semantics > where it should only handle frequency ranges. Take the discussed rules for CA > at > hand: while the linked document considers frequencies from 5150 to 5350, the > according rule for CA is defined as (5170 - 5250 @ 80). Why 5170 instead of > 5150? > Because we know there is no channel defined below 5170 - but why do we need to > embed this information as a rule when it is already handled by SW? > > In the current regdb, both semantics are used, e.g. UA (5150-5350) vs. CA > (5170-5250) or ES (5470-5725) vs. FI (5490-5710)). I'm not surprised. I don't know that anyone has given it that much thought before. > This might sound like an irrelevant difference, but here is why it matters: > the > above mentioned rules for ES and FI would give the same channel lists - as > long as > we think in HT20 and HT40. But only ES gives access to 10 and 5MHz operation > on > channel 144. Good example. > My bottom line is: regulatory rules must not contain channel semantics - this > is > done by the SW. Rules must be a literal formalization of the country's > regulatory, > which always uses frequency ranges within defined band edges. I'm generally in agreement. I'll try to pay closer attention to this in the future. > Sorry for this going off-topic. It has nothing to do with the changes > proposed by > Wei, but is more about something to keep in mind when considering upcoming > support > for narrow band channels at band edges. Except that it seems to have inspired Wei to change the patch to do exactly what you're arguing against ;-) Seth -- 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: set wiphy's addr_mask to force using valid MACs
On 9 July 2015 at 14:46, Rafał Miłecki wrote: > Broadcom's firmware requires every BSS to use MAC address with unique > last 2 bits. Otherwise it rejects submitted MAC which results in: > brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 > > Set addr_mask properly to hint only last 2 bits can be modified. This > isn't exactly true as all bits can be changed but that's the only way > to force unique values in the last 2 bits. I asked Felix about this and he pointed it may be not a good idea to disallow using locally administrated bit. I'll rework my fix to provide a full list of addresses that shall be used. Please drop this one. -- 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] brcmfmac: set wiphy's addresses to provide valid MACs
Broadcom's firmware requires every BSS to use MAC address with unique last few bits. The amount of bits may depend on a particular firmware, it was verified to be 2 for BCM43602 one. If this condition won't be fulfilled firmware will reject such MAC: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 We don't want to simply set addr_mask as it would also disallow using locally administrated bit. Instead let's build a list of addresses manually enabling 0x2 bit for extra interfaces. Signed-off-by: Rafał Miłecki --- drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 14 ++ drivers/net/wireless/brcm80211/brcmfmac/core.h | 3 +++ 2 files changed, 17 insertions(+) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c index d86d1f1..ffe5260 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c @@ -5785,6 +5785,7 @@ static void brcmf_wiphy_wowl_params(struct wiphy *wiphy) static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp) { + struct brcmf_pub *drvr = ifp->drvr; struct ieee80211_supported_band *band; __le32 bandlist[3]; u32 n_bands; @@ -5798,6 +5799,19 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp) if (err) return err; + for (i = 0; i < wiphy->iface_combinations->max_interfaces && +i < ARRAY_SIZE(drvr->addresses); i++) { + u8 *addr = drvr->addresses[i].addr; + + memcpy(addr, drvr->mac, ETH_ALEN); + if (i) { + addr[0] |= BIT(1); + addr[ETH_ALEN - 1] ^= i; + } + } + wiphy->addresses = drvr->addresses; + wiphy->n_addresses = i; + wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM; wiphy->cipher_suites = __wl_cipher_suites; wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites); diff --git a/drivers/net/wireless/brcm80211/brcmfmac/core.h b/drivers/net/wireless/brcm80211/brcmfmac/core.h index fd74a9c..7463041 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/core.h +++ b/drivers/net/wireless/brcm80211/brcmfmac/core.h @@ -21,6 +21,7 @@ #ifndef BRCMFMAC_CORE_H #define BRCMFMAC_CORE_H +#include #include "fweh.h" #define TOE_TX_CSUM_OL 0x0001 @@ -118,6 +119,8 @@ struct brcmf_pub { /* Multicast data packets sent to dongle */ unsigned long tx_multicast; + struct mac_address addresses[BRCMF_MAX_IFS]; + struct brcmf_if *iflist[BRCMF_MAX_IFS]; struct mutex proto_block; -- 1.8.4.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] wireless-regdb: Update regulatory rules for Taiwan (TW)
On Wed, Jul 08, 2015 at 11:07:20AM +0800, Chen-Yu Tsai wrote: > > Thanks. I think there should be a written document about what the > > rules should be like, or what is expected: > > > > 1. WiFi channel boundaries or band boundaries > > 2. peak output power or peak power spectral density > > > > In http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000856.html > > you mentioned the software is smart enough to work out how to combine > > different bands and what channels to use, so I see no reason to explicitly > > chop up contiguous spectrum, unless there are explicit rules forbidding > > combined use of bands with different regulatory rules. AFAIK the FCC > > only requires one to satisfy all rules when usage crosses band boundaries. > > > > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000857.html > > also raises a similar question. I was really commenting about the transmit power updates in your patch. I just compared the frequency changes to the documentation you linked to and those do look okay to me. > >> I would however consider an update for 5.15-5.25 GHz and 5.6-5.65 GHz > >> provided that there's official documentation to substantiate the change. > >> I unfortunately cannot read Chinese, so I would need some assistance to > >> confirm the documentation. > > > > I could possibly ask around, though I'm not optimistic. The "official" > > documents are just transcripts from NCC hosted Q&A sessions regarding > > the latest regulations. Proposals/questions are submitted by vendors, > > and the NCC responds and puts together an aggregated transcript. > > Just got off the phone with the NCC. Their position is, spectrum allocation > is not within their purview, but the Ministry of Transportation and > Communications. As noted in the patch, they have already opened up the > spectrum to U-NII and low power radio usage. What remains is that the > NCC revise its testing standards. Until then, their position is that, > since their testing standards are modeled after FCC standards, vendors > can just test under FCC standards, then convert the reports into LP0002 > format, and cite the FCC test report. > > There is no formal English version of the Q&A transcript, at least not > until some foreign testing body requests it. The person in charge just > asked me to translate it myself... If you send a patch which updates only the frequencies I would likely apply that after allowing a week or so for others to either ack or nack it (and running the stuff you linked to through google translate and seeing if I could make any sense of the output). I think the power updates are probably based on a misunderstanding, and may not even be completely correct. For the most part after they've been converted to EIRP (eirp = 10 * log10(mW)) they don't turn out to be substantially different than what we have now. I think the value in 5250-5350 MHz is probably incorrect however. Based on my quick skim of the document you linked to it should be 50 mW rather than 250. 50 mW also roughly matches to the 17 dBm which is in the database today, whereas 250 mW is closer to 24 dBm. My suggestion would be update the frequencies but not the existing transmit power limits, unless you discover that any of the power limits are definitely incorrect. Thanks, Seth -- 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 v5] Add new mac80211 driver mwlwifi.
On Fri, 2015-07-03 at 06:10 +, David Lin wrote: Hello, > The Linux driver for WRT1900AC. The work was initially developed as > part of openwrt effort and maintained on > https://github.com/kaloz/mwlwifi. I see *massive* code duplication with the mwl8k driver. This is, I guess, not a surprise since the supported chipset are an evolution of the ones supported by mwl8k, just look at how close/similar the descriptor format is. The problem is that each new Marvell chipset comes with a new firmware version, and there is no effort to have a common firmware API or code base that supports multiple chipsets. That pushes the bloat on the kernel side, do we really agree on that ? -- Maxime -- 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 v2] staging: vt6655: Fix missing power saving support
Add IEEE80211_HW_SUPPORTS_PS to ieee80211_hw flags enabling this feature. Signed-off-by: Malcolm Priestley --- v2 rebased for 4.2 drivers/staging/vt6655/device_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c index b0c8e23..e78bd5e 100644 --- a/drivers/staging/vt6655/device_main.c +++ b/drivers/staging/vt6655/device_main.c @@ -1811,6 +1811,7 @@ vt6655_probe(struct pci_dev *pcid, const struct pci_device_id *ent) ieee80211_hw_set(priv->hw, SIGNAL_DBM); ieee80211_hw_set(priv->hw, RX_INCLUDES_FCS); ieee80211_hw_set(priv->hw, REPORTS_TX_ACK_STATUS); + ieee80211_hw_set(priv->hw, SUPPORTS_PS); priv->hw->max_signal = 100; -- 2.1.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 3/4] staging: vt6655: vnt_tx_packet don't wakeup from power saving.
mac80211 changes the wake state before attempting to tx data Signed-off-by: Malcolm Priestley --- drivers/staging/vt6655/device_main.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c index e78bd5e..c245dea 100644 --- a/drivers/staging/vt6655/device_main.c +++ b/drivers/staging/vt6655/device_main.c @@ -1211,9 +1211,6 @@ static int vnt_tx_packet(struct vnt_private *priv, struct sk_buff *skb) vnt_generate_fifo_header(priv, dma_idx, head_td, skb); - if (MACbIsRegBitsOn(priv->PortOffset, MAC_REG_PSCTL, PSCTL_PS)) - MACbPSWakeup(priv->PortOffset); - spin_lock_irqsave(&priv->lock, flags); priv->bPWBitOn = false; -- 2.1.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/4] staging: vt6655: Correct listen interval TBTT wake up
PSbIsNextTBTTWakeUp is called at beacon intervals. The should listen to next beacon on count down of wake_up_count == 1. This restores this back to vendors code but modified for mac80211. Signed-off-by: Malcolm Priestley --- drivers/staging/vt6655/device.h | 1 + drivers/staging/vt6655/power.c | 16 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/staging/vt6655/device.h b/drivers/staging/vt6655/device.h index 5cf1b33..6aebb49 100644 --- a/drivers/staging/vt6655/device.h +++ b/drivers/staging/vt6655/device.h @@ -403,6 +403,7 @@ struct vnt_private { unsigned char abyEEPROM[EEP_MAX_CONTEXT_SIZE]; /* unsigned long alignment */ unsigned short wBeaconInterval; + u16 wake_up_count; struct work_struct interrupt_work; diff --git a/drivers/staging/vt6655/power.c b/drivers/staging/vt6655/power.c index be3c4e9..06e6b9d 100644 --- a/drivers/staging/vt6655/power.c +++ b/drivers/staging/vt6655/power.c @@ -157,10 +157,18 @@ PSbIsNextTBTTWakeUp( struct ieee80211_conf *conf = &hw->conf; bool bWakeUp = false; - if (conf->listen_interval == 1) { - /* Turn on wake up to listen next beacon */ - MACvRegBitsOn(pDevice->PortOffset, MAC_REG_PSCTL, PSCTL_LNBCN); - bWakeUp = true; + if (conf->listen_interval > 1) { + if (!pDevice->wake_up_count) + pDevice->wake_up_count = conf->listen_interval; + + --pDevice->wake_up_count; + + if (pDevice->wake_up_count == 1) { + /* Turn on wake up to listen next beacon */ + MACvRegBitsOn(pDevice->PortOffset, + MAC_REG_PSCTL, PSCTL_LNBCN); + bWakeUp = true; + } } return bWakeUp; -- 2.1.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 1/4] staging: vt6655: check ieee80211_bss_conf bssid not NULL
Sometimes bssid can go null on failed association. Signed-off-by: Malcolm Priestley Cc: # v3.19+ --- drivers/staging/vt6655/device_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c index ed040fb..b0c8e23 100644 --- a/drivers/staging/vt6655/device_main.c +++ b/drivers/staging/vt6655/device_main.c @@ -1418,7 +1418,7 @@ static void vnt_bss_info_changed(struct ieee80211_hw *hw, priv->current_aid = conf->aid; - if (changed & BSS_CHANGED_BSSID) { + if (changed & BSS_CHANGED_BSSID && conf->bssid) { unsigned long flags; spin_lock_irqsave(&priv->lock, flags); -- 2.1.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] staging: vt6656: check ieee80211_bss_conf bssid not NULL
Sometimes bssid can go null on failed association. Signed-off-by: Malcolm Priestley Cc: # v3.17+ --- drivers/staging/vt6656/main_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c index f97323f..af572d7 100644 --- a/drivers/staging/vt6656/main_usb.c +++ b/drivers/staging/vt6656/main_usb.c @@ -701,7 +701,7 @@ static void vnt_bss_info_changed(struct ieee80211_hw *hw, priv->current_aid = conf->aid; - if (changed & BSS_CHANGED_BSSID) + if (changed & BSS_CHANGED_BSSID && conf->bssid) vnt_mac_set_bssid_addr(priv, (u8 *)conf->bssid); -- 2.1.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: Clarification for the use of additional fields in the message body
On Wed, Jul 08, 2015 at 05:27:38PM +0200, SF Markus Elfring wrote: > > Note also that some maintainers have work flow that deliberately smash > > the date (i.e., because they are using a system such as guilt), > > so if you are depending on the submitted timestamp, it's going to > > break on you. > > Thanks for your hint. > > I am just trying to offer the possibility for the reuse of a more > precise commit timestamp together with an appropriate author mail > address for my update suggestions. > Do you reject any more such message field overrides? Well, I won't hold it against you, since I also often need to fix patches or git commit descriptions anyway. But at the same time, my workflow (which you have no right to dictate) **will** destroy your timestamp. Given that you haven't explained why you want to do this, I'm not going have much sympathy if you complain. Personally, given that you're going through some extremely baroque e-mail/patchsubmission scheme, I don't understand why you can't also arrange to override the Date field in the e-mail header. But I don't really care all that much, because I can ignore your timestamp no matter where you put it. Regards, - Ted -- 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
WARNING: brcmfmac/core.c:1144 brcmf_netdev_wait_pend8021x
Hello again. After fixing user space <-> brcmfmac communication for using valid MACs: [PATCH] brcmfmac: set wiphy's addresses to provide valid MACs i started testing multiple interfaces. It seems there are many bugs in brcmfmac :( So after running 3 AP interfaces and switching my STA device between them I started seeing WARNINGs triggered by brcmf_netdev_wait_pend8021x. It was brcmf_cfg80211_del_key that was calling above function. The problem is that brcmf_netdev_start_xmit increases interfaces's pend_8021x_cnt on every transmission of ETH_P_PAE but brcmf_txfinalize fails (from time to time?) do decrease it. There is a bug in brcmf_txfinalize that stops it from finding an interface for the received TX transmission success. I added some debugging to brcmfmac as you can see below and this is what I got: [ 39.394022] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c72c1dc0 on ifidx:0 [ 39.413251] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c72c1dc0 on ifidx:2 [ 39.421887] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c725a7c0 on ifidx:1 [ 39.431720] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c6a78a00 on ifidx:0 [ 39.442829] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 but got invalid ifidx:1 [ 39.451773] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c726ee80 on ifidx:2 [ 39.460384] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c725a7c0 on ifidx:1 [ 39.536224] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 but got invalid ifidx:1 [ 51.884737] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c714cd00 on ifidx:1 [ 51.895577] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 but got invalid ifidx:1 [ 51.904592] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c707de80 on ifidx:2 [ 51.913195] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c7011e80 on ifidx:0 [ 51.922900] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c725a280 on ifidx:1 [ 51.933988] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a280 but got invalid ifidx:1 [ 51.942979] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c714cd00 on ifidx:2 [ 51.951602] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c707de80 on ifidx:0 [ 55.228402] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4 [ 55.278395] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4 [ 55.328394] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4 [ 55.336211] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c7070b80 on ifidx:2 [ 55.347075] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c7070b80 and decreased pend_8021x_cnt for ifidx:2 but got negative count -1! [ 55.387991] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c6a78a00 on ifidx:1 [ 55.396601] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c7070b80 on ifidx:0 [ 55.406245] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c707d400 on ifidx:2 [ 55.417257] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c6a78a00 but got invalid ifidx:1 [ 55.426144] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c707d400 and decreased pend_8021x_cnt for ifidx:2 but got negative count -1! [ 55.439019] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c714cd00 on ifidx:1 [ 55.447611] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c72c2580 on ifidx:0 [ 55.498397] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:6 [ 55.504785] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 but got invalid ifidx:1 As you can see brcmf_txfinalize fails to find interface for ifidx:1. Why is that? It seems that drvr->iflist is an array indexed by bssidx, but brcmf_txfinalize uses ifidx to access it. Obviously ifidx != bssidx. This also results in decreasing pend_8021x_cnt for wrong interfaces and some negative values. Will you fix this? --- drivers/net/wireless/brcm80211/brcmfmac/core.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/core.c b/drivers/net/wireless/brcm80211/brcmfmac/core.c index 5663870..e521ce5 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/core.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/core.c @@ -238,8 +238,10 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb, goto done; } - if (eh->h_proto == htons(ETH_P_PAE)) + if (eh->h_proto == htons(ETH_P_PAE)) { + pr_info("[%s] Transmitting ETH_P_PAE skb:%p on ifidx:%d\n", __FUNCTION__, skb, ifp->ifidx); atomic_inc(&ifp->pend_8021x_cnt); + } ret = brcmf_fws_process_skb(ifp, skb); @@ -543,6 +545,8 @@ void brcmf_
Re: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
On 07/09/2015 09:07 AM, Rafał Miłecki wrote: Hey guys, I'm afraid I hit another brcmfmac bug. First of all, I implemented a trivial workaround for the previous bug reported in the: brcmfmac: one faulty "iw interface add" command breaks in-firmware BSS state See my workaround in OpenWrt git: http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=0e6c9bd9556eea98b476ad371d64d8d16e3a9f9c So now OpenWrt's user space calls using "iw" tool don't trigger brcmfmac BSSes bug anymore. I can successfully use one AP interface per device. The problem appears when trying to use more than 1 interface. It gets created correctly, but setting its MAC fails. It results in wlan0-1 having the same MAC as wlan0 and finally having two networks (SSIDs) using the same MAC. That obviously doesn't work. Can we please take one step back. I am not understanding how you guys use the multiple interfaces. The multiple AP interfaces in brcmfmac are only intended for Multiple-BSS feature as described in hostapd.conf which changes wlan0 from STA to AP and creates additional AP interfaces, but you seem to be creating an AP interface with iw next to a STA interface. I actually have patches pending that correct the announced interface combinations. I am currently on vacation as my family expanded with a baby girl. Regards, Arend The error I see is: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52 with -52 meaning BCME_IE_NOTFOUND. -- 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/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
On 07/09/2015 10:13 AM, Vineet Gupta wrote: There's already a generic implementation so use that instead. There is or there was? If there is now I am fine with this patch, but if it already was there the author might have had a reason for adding a local function and I would like to hear that reason. --- I'm not sure if the driver usage of atomic_or?() is correct in terms of storage size of @val for 64 bit arches. Assuming LP64 programming model for linux on say x86_64: atomic_or() callers in this driver use long (sana 64 bit) storage and pass it to atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ? The function is used with 32bit register value from the device so I think it is ok. Regards, Arend --- Cc: Brett Rudley Cc: Arend van Spriel Cc: "Franky (Zhenhui) Lin" Cc: Hante Meuleman Cc: Kalle Valo Cc: Pieter-Paul Giesberts Cc: Daniel Kim Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-l...@broadcom.com Cc: Peter Zijlstra Cc: Ingo Molnar Cc: net...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Vineet Gupta --- drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c index d36f5f3d931b..f990e3d0e696 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c @@ -2564,15 +2564,6 @@ static inline void brcmf_sdio_clrintr(struct brcmf_sdio *bus) } } -static void atomic_orr(int val, atomic_t *v) -{ - int old_val; - - old_val = atomic_read(v); - while (atomic_cmpxchg(v, old_val, val | old_val) != old_val) - old_val = atomic_read(v); -} - static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus) { struct brcmf_core *buscore; @@ -2595,7 +2586,7 @@ static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus) if (val) { brcmf_sdiod_regwl(bus->sdiodev, addr, val, &ret); bus->sdcnt.f1regdata++; - atomic_orr(val, &bus->intstatus); + atomic_or(val, &bus->intstatus); } return ret; @@ -2712,7 +2703,7 @@ static void brcmf_sdio_dpc(struct brcmf_sdio *bus) /* Keep still-pending events for next scheduling */ if (intstatus) - atomic_orr(intstatus, &bus->intstatus); + atomic_or(intstatus, &bus->intstatus); brcmf_sdio_clrintr(bus); -- 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/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
On 07/09/2015 08:25 PM, Arend van Spriel wrote: On 07/09/2015 10:13 AM, Vineet Gupta wrote: There's already a generic implementation so use that instead. There is or there was? If there is now I am fine with this patch, but if it already was there the author might have had a reason for adding a local function and I would like to hear that reason. Nevermind. Just noticed you are proposing the generic implementation in this series. Currently on vacation and want to discuss with Hante about this change. Regards, Arend --- I'm not sure if the driver usage of atomic_or?() is correct in terms of storage size of @val for 64 bit arches. Assuming LP64 programming model for linux on say x86_64: atomic_or() callers in this driver use long (sana 64 bit) storage and pass it to atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ? The function is used with 32bit register value from the device so I think it is ok. Regards, Arend --- Cc: Brett Rudley Cc: Arend van Spriel Cc: "Franky (Zhenhui) Lin" Cc: Hante Meuleman Cc: Kalle Valo Cc: Pieter-Paul Giesberts Cc: Daniel Kim Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-l...@broadcom.com Cc: Peter Zijlstra Cc: Ingo Molnar Cc: net...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Vineet Gupta --- drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c index d36f5f3d931b..f990e3d0e696 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c @@ -2564,15 +2564,6 @@ static inline void brcmf_sdio_clrintr(struct brcmf_sdio *bus) } } -static void atomic_orr(int val, atomic_t *v) -{ -int old_val; - -old_val = atomic_read(v); -while (atomic_cmpxchg(v, old_val, val | old_val) != old_val) -old_val = atomic_read(v); -} - static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus) { struct brcmf_core *buscore; @@ -2595,7 +2586,7 @@ static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus) if (val) { brcmf_sdiod_regwl(bus->sdiodev, addr, val, &ret); bus->sdcnt.f1regdata++; -atomic_orr(val, &bus->intstatus); +atomic_or(val, &bus->intstatus); } return ret; @@ -2712,7 +2703,7 @@ static void brcmf_sdio_dpc(struct brcmf_sdio *bus) /* Keep still-pending events for next scheduling */ if (intstatus) -atomic_orr(intstatus, &bus->intstatus); +atomic_or(intstatus, &bus->intstatus); brcmf_sdio_clrintr(bus); -- 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] brcmsmac: Use kstrdup to simplify code
On 07/08/2015 10:22 PM, Christophe JAILLET wrote: Replace a kmalloc+strcpy by an equivalent kstrdup in order to improve readability. Not sure if readability is really the issue here. At most it is a small reduction of driver code by using kstrdup(). Anyway, the patch looks fine so Acked-by: Arend van Spriel Signed-off-by: Christophe JAILLET --- v2: fix the subject drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c index 4813506..8a6c077 100644 --- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c +++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c @@ -1476,9 +1476,7 @@ struct brcms_timer *brcms_init_timer(struct brcms_info *wl, wl->timers = t; #ifdef DEBUG - t->name = kmalloc(strlen(name) + 1, GFP_ATOMIC); - if (t->name) - strcpy(t->name, name); + t->name = kstrdup(name, GFP_ATOMIC); #endif return t; -- 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: WARNING: brcmfmac/core.c:1144 brcmf_netdev_wait_pend8021x
On 07/09/2015 08:01 PM, Rafał Miłecki wrote: Hello again. After fixing user space <-> brcmfmac communication for using valid MACs: [PATCH] brcmfmac: set wiphy's addresses to provide valid MACs i started testing multiple interfaces. It seems there are many bugs in brcmfmac :( Well, you are using the device outside its capability, because brcmfmac does not properly announce interface combinations. I will submit patches for that. So after running 3 AP interfaces and switching my STA device between them I started seeing WARNINGs triggered by brcmf_netdev_wait_pend8021x. It was brcmf_cfg80211_del_key that was calling above function. The problem is that brcmf_netdev_start_xmit increases interfaces's pend_8021x_cnt on every transmission of ETH_P_PAE but brcmf_txfinalize fails (from time to time?) do decrease it. There is a bug in brcmf_txfinalize that stops it from finding an interface for the received TX transmission success. I added some debugging to brcmfmac as you can see below and this is what I got: [ 39.394022] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c72c1dc0 on ifidx:0 [ 39.413251] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c72c1dc0 on ifidx:2 [ 39.421887] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c725a7c0 on ifidx:1 [ 39.431720] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c6a78a00 on ifidx:0 [ 39.442829] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 but got invalid ifidx:1 [ 39.451773] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c726ee80 on ifidx:2 [ 39.460384] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c725a7c0 on ifidx:1 [ 39.536224] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 but got invalid ifidx:1 [ 51.884737] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c714cd00 on ifidx:1 [ 51.895577] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 but got invalid ifidx:1 [ 51.904592] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c707de80 on ifidx:2 [ 51.913195] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c7011e80 on ifidx:0 [ 51.922900] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c725a280 on ifidx:1 [ 51.933988] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a280 but got invalid ifidx:1 [ 51.942979] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c714cd00 on ifidx:2 [ 51.951602] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c707de80 on ifidx:0 [ 55.228402] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4 [ 55.278395] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4 [ 55.328394] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4 [ 55.336211] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c7070b80 on ifidx:2 [ 55.347075] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c7070b80 and decreased pend_8021x_cnt for ifidx:2 but got negative count -1! [ 55.387991] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c6a78a00 on ifidx:1 [ 55.396601] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c7070b80 on ifidx:0 [ 55.406245] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c707d400 on ifidx:2 [ 55.417257] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c6a78a00 but got invalid ifidx:1 [ 55.426144] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c707d400 and decreased pend_8021x_cnt for ifidx:2 but got negative count -1! [ 55.439019] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c714cd00 on ifidx:1 [ 55.447611] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE skb:c72c2580 on ifidx:0 [ 55.498397] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:6 [ 55.504785] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 but got invalid ifidx:1 As you can see brcmf_txfinalize fails to find interface for ifidx:1. Why is that? It seems that drvr->iflist is an array indexed by bssidx, but brcmf_txfinalize uses ifidx to access it. Obviously ifidx != bssidx. This also results in decreasing pend_8021x_cnt for wrong interfaces and some negative values. Will you fix this? I have some patches reworking the driver using drvr->iflist. One of the fixes involves calling brcmf_txfinalize with brcmf_if instance. I need to do more testing on those patches before submitting them. If you are willing to give them a try as well I can provide them. Regards, Arend --- drivers/net/wireless/brcm80211/brcmfmac/core.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/core.c b/drivers/net/wireless/brcm80211/brcmfmac/core.c index 5663870..e521ce5 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/core.c +++ b/drivers/net/
Re: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
On 9 July 2015 at 20:08, Arend van Spriel wrote: > On 07/09/2015 09:07 AM, Rafał Miłecki wrote: >> >> Hey guys, I'm afraid I hit another brcmfmac bug. >> >> First of all, I implemented a trivial workaround for the previous bug >> reported in the: >> brcmfmac: one faulty "iw interface add" command breaks in-firmware BSS >> state >> See my workaround in OpenWrt git: >> >> http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=0e6c9bd9556eea98b476ad371d64d8d16e3a9f9c >> >> So now OpenWrt's user space calls using "iw" tool don't trigger >> brcmfmac BSSes bug anymore. I can successfully use one AP interface >> per device. >> >> The problem appears when trying to use more than 1 interface. It gets >> created correctly, but setting its MAC fails. It results in wlan0-1 >> having the same MAC as wlan0 and finally having two networks (SSIDs) >> using the same MAC. That obviously doesn't work. > > > Can we please take one step back. I am not understanding how you guys use > the multiple interfaces. The multiple AP interfaces in brcmfmac are only > intended for Multiple-BSS feature as described in hostapd.conf which changes > wlan0 from STA to AP and creates additional AP interfaces, but you seem to > be creating an AP interface with iw next to a STA interface. OpenWrt tries to remove all existing interfaces and then create needed ones from the scratch. So e.g. after loading brcmfmac you have: wlan0 Lets say OpenWrt wants 2 AP interfaces, so it calls: iw dev wlan0 del iw phy phy0 interface add wlan0 type __ap iw phy phy0 interface add wlan0-1 type __ap The first command fails (brcmfmac limitation), the second one gets rejected (wlan0 already exists) and the third one creates new virtual interface. This results in having two interfaces: STA and AP. Then OpenWrt finally runs hostapd which changes wlan0 to AP and starts AP on both interfaces. > I actually have patches pending that correct the announced interface > combinations. I am currently on vacation as my family expanded with a baby > girl. Have fun! :) -- 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: WARNING: brcmfmac/core.c:1144 brcmf_netdev_wait_pend8021x
On 9 July 2015 at 20:48, Arend van Spriel wrote: > On 07/09/2015 08:01 PM, Rafał Miłecki wrote: >> After fixing user space <-> brcmfmac communication for using valid MACs: >> [PATCH] brcmfmac: set wiphy's addresses to provide valid MACs >> i started testing multiple interfaces. >> >> It seems there are many bugs in brcmfmac :( > > > Well, you are using the device outside its capability, because brcmfmac does > not properly announce interface combinations. I will submit patches for > that. Really? I'm just running 3 interfaces, all of them in AP mode, nothing unexpected I believe. >> So after running 3 AP interfaces and switching my STA device between them >> I >> started seeing WARNINGs triggered by brcmf_netdev_wait_pend8021x. It was >> brcmf_cfg80211_del_key that was calling above function. >> >> The problem is that brcmf_netdev_start_xmit increases interfaces's >> pend_8021x_cnt on every transmission of ETH_P_PAE but brcmf_txfinalize >> fails >> (from time to time?) do decrease it. >> >> There is a bug in brcmf_txfinalize that stops it from finding an interface >> for >> the received TX transmission success. I added some debugging to brcmfmac >> as you >> can see below and this is what I got: >> [ 39.394022] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c72c1dc0 on ifidx:0 >> [ 39.413251] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c72c1dc0 on ifidx:2 >> [ 39.421887] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c725a7c0 on ifidx:1 >> [ 39.431720] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c6a78a00 on ifidx:0 >> [ 39.442829] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c725a7c0 but got invalid ifidx:1 >> [ 39.451773] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c726ee80 on ifidx:2 >> [ 39.460384] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c725a7c0 on ifidx:1 >> [ 39.536224] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c725a7c0 but got invalid ifidx:1 >> [ 51.884737] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c714cd00 on ifidx:1 >> [ 51.895577] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c714cd00 but got invalid ifidx:1 >> [ 51.904592] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c707de80 on ifidx:2 >> [ 51.913195] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c7011e80 on ifidx:0 >> [ 51.922900] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c725a280 on ifidx:1 >> [ 51.933988] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c725a280 but got invalid ifidx:1 >> [ 51.942979] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c714cd00 on ifidx:2 >> [ 51.951602] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c707de80 on ifidx:0 >> [ 55.228402] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING >> pend_8021x_cnt:4 >> [ 55.278395] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING >> pend_8021x_cnt:4 >> [ 55.328394] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING >> pend_8021x_cnt:4 >> [ 55.336211] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c7070b80 on ifidx:2 >> [ 55.347075] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c7070b80 and decreased pend_8021x_cnt for ifidx:2 but got negative count >> -1! >> [ 55.387991] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c6a78a00 on ifidx:1 >> [ 55.396601] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c7070b80 on ifidx:0 >> [ 55.406245] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c707d400 on ifidx:2 >> [ 55.417257] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c6a78a00 but got invalid ifidx:1 >> [ 55.426144] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c707d400 and decreased pend_8021x_cnt for ifidx:2 but got negative count >> -1! >> [ 55.439019] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c714cd00 on ifidx:1 >> [ 55.447611] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE >> skb:c72c2580 on ifidx:0 >> [ 55.498397] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING >> pend_8021x_cnt:6 >> [ 55.504785] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE >> skb:c714cd00 but got invalid ifidx:1 >> >> As you can see brcmf_txfinalize fails to find interface for ifidx:1. Why >> is >> that? It seems that drvr->iflist is an array indexed by bssidx, but >> brcmf_txfinalize uses ifidx to access it. Obviously ifidx != bssidx. >> >> This also results in decreasing pend_8021x_cnt for wrong interfaces and >> some >> negative values. >> >> Will you fix this? > > > I have some patches reworking the driver using drvr->iflist. One of the > fixes involves calling brcmf_txfinalize with brcmf_if instance. I need to do > more testing on those patches before submitting them. If you are willing to > give them a try as
Re: [PATCH v2 3/3] mac80211: select an AID when creating new mesh STAs
On Fri, Jul 3, 2015 at 3:41 PM, Bob Copeland wrote: > Instead of using peer link id for AID, generate a new > AID when creating mesh STAs in the kernel peering manager. I missed a case where llid was used for aid in ieee80211_mps_frame_release() -- will send a v3 for the series. -- Bob Copeland %% www.bobcopeland.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 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
On Thu, Jul 09, 2015 at 08:31:16PM +0200, Arend van Spriel wrote: > >There is or there was? If there is now I am fine with this patch, but if > >it already was there the author might have had a reason for adding a > >local function and I would like to hear that reason. > > Nevermind. Just noticed you are proposing the generic implementation in this > series. Currently on vacation and want to discuss with Hante about this > change. No there is one in linux/atomic.h, he just renamed the #ifdef guard and provided a 'sane' implementation for his arch. -- 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
How is AP supposed to handle power-save packets from peer?
Suppose one is doing heavy download (AP -> peer traffic), and there are lots of frames in the NIC's tx buffers (ath10k firmware, in this case). Then, peer sends a power-save pkt telling AP it is going off-channel or otherwise will be unavailable. What is the appropriate behaviour from the AP? Can the firmware just drop all those tx frames to make room to handle other stations? Maybe report ACK failure and hope the upper level stacks retransmit as appropriate? Or, is the host supposed to flush the peer's packets to clear out the frames? Or, is firmware somehow supposed to keep all the frames for when the peer comes back? 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 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
On Thursday 09 July 2015 11:55 PM, Arend van Spriel wrote: > On 07/09/2015 10:13 AM, Vineet Gupta wrote: >> > There's already a generic implementation so use that instead. > There is or there was? If there is now I am fine with this patch, but if > it already was there the author might have had a reason for adding a > local function and I would like to hear that reason. > atomic_orr() was introduced to this driver with 2014-03-06 5cbb9c285bdc brcmfmac: Use atomic functions for intstatus update. as it seems atomic_set_mask() was not available cross arch. And atomic_or() in generic code was indeed introduced after that 2014-04-23 560cb12a4080 locking,arch: Rewrite generic atomic support Hence likely the reason author went with home grown atomic_orr() -Vineet -- 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: How is AP supposed to handle power-save packets from peer?
On 10 July 2015 at 02:03, Ben Greear wrote: > Suppose one is doing heavy download (AP -> peer traffic), and there are lots > of frames in the > NIC's tx buffers (ath10k firmware, in this case). > > Then, peer sends a power-save pkt telling AP it is going off-channel or > otherwise > will be unavailable. I assume you're exploring the worst-case scenario when all tx buffers are consumed and peer goes to sleep, am I correct? > > What is the appropriate behaviour from the AP? Can the firmware just drop > all those tx frames to > make room to handle other stations? Maybe report ACK failure and hope the > upper level stacks > retransmit as appropriate? > > Or, is the host supposed to flush the peer's packets to clear out the frames? > > Or, is firmware somehow supposed to keep all the frames for when the peer > comes back? Firmware will keep frames buffered until station wakes up again. There's a timeout to detect stale stations as far as I'm aware and the default value is 10s (sounds familiar? this goes back to mgmt tx/ credit starvation). This makes to handle stations that go to sleep and then out of range/away. AP doesn't need to keep frames buffered till the end of time. Once the timeout is hit firmware stops caring about station's last seen sleep state transition and marks it as awake and just sends frames to it (with tons of retransmits if it's really not there anymore since there'd be noone to ACK) - in which case you'll get no_ack=1 in tx status. See: WMI_10X_VDEV_PARAM_AP_DETECT_OUT_OF_SYNC_SLEEPING_STA_TIME_SECS Ideally there should be little to no buffer bloat but it's difficult to do that considering aggregation sizes of 11ac.. Michał -- 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/3] staging: wilc1000: rework integer value for x64
Hello Greg. This driver convert pointer address to integer value and use it as function argument. because the value has a limited 32bit size, current driver happen many issues on x64 machine. I have split it up enough sensibliy to allow review. If this patches are accepted, I will update more patches related with this patch. Best regards. Johnny. Johnny Kim (3): staging: wilc1000: wilc_wlan_cfg_commit(): replace integer with pointer staging: wilc1000: wilc_wlan_cfg_get(): replace integer with void pointer staging: wilc1000: wilc_wlan_cfg_set(): replace integer with void pointer drivers/staging/wilc1000/coreconfigurator.c | 4 ++-- drivers/staging/wilc1000/linux_wlan.c | 2 +- drivers/staging/wilc1000/wilc_wlan.c| 12 ++-- drivers/staging/wilc1000/wilc_wlan_if.h | 4 ++-- 4 files changed, 11 insertions(+), 11 deletions(-) -- 1.9.1 -- 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/3] staging: wilc1000: wilc_wlan_cfg_commit(): replace integer with pointer
A argument of wilc_wlan_cfg_commit() is address of structure. But because the size is restricted to 32bit, it is not correct for 64bit machine. So, this changes the interger value to obvious structure pointer. Signed-off-by: Johnny Kim --- drivers/staging/wilc1000/wilc_wlan.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c index def72fd..d32e45e 100644 --- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -1862,13 +1862,13 @@ static void wilc_wlan_cleanup(void) } -static int wilc_wlan_cfg_commit(int type, uint32_t drvHandler) +static int wilc_wlan_cfg_commit(int type, tstrWILC_WFIDrv *drvHandler) { wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan; wilc_cfg_frame_t *cfg = &p->cfg_frame; int total_len = p->cfg_frame_offset + 4 + DRIVER_HANDLER_SIZE; int seq_no = p->cfg_seq_no % 256; - int driver_handler = (u32)drvHandler; + uintptr_t driver_handler = (uintptr_t)drvHandler; /** @@ -1923,7 +1923,7 @@ static int wilc_wlan_cfg_set(int start, uint32_t wid, uint8_t *buffer, uint32_t p->cfg_frame_in_use = 1; /*Edited by Amr - BugID_4720*/ - if (wilc_wlan_cfg_commit(WILC_CFG_SET, drvHandler)) + if (wilc_wlan_cfg_commit(WILC_CFG_SET, (tstrWILC_WFIDrv *)drvHandler)) ret_size = 0; /* BugID_5213 */ if (p->os_func.os_wait(p->cfg_wait, CFG_PKTS_TIMEOUT)) { @@ -1960,7 +1960,7 @@ static int wilc_wlan_cfg_get(int start, uint32_t wid, int commit, uint32_t drvHa p->cfg_frame_in_use = 1; /*Edited by Amr - BugID_4720*/ - if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, drvHandler)) + if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, (tstrWILC_WFIDrv *)drvHandler)) ret_size = 0; /* BugID_5213 */ -- 1.9.1 -- 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 5/5] staging: wilc1000: change variable of limited 32bit size to pointer
gu8FlushedJoinReqDrvHandler variable is be using to save structure pointer. But because that is restricted to 32bit and has needless casting, the varibale should be changed to pointer of same type. Signed-off-by: Johnny Kim --- drivers/staging/wilc1000/host_interface.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index dfd8e01..a82e0a8 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -581,7 +581,7 @@ u8 gu8Flushed11iMode; u8 gu8FlushedAuthType; u32 gu32FlushedJoinReqSize; u32 gu32FlushedInfoElemAsocSize; -u32 gu8FlushedJoinReqDrvHandler; +tstrWILC_WFIDrv *gu8FlushedJoinReqDrvHandler; #define REAL_JOIN_REQ 0 #define FLUSHED_JOIN_REQ 1 #define FLUSHED_BYTE_POS 79 /* Position the byte indicating flushing in the flushed request */ @@ -1948,7 +1948,7 @@ static s32 Handle_Connect(void *drvHandler, tstrHostIFconnectAttr *pstrHostIFcon /*BugID_5137*/ if (WILC_memcmp("DIRECT-", pstrHostIFconnectAttr->pu8ssid, 7)) { memcpy(gu8FlushedJoinReq, pu8CurrByte, gu32FlushedJoinReqSize); - gu8FlushedJoinReqDrvHandler = (u32)pstrWFIDrv; + gu8FlushedJoinReqDrvHandler = pstrWFIDrv; } PRINT_D(GENERIC_DBG, "send HOST_IF_WAITING_CONN_RESP\n"); @@ -2199,11 +2199,11 @@ static s32 Handle_ConnectTimeout(void *drvHandler) WILC_memset(u8ConnectedSSID, 0, ETH_ALEN); /*BugID_5213*/ /*Freeing flushed join request params on connect timeout*/ - if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == (u32)drvHandler) { + if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == drvHandler) { WILC_FREE(gu8FlushedJoinReq); gu8FlushedJoinReq = NULL; } - if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == (u32)drvHandler) { + if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == drvHandler) { WILC_FREE(gu8FlushedInfoElemAsoc); gu8FlushedInfoElemAsoc = NULL; } @@ -2624,11 +2624,11 @@ static s32 Handle_RcvdGnrlAsyncInfo(void *drvHandler, tstrRcvdGnrlAsyncInfo *pst /*BugID_5213*/ /*Freeing flushed join request params on receiving*/ /*MAC_DISCONNECTED while connected*/ - if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == (u32)drvHandler) { + if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == drvHandler) { WILC_FREE(gu8FlushedJoinReq); gu8FlushedJoinReq = NULL; } - if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == (u32)drvHandler) { + if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == drvHandler) { WILC_FREE(gu8FlushedInfoElemAsoc); gu8FlushedInfoElemAsoc = NULL; } @@ -3125,11 +3125,11 @@ static void Handle_Disconnect(void *drvHandler) /*BugID_5137*/ - if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == (u32)drvHandler) { + if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == drvHandler) { WILC_FREE(gu8FlushedJoinReq); gu8FlushedJoinReq = NULL; } - if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == (u32)drvHandler) { + if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == drvHandler) { WILC_FREE(gu8FlushedInfoElemAsoc); gu8FlushedInfoElemAsoc = NULL; } -- 1.9.1 -- 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/3] staging: wilc1000: wilc_wlan_cfg_get(): replace integer with void pointer
Last argument of wilc_wlan_cfg_get function is actually structure's address. This should be changed to be compatible with 64bit machine. Because wilc_wlan_cfg_get function is mapped by function pointer later, wilc_wlan_oup_t.wlan_cfg_get should be changed together. tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_get is defined. So, this patch changes the argument to void type pointer. Signed-off-by: Johnny Kim --- drivers/staging/wilc1000/coreconfigurator.c | 2 +- drivers/staging/wilc1000/wilc_wlan.c| 2 +- drivers/staging/wilc1000/wilc_wlan_if.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/wilc1000/coreconfigurator.c b/drivers/staging/wilc1000/coreconfigurator.c index b069614..141d7b4 100644 --- a/drivers/staging/wilc1000/coreconfigurator.c +++ b/drivers/staging/wilc1000/coreconfigurator.c @@ -2094,7 +2094,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs, (counter == u32WIDsCount - 1)); if (!gpstrWlanOps->wlan_cfg_get(!counter, pstrWIDs[counter].u16WIDid, - (counter == u32WIDsCount - 1), drvHandler)) { + (counter == u32WIDsCount - 1), (void *)drvHandler)) { ret = -1; printk("[Sendconfigpkt]Get Timed out\n"); break; diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c index d32e45e..c0a8063 100644 --- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -1938,7 +1938,7 @@ static int wilc_wlan_cfg_set(int start, uint32_t wid, uint8_t *buffer, uint32_t return ret_size; } -static int wilc_wlan_cfg_get(int start, uint32_t wid, int commit, uint32_t drvHandler) +static int wilc_wlan_cfg_get(int start, uint32_t wid, int commit, void* drvHandler) { wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan; uint32_t offset; diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h b/drivers/staging/wilc1000/wilc_wlan_if.h index 8735a6a..8c293ab 100644 --- a/drivers/staging/wilc1000/wilc_wlan_if.h +++ b/drivers/staging/wilc1000/wilc_wlan_if.h @@ -194,7 +194,7 @@ typedef struct { void (*wlan_handle_rx_isr)(void); void (*wlan_cleanup)(void); int (*wlan_cfg_set)(int, uint32_t, uint8_t *, uint32_t, int, uint32_t); - int (*wlan_cfg_get)(int, uint32_t, int, uint32_t); + int (*wlan_cfg_get)(int, uint32_t, int, void *); int (*wlan_cfg_get_value)(uint32_t, uint8_t *, uint32_t); /*Bug3959: transmitting mgmt frames received from host*/ #if defined(WILC_AP_EXTERNAL_MLME) || defined(WILC_P2P) -- 1.9.1 -- 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/3] staging: wilc1000: wilc_wlan_cfg_set(): replace integer with void pointer
Last argument of wilc_wlan_cfg_set function is actually structure's address. This should be changed to be compatible with 64bit machine. Because wilc_wlan_cfg_set function is mapped by function pointer later, wilc_wlan_oup_t.wlan_cfg_set should be changed together. tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_set is defined. So, this patch changes the argument to void type pointer. Signed-off-by: Johnny Kim --- drivers/staging/wilc1000/coreconfigurator.c | 2 +- drivers/staging/wilc1000/linux_wlan.c | 2 +- drivers/staging/wilc1000/wilc_wlan.c| 2 +- drivers/staging/wilc1000/wilc_wlan_if.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/wilc1000/coreconfigurator.c b/drivers/staging/wilc1000/coreconfigurator.c index 141d7b4..5c1096d 100644 --- a/drivers/staging/wilc1000/coreconfigurator.c +++ b/drivers/staging/wilc1000/coreconfigurator.c @@ -2117,7 +2117,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs, if (!gpstrWlanOps->wlan_cfg_set(!counter, pstrWIDs[counter].u16WIDid, pstrWIDs[counter].ps8WidVal, pstrWIDs[counter].s32ValueSize, - (counter == u32WIDsCount - 1), drvHandler)) { + (counter == u32WIDsCount - 1), (void *)drvHandler)) { ret = -1; printk("[Sendconfigpkt]Set Timed out\n"); break; diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index 5a794df..eadc500 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -1340,7 +1340,7 @@ static int linux_wlan_init_test_config(struct net_device *dev, linux_wlan_t *p_n goto _fail_; c_val[0] = 1; /* Enable N with immediate block ack. */ - if (!g_linux_wlan->oup.wlan_cfg_set(0, WID_11N_IMMEDIATE_BA_ENABLED, c_val, 1, 1, (u32)pstrWFIDrv)) + if (!g_linux_wlan->oup.wlan_cfg_set(0, WID_11N_IMMEDIATE_BA_ENABLED, c_val, 1, 1, (void *)pstrWFIDrv)) goto _fail_; return 0; diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c index c0a8063..f9dbd40 100644 --- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -1899,7 +1899,7 @@ static int wilc_wlan_cfg_commit(int type, tstrWILC_WFIDrv *drvHandler) return 0; } -static int wilc_wlan_cfg_set(int start, uint32_t wid, uint8_t *buffer, uint32_t buffer_size, int commit, uint32_t drvHandler) +static int wilc_wlan_cfg_set(int start, uint32_t wid, uint8_t *buffer, uint32_t buffer_size, int commit, void *drvHandler) { wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan; uint32_t offset; diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h b/drivers/staging/wilc1000/wilc_wlan_if.h index 8c293ab..9d42bd8 100644 --- a/drivers/staging/wilc1000/wilc_wlan_if.h +++ b/drivers/staging/wilc1000/wilc_wlan_if.h @@ -193,7 +193,7 @@ typedef struct { void (*wlan_handle_rx_que)(void); void (*wlan_handle_rx_isr)(void); void (*wlan_cleanup)(void); - int (*wlan_cfg_set)(int, uint32_t, uint8_t *, uint32_t, int, uint32_t); + int (*wlan_cfg_set)(int, uint32_t, uint8_t *, uint32_t, int, void *); int (*wlan_cfg_get)(int, uint32_t, int, void *); int (*wlan_cfg_get_value)(uint32_t, uint8_t *, uint32_t); /*Bug3959: transmitting mgmt frames received from host*/ -- 1.9.1 -- 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/5] staging: wilc1000: SendConfigPkt(): replace integer with void pointer
This patch replaces a integer argument of SendConfigPkt function with void type pointer and fix code that the function is called. Because tstrWILC_WFIDrv structure is defined after SendConfigPkt function is defined, the function can not refer to the structure type. So this patch change the argument to void type pointer. Signed-off-by: Johnny Kim --- drivers/staging/wilc1000/coreconfigurator.c | 4 +- drivers/staging/wilc1000/coreconfigurator.h | 2 +- drivers/staging/wilc1000/host_interface.c | 102 ++-- 3 files changed, 54 insertions(+), 54 deletions(-) diff --git a/drivers/staging/wilc1000/coreconfigurator.c b/drivers/staging/wilc1000/coreconfigurator.c index 5c1096d..e274f1b 100644 --- a/drivers/staging/wilc1000/coreconfigurator.c +++ b/drivers/staging/wilc1000/coreconfigurator.c @@ -1893,7 +1893,7 @@ s32 ConfigWaitResponse(char *pcRespBuffer, s32 s32MaxRespBuffLen, s32 *ps32Bytes */ #ifdef SIMULATION s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs, - u32 u32WIDsCount, bool bRespRequired, u32 drvHandler) + u32 u32WIDsCount, bool bRespRequired, void *drvHandler) { s32 s32Error = WILC_SUCCESS; s32 err = WILC_SUCCESS; @@ -2072,7 +2072,7 @@ extern wilc_wlan_oup_t *gpstrWlanOps; * @version 1.0 */ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs, - u32 u32WIDsCount, bool bRespRequired, u32 drvHandler) + u32 u32WIDsCount, bool bRespRequired, void *drvHandler) { s32 counter = 0, ret = 0; if (gpstrWlanOps == NULL) { diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h index 9059c8d..c39802f 100644 --- a/drivers/staging/wilc1000/coreconfigurator.h +++ b/drivers/staging/wilc1000/coreconfigurator.h @@ -175,7 +175,7 @@ extern s32 CoreConfiguratorInit(void); extern s32 CoreConfiguratorDeInit(void); extern s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs, -u32 u32WIDsCount, bool bRespRequired, u32 drvHandler); +u32 u32WIDsCount, bool bRespRequired, void *drvHandler); extern s32 ParseNetworkInfo(u8 *pu8MsgBuffer, tstrNetworkInfo **ppstrNetworkInfo); extern s32 DeallocateNetworkInfo(tstrNetworkInfo *pstrNetworkInfo); diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index c089e73..dfd8e01 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -619,7 +619,7 @@ static s32 Handle_SetChannel(void *drvHandler, tstrHostIFSetChan *pstrHostIFSetC PRINT_D(HOSTINF_DBG, "Setting channel\n"); /*Sending Cfg*/ - s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv); + s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv); if (s32Error) { PRINT_ER("Failed to set channel\n"); WILC_ERRORREPORT(s32Error, WILC_INVALID_STATE); @@ -656,7 +656,7 @@ static s32 Handle_SetWfiDrvHandler(tstrHostIfSetDrvHandler *pstrHostIfSetDrvHand /*Sending Cfg*/ - s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv); + s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv); if ((pstrHostIfSetDrvHandler->u32Address) == (u32)NULL) @@ -701,7 +701,7 @@ static s32 Handle_SetOperationMode(void *drvHandler, tstrHostIfSetOperationMode /*Sending Cfg*/ PRINT_INFO(HOSTINF_DBG, "pstrWFIDrv= %p\n", pstrWFIDrv); - s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv); + s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv); if ((pstrHostIfSetOperationMode->u32Mode) == (u32)NULL) @@ -750,7 +750,7 @@ s32 Handle_set_IPAddress(void *drvHandler, u8 *pu8IPAddr, u8 idx) strWID.ps8WidVal = (u8 *)pu8IPAddr; strWID.s32ValueSize = IP_ALEN; - s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv); + s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv); @@ -794,7 +794,7 @@ s32 Handle_get_IPAddress(void *drvHandler, u8 *pu8IPAddr, u8 idx) strWID.ps8WidVal = (u8 *)WILC_MALLOC(IP_ALEN); strWID.s32ValueSize = IP_ALEN; - s32Error = SendConfigPkt(GET_CFG, &strWID, 1, true, (u32)pstrWFIDrv); + s32Error = SendConfigPkt(GET_CFG, &strWID, 1, true, pstrWFIDrv); PRINT_INFO(HOSTINF_DBG, "%pI4\n", strWID.ps8WidVal); @@ -855,7 +855,7 @@ static s32 Handle_SetMacAddress(void *drvHandler, tstrHostIfSetMacAddress *pstrH strWID.s32ValueSize = ETH_ALEN; PRINT_D(GENERIC_DBG, "mac addr = :%x:%x:%x:%x:%x:%x\n", strWID.ps8WidVal[0], strWID.ps8WidVal[1], strWID.ps8WidVal[2], strWID.ps8WidVal[3], strWID.ps8WidVal[4], strWID.ps8WidVal[5]); /*Sending Cfg*/ - s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv); + s32Error = SendConfigPkt(SET
Re: [PATCH 1/3] staging: wilc1000: wilc_wlan_cfg_commit(): replace integer with pointer
Hi Johnny, On Fri, Jul 10, 2015 at 3:55 PM, Johnny Kim wrote: > A argument of wilc_wlan_cfg_commit() is address of structure. > But because the size is restricted to 32bit, it is not correct > for 64bit machine. > > So, this changes the interger value to obvious structure pointer. > > Signed-off-by: Johnny Kim > --- > drivers/staging/wilc1000/wilc_wlan.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/wilc1000/wilc_wlan.c > b/drivers/staging/wilc1000/wilc_wlan.c > index def72fd..d32e45e 100644 > --- a/drivers/staging/wilc1000/wilc_wlan.c > +++ b/drivers/staging/wilc1000/wilc_wlan.c > @@ -1862,13 +1862,13 @@ static void wilc_wlan_cleanup(void) > > } > > -static int wilc_wlan_cfg_commit(int type, uint32_t drvHandler) > +static int wilc_wlan_cfg_commit(int type, tstrWILC_WFIDrv *drvHandler) > { > wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan; > wilc_cfg_frame_t *cfg = &p->cfg_frame; > int total_len = p->cfg_frame_offset + 4 + DRIVER_HANDLER_SIZE; > int seq_no = p->cfg_seq_no % 256; > - int driver_handler = (u32)drvHandler; > + uintptr_t driver_handler = (uintptr_t)drvHandler; Er, why not just remove this variable and use drvHandler directly? > @@ -1923,7 +1923,7 @@ static int wilc_wlan_cfg_set(int start, uint32_t wid, > uint8_t *buffer, uint32_t > p->cfg_frame_in_use = 1; > > /*Edited by Amr - BugID_4720*/ > - if (wilc_wlan_cfg_commit(WILC_CFG_SET, drvHandler)) > + if (wilc_wlan_cfg_commit(WILC_CFG_SET, (tstrWILC_WFIDrv > *)drvHandler)) No need to cast it to it's own type. > ret_size = 0; /* BugID_5213 */ > > if (p->os_func.os_wait(p->cfg_wait, CFG_PKTS_TIMEOUT)) { > @@ -1960,7 +1960,7 @@ static int wilc_wlan_cfg_get(int start, uint32_t wid, > int commit, uint32_t drvHa > p->cfg_frame_in_use = 1; > > /*Edited by Amr - BugID_4720*/ > - if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, drvHandler)) > + if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, (tstrWILC_WFIDrv > *)drvHandler)) Ditto. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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/3] staging: wilc1000: wilc_wlan_cfg_get(): replace integer with void pointer
Hi Johnny, On Fri, Jul 10, 2015 at 3:55 PM, Johnny Kim wrote: > Last argument of wilc_wlan_cfg_get function is actually structure's address. > This should be changed to be compatible with 64bit machine. > Because wilc_wlan_cfg_get function is mapped by function pointer later, > wilc_wlan_oup_t.wlan_cfg_get should be changed together. > > tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_get > is defined. So, this patch changes the argument to void type pointer. Why not add a patch moving the structure definition before wilc_wlan_oup_t.wlan_cfg_get is defined? > Signed-off-by: Johnny Kim > --- > drivers/staging/wilc1000/coreconfigurator.c | 2 +- > drivers/staging/wilc1000/wilc_wlan.c| 2 +- > drivers/staging/wilc1000/wilc_wlan_if.h | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/wilc1000/coreconfigurator.c > b/drivers/staging/wilc1000/coreconfigurator.c > index b069614..141d7b4 100644 > --- a/drivers/staging/wilc1000/coreconfigurator.c > +++ b/drivers/staging/wilc1000/coreconfigurator.c > @@ -2094,7 +2094,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs, >(counter == u32WIDsCount - 1)); > if (!gpstrWlanOps->wlan_cfg_get(!counter, > > pstrWIDs[counter].u16WIDid, > - (counter == > u32WIDsCount - 1), drvHandler)) { > + (counter == > u32WIDsCount - 1), (void *)drvHandler)) { If I recall correctly, you shouldn't need void * casts. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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] nfc: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver() will set it. Signed-off-by: Krzysztof Kozlowski --- The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html --- drivers/nfc/nxp-nci/i2c.c | 1 - drivers/nfc/pn544/i2c.c| 1 - drivers/nfc/st-nci/i2c.c | 1 - drivers/nfc/st21nfca/i2c.c | 1 - 4 files changed, 4 deletions(-) diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c index 2f77f1d03638..6c5e63cd0022 100644 --- a/drivers/nfc/nxp-nci/i2c.c +++ b/drivers/nfc/nxp-nci/i2c.c @@ -450,7 +450,6 @@ MODULE_DEVICE_TABLE(acpi, acpi_id); static struct i2c_driver nxp_nci_i2c_driver = { .driver = { .name = NXP_NCI_I2C_DRIVER_NAME, - .owner = THIS_MODULE, .acpi_match_table = ACPI_PTR(acpi_id), .of_match_table = of_match_ptr(of_nxp_nci_i2c_match), }, diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c index fa75c53f3fa5..a095523309cf 100644 --- a/drivers/nfc/pn544/i2c.c +++ b/drivers/nfc/pn544/i2c.c @@ -1162,7 +1162,6 @@ MODULE_DEVICE_TABLE(of, of_pn544_i2c_match); static struct i2c_driver pn544_hci_i2c_driver = { .driver = { .name = PN544_HCI_I2C_DRIVER_NAME, - .owner = THIS_MODULE, .of_match_table = of_match_ptr(of_pn544_i2c_match), .acpi_match_table = ACPI_PTR(pn544_hci_i2c_acpi_match), }, diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c index 06175ce769bb..c21c45c656c0 100644 --- a/drivers/nfc/st-nci/i2c.c +++ b/drivers/nfc/st-nci/i2c.c @@ -370,7 +370,6 @@ MODULE_DEVICE_TABLE(of, of_st_nci_i2c_match); static struct i2c_driver st_nci_i2c_driver = { .driver = { - .owner = THIS_MODULE, .name = ST_NCI_I2C_DRIVER_NAME, .of_match_table = of_match_ptr(of_st_nci_i2c_match), }, diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c index a32143951616..6f987fa36371 100644 --- a/drivers/nfc/st21nfca/i2c.c +++ b/drivers/nfc/st21nfca/i2c.c @@ -680,7 +680,6 @@ MODULE_DEVICE_TABLE(of, of_st21nfca_i2c_match); static struct i2c_driver st21nfca_hci_i2c_driver = { .driver = { - .owner = THIS_MODULE, .name = ST21NFCA_HCI_I2C_DRIVER_NAME, .of_match_table = of_match_ptr(of_st21nfca_i2c_match), }, -- 1.9.1 -- 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/3] staging: wilc1000: wilc_wlan_cfg_set(): replace integer with void pointer
Hi Johnny, On Fri, Jul 10, 2015 at 3:55 PM, Johnny Kim wrote: > Last argument of wilc_wlan_cfg_set function is actually structure's address. > This should be changed to be compatible with 64bit machine. > Because wilc_wlan_cfg_set function is mapped by function pointer later, > wilc_wlan_oup_t.wlan_cfg_set should be changed together. > > tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_set > is defined. So, this patch changes the argument to void type pointer. Same question, why not move the structure definition before this op is defined? > Signed-off-by: Johnny Kim > --- > drivers/staging/wilc1000/coreconfigurator.c | 2 +- > drivers/staging/wilc1000/linux_wlan.c | 2 +- > drivers/staging/wilc1000/wilc_wlan.c| 2 +- > drivers/staging/wilc1000/wilc_wlan_if.h | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/wilc1000/coreconfigurator.c > b/drivers/staging/wilc1000/coreconfigurator.c > index 141d7b4..5c1096d 100644 > --- a/drivers/staging/wilc1000/coreconfigurator.c > +++ b/drivers/staging/wilc1000/coreconfigurator.c > @@ -2117,7 +2117,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs, > if (!gpstrWlanOps->wlan_cfg_set(!counter, > > pstrWIDs[counter].u16WIDid, pstrWIDs[counter].ps8WidVal, > > pstrWIDs[counter].s32ValueSize, > - (counter == > u32WIDsCount - 1), drvHandler)) { > + (counter == > u32WIDsCount - 1), (void *)drvHandler)) { Again, you shouldn't need a void * cast. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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/5] staging: wilc1000: SendConfigPkt(): replace integer with void pointer
Hi Johnny, On Fri, Jul 10, 2015 at 3:55 PM, Johnny Kim wrote: > This patch replaces a integer argument of SendConfigPkt function with > void type pointer and fix code that the function is called. > > Because tstrWILC_WFIDrv structure is defined after SendConfigPkt function > is defined, the function can not refer to the structure type. > So this patch change the argument to void type pointer. Same comments again, why not move the structure definition? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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