Re: RT2870 failure in kernel 4.12.8
On Wed, Aug 30, 2017 at 12:03:06PM -0500, Larry Finger wrote: > Stanislaw and Helmut, > > In a bug report at https://bugzilla.suse.com/show_bug.cgi?id=1055826, the OP > reports that his RT3572 fails to work after an upgrade from the openSUSE > Tumbleweed kernel 4.12.7 to 4.12.8. I checked the kernel configuration and > did not see any problems. > > Are you aware of anyone reporting problems with rt2800usb in 4.12.8 kernels? I think it is the issue addressed by this 4.12 patch: https://marc.info/?l=linux-wireless&m=150366111408179&w=2 Patch for 4.13+ kernels is here: https://marc.info/?l=linux-wireless&m=150367345912061&w=2 Thanks Stanislaw
Re: RT2870 failure in kernel 4.12.8
Stanislaw Gruszka writes: > On Wed, Aug 30, 2017 at 12:03:06PM -0500, Larry Finger wrote: >> Stanislaw and Helmut, >> >> In a bug report at https://bugzilla.suse.com/show_bug.cgi?id=1055826, the OP >> reports that his RT3572 fails to work after an upgrade from the openSUSE >> Tumbleweed kernel 4.12.7 to 4.12.8. I checked the kernel configuration and >> did not see any problems. >> >> Are you aware of anyone reporting problems with rt2800usb in 4.12.8 kernels? > > I think it is the issue addressed by this 4.12 patch: > https://marc.info/?l=linux-wireless&m=150366111408179&w=2 > > Patch for 4.13+ kernels is here: > https://marc.info/?l=linux-wireless&m=150367345912061&w=2 And the commit is here: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=83ec489193894e52bd395eec470f4f7c4286d4a5 -- Kalle Valo
Re: rfkill(8) move and improvements
On Wed, Aug 30, 2017 at 08:40:01PM +0100, Sami Kerola wrote: > On 1 July 2017 at 10:06, Sami Kerola wrote: > > I did couple last minute changes to my remote branch, that should now be > > ready for final review. > > > > git://github.com/kerolasa/lelux-utiliteetit.git rfkill > > Hello, > > It's been a while. I did not get any review feedback, so I assume changes > were ok. Would it be possible to move forward with the merge to > util-linux upstream? Merged to util-linux. Karel -- Karel Zak http://karelzak.blogspot.com
Re: [PATCH 5/5] qtnfmac: implement 64-bit dma support
Hello Kalle, > > - writel(QTN_HOST_LO32(paddr), > > -PCIE_HDP_TX_HOST_Q_BASE_L(priv->pcie_reg_base)); > > +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT > > writel(QTN_HOST_HI32(paddr), > > PCIE_HDP_TX_HOST_Q_BASE_H(priv->pcie_reg_base)); > > +#endif > > Personally I detest ifdefs and try to write code like this using > IS_ENABLED(): > > if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)) > writel(QTN_HOST_HI32(paddr), >PCIE_HDP_TX_HOST_Q_BASE_H(priv->pcie_reg_base)); > > But up to you which style you prefer. I agree that this way it looks better. But I am using the same ifdef in header to define QTN_HOST_* macros. So in this particular case I would prefer to keep the same notation in both source and header files. Thanks, Sergey
[PATCH] mac80211: fix incorrect assignment of reassoc value
this fix minor issue in the log message. in ieee80211_rx_mgmt_assoc_resp function, when assigning the reassoc value from the mgmt frame control: ieee80211_is_reassoc_resp function need to be used, instead of ieee80211_is_reassoc_req function. Signed-off-by: Simon Dinkin --- net/mac80211/mlme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 7be7917..0467f9f 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -3159,7 +3159,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata, if (len < 24 + 6) return; - reassoc = ieee80211_is_reassoc_req(mgmt->frame_control); + reassoc = ieee80211_is_reassoc_resp(mgmt->frame_control); capab_info = le16_to_cpu(mgmt->u.assoc_resp.capab_info); status_code = le16_to_cpu(mgmt->u.assoc_resp.status_code); aid = le16_to_cpu(mgmt->u.assoc_resp.aid); -- 2.7.4
Re: [PATCH 5/5] qtnfmac: implement 64-bit dma support
Sergey Matyukevich writes: > Hello Kalle, > >> > - writel(QTN_HOST_LO32(paddr), >> > -PCIE_HDP_TX_HOST_Q_BASE_L(priv->pcie_reg_base)); >> > +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT >> > writel(QTN_HOST_HI32(paddr), >> > PCIE_HDP_TX_HOST_Q_BASE_H(priv->pcie_reg_base)); >> > +#endif >> >> Personally I detest ifdefs and try to write code like this using >> IS_ENABLED(): >> >> if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)) >> writel(QTN_HOST_HI32(paddr), >>PCIE_HDP_TX_HOST_Q_BASE_H(priv->pcie_reg_base)); >> >> But up to you which style you prefer. > > I agree that this way it looks better. But I am using the same ifdef in header > to define QTN_HOST_* macros. So in this particular case I would prefer to > keep the same notation in both source and header files. Ok. I'll try to get these to 4.14 still. -- Kalle Valo
Re: [GIT] Networking
(Adding linux-wireless) Pavel Machek writes: > On Thu 2017-08-31 07:44:58, Kalle Valo wrote: >> David Miller writes: >> >> > From: Kalle Valo >> > Date: Wed, 30 Aug 2017 20:31:31 +0300 >> > >> >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug >> >> has been there for 7 years so waiting for a few more weeks should not >> >> hurt. >> > >> > As a maintainer you have a right to handle bug fixing in that way, but >> > certainly that is not how I would handle this. >> > >> > It's easy to validate this fix, it's extremely unlikely to cause >> > a regression, and fixes a problem someone actually was able to >> > trigger. >> > >> > Deferring to -next only has the side effect of making people wait >> > longer for the fix. >> >> Yeah, you are right there. I did actually ponder which I tree should >> commit it back in July but due to various reasons decided differently. > > Can we still get the fix to v4.13-final? :-). I'm not planning to submit pull requests to 4.13 anymore. If you think this is so important that it needs to be applied in the last minute (I don't) you could always try to convince Dave to take it directly. Or better yet, push it to the stable tree. If the merge window opens on Sunday I suspect that the commit will be in Linus' tree sometime next week. Then you can submit the request to the stable team to take it. -- Kalle Valo
Re: ath10k: fix napi_poll budget overflow
ryan...@qti.qualcomm.com wrote: > In napi_poll, the budget number is used to control the amount of packets > we should handle per poll to balance the resource in the system. > > In the list of the amsdu packets reception, we check if there is budget > count left and handle the complete list of the packets, that it will have > chances the very last list will over the budget leftover. > > So adding one more parameter - budget_left, this would help while > traversing the list to avoid handling more than the budget given. > > Reported-by: Andrey Ryabinin > Fix-suggested-by: Igor Mitsyanko > Link: > https://lkml.kernel.org/r/26670dce-4dd2-f8e4-0e14-90d74257e...@virtuozzo.com > Signed-off-by: Ryan Hsu > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. c9353bf483d3 ath10k: fix napi_poll budget overflow -- https://patchwork.kernel.org/patch/9916207/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v2] ath10k: sdio: remove unused struct member
Erik Stromdahl wrote: > irq_wq in struct ath10k_sdio is a remnant from an earlier > version of the sdio patchset. > > Its use was removed as a result of Kalle's review, but somehow > the struct member survived. > > It is not used and can therefore safely be removed. > > Signed-off-by: Erik Stromdahl > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 30b83fff6d97 ath10k: sdio: remove unused struct member -- https://patchwork.kernel.org/patch/9918195/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k: activate user space firmware loading again
Hauke Mehrtens wrote: > In commit 9f5bcfe93315 ("ath10k: silence firmware file probing > warnings") the firmware loading was changed from request_firmware() to > request_firmware_direct() to silence some warnings in case it fails. > request_firmware_direct() directly searches in the file system only and > does not send a hotplug event to user space in case it could not find > the firmware directly. > In LEDE we use a user space script to extract the calibration data from > the flash memory which gets triggered by the hotplug event. This way the > firmware gets extracted from some vendor specific partition when the > driver requests this firmware. This mechanism does not work any more > after this change. > > Fixes: 9f5bcfe93315 ("ath10k: silence firmware file probing warnings") > Signed-off-by: Hauke Mehrtens > Cc: Michal Kazior > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. c0cc00f250e1 ath10k: activate user space firmware loading again -- https://patchwork.kernel.org/patch/9920973/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [1/7] wil6210: ratelimit errors in TX/RX interrupts
Maya Erez wrote: > Sometimes there is a firmware crash but the hardware > is not fully stopped and continue to send TX/RX interrupts. > This can cause an overload of messages which can bring the > host down. Add ratelimit to these error messages to fix this. > > Signed-off-by: Lior David > Signed-off-by: Maya Erez > Signed-off-by: Kalle Valo 7 patches applied to ath-next branch of ath.git, thanks. 40cbd88be702 wil6210: ratelimit errors in TX/RX interrupts 5f591dac9f20 wil6210: make debugfs compilation optional 761f8e4d463e wil6210: align to latest auto generated wmi.h 1490846d256a wil6210: move pre-FW configuration to separate function 7086d861753b wil6210: clear PAL_UNIT_ICR part of device reset d83ad4c4fd78 wil6210: increase connect timeout 69fecf599f48 wil6210: ensure P2P device is stopped before removing interface -- https://patchwork.kernel.org/patch/9926041/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH 20/25] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer
From: Thomas Gleixner Switch the timer to CLOCK_MONOTONIC_SOFT, which executed the timer callback in softirq context and remove the hrtimer_tasklet. Signed-off-by: Thomas Gleixner Signed-off-by: Anna-Maria Gleixner Cc: Johannes Berg Cc: Kalle Valo Cc: linux-wireless@vger.kernel.org --- drivers/net/wireless/mac80211_hwsim.c | 44 +++--- 1 file changed, 20 insertions(+), 24 deletions(-) --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/net/wireless/mac80211_hwsim.c @@ -537,7 +537,7 @@ struct mac80211_hwsim_data { unsigned int rx_filter; bool started, idle, scanning; struct mutex mutex; - struct tasklet_hrtimer beacon_timer; + struct hrtimer beacon_timer; enum ps_mode { PS_DISABLED, PS_ENABLED, PS_AUTO_POLL, PS_MANUAL_POLL } ps; @@ -1420,7 +1420,7 @@ static void mac80211_hwsim_stop(struct i { struct mac80211_hwsim_data *data = hw->priv; data->started = false; - tasklet_hrtimer_cancel(&data->beacon_timer); + hrtimer_cancel(&data->beacon_timer); wiphy_debug(hw->wiphy, "%s\n", __func__); } @@ -1543,14 +1543,12 @@ static enum hrtimer_restart mac80211_hwsim_beacon(struct hrtimer *timer) { struct mac80211_hwsim_data *data = - container_of(timer, struct mac80211_hwsim_data, -beacon_timer.timer); + container_of(timer, struct mac80211_hwsim_data, beacon_timer); struct ieee80211_hw *hw = data->hw; u64 bcn_int = data->beacon_int; - ktime_t next_bcn; if (!data->started) - goto out; + return HRTIMER_NORESTART; ieee80211_iterate_active_interfaces_atomic( hw, IEEE80211_IFACE_ITER_NORMAL, @@ -1562,11 +1560,9 @@ mac80211_hwsim_beacon(struct hrtimer *ti data->bcn_delta = 0; } - next_bcn = ktime_add(hrtimer_get_expires(timer), -ns_to_ktime(bcn_int * 1000)); - tasklet_hrtimer_start(&data->beacon_timer, next_bcn, HRTIMER_MODE_ABS); -out: - return HRTIMER_NORESTART; + hrtimer_forward(&data->beacon_timer, hrtimer_get_expires(timer), + ns_to_ktime(bcn_int * NSEC_PER_USEC)); + return HRTIMER_RESTART; } static const char * const hwsim_chanwidths[] = { @@ -1640,15 +1636,15 @@ static int mac80211_hwsim_config(struct mutex_unlock(&data->mutex); if (!data->started || !data->beacon_int) - tasklet_hrtimer_cancel(&data->beacon_timer); - else if (!hrtimer_is_queued(&data->beacon_timer.timer)) { + hrtimer_cancel(&data->beacon_timer); + else if (!hrtimer_is_queued(&data->beacon_timer)) { u64 tsf = mac80211_hwsim_get_tsf(hw, NULL); u32 bcn_int = data->beacon_int; u64 until_tbtt = bcn_int - do_div(tsf, bcn_int); - tasklet_hrtimer_start(&data->beacon_timer, - ns_to_ktime(until_tbtt * 1000), - HRTIMER_MODE_REL); + hrtimer_start(&data->beacon_timer, + ns_to_ktime(until_tbtt * 1000), + HRTIMER_MODE_REL); } return 0; @@ -1711,7 +1707,7 @@ static void mac80211_hwsim_bss_info_chan info->enable_beacon, info->beacon_int); vp->bcn_en = info->enable_beacon; if (data->started && - !hrtimer_is_queued(&data->beacon_timer.timer) && + !hrtimer_is_queued(&data->beacon_timer) && info->enable_beacon) { u64 tsf, until_tbtt; u32 bcn_int; @@ -1719,9 +1715,9 @@ static void mac80211_hwsim_bss_info_chan tsf = mac80211_hwsim_get_tsf(hw, vif); bcn_int = data->beacon_int; until_tbtt = bcn_int - do_div(tsf, bcn_int); - tasklet_hrtimer_start(&data->beacon_timer, - ns_to_ktime(until_tbtt * 1000), - HRTIMER_MODE_REL); + hrtimer_start(&data->beacon_timer, + ns_to_ktime(until_tbtt * 1000), + HRTIMER_MODE_REL); } else if (!info->enable_beacon) { unsigned int count = 0; ieee80211_iterate_active_interfaces_atomic( @@ -1730,7 +1726,7 @@ static void mac80211_hwsim_bss_info_chan wiphy_debug(hw->wiphy, " beaconing vifs remaining: %u", count); if (count == 0) { - tasklet_hrtimer_cancel(&data->beacon_timer); + hrtimer_cancel(&data->beacon_timer);
Re: [v3,1/2] ath10k: add the PCI PM core suspend/resume ops
ryan...@qti.qualcomm.com wrote: > The actual PCI suspend/resume in ath10k has been handled in wow.c, > but in the case of the device doesn't support remote wakeup, > the .hif_suspend() and .hif_resume() will never be handled. > > ath10k_wow_op_suspend() > { > if (WARN_ON(!test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT, > ar->running_fw->fw_file.fw_features))) { > ret = 1; > goto exit; > } > > > > ret = ath10k_hif_suspend(ar); > } > > So register the PCI PM core to support the suspend/resume if the device > doesn't support remote wakeup. > > Signed-off-by: Ryan Hsu > Signed-off-by: Kalle Valo This had a warning: drivers/net/wireless/ath/ath10k/pci.c:3651:1: warning: symbol 'ath10k_pci_pm_ops' was not declared. Should it be static? I fixed it in the pending branch by making it static: static SIMPLE_DEV_PM_OPS(ath10k_pci_pm_ops, ath10k_pci_pm_suspend, ath10k_pci_pm_resume); Please review. -- https://patchwork.kernel.org/patch/9916215/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [1/5] qtnfmac: drop -D__CHECK_ENDIAN from cflags
Sergey Matyukevich wrote: > Flag -D__CHECK_ENDIAN was wrong: it should be -D__CHECK_ENDIAN__ instead. > However now this flag is enabled by default, so it can be removed. > > Signed-off-by: Sergey Matyukevich 5 patches applied to wireless-drivers-next.git, thanks. 57b18a75d90e qtnfmac: drop -D__CHECK_ENDIAN from cflags 97f38011451f qtnfmac: module param sanity check bab5dac73c08 qtnfmac: modify qtnf_map_bar not to return NULL b00edea3ed5f qtnfmac: fix free_xfer_buffer cleanup f31039d4aea9 qtnfmac: implement 64-bit dma support -- https://patchwork.kernel.org/patch/9927237/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v2] brcmfmac: Log chip id and revision
Hans de Goede wrote: > For debugging some problems, it is useful to know the chip revision > add a brcmf_info message logging this. > > Signed-off-by: Hans de Goede > Acked-by: Arend van Spriel Patch applied to wireless-drivers-next.git, thanks. f38966a7ace8 brcmfmac: Log chip id and revision -- https://patchwork.kernel.org/patch/9929651/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: rtlwifi: rtl8723be: fix duplicated code for different branches
"Gustavo A. R. Silva" wrote: > Refactor code in order to avoid identical code for different branches. > > Addresses-Coverity-ID: 1248728 > Signed-off-by: Gustavo A. R. Silva > Acked-by: Larry Finger Patch applied to wireless-drivers-next.git, thanks. a9a65a6b2b69 rtlwifi: rtl8723be: fix duplicated code for different branches -- https://patchwork.kernel.org/patch/9930325/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] ath9k: remove cast to void pointer
casting to void pointer from any pointer type and vice-versa is done implicitly and therefore casting is not needed in such a case. Signed-off-by: Himanshu Jha --- drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 ++-- drivers/net/wireless/ath/ath9k/dfs.c| 2 +- drivers/net/wireless/ath/ath9k/hif_usb.c| 8 drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 24 drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 6 +++--- drivers/net/wireless/ath/ath9k/init.c | 8 drivers/net/wireless/ath/ath9k/main.c | 2 +- drivers/net/wireless/ath/ath9k/mci.c| 2 +- drivers/net/wireless/ath/ath9k/wmi.c| 4 ++-- 11 files changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c index b3f20b3..e1fe7a7 100644 --- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c +++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c @@ -480,7 +480,7 @@ EXPORT_SYMBOL(ath9k_hw_addrxbuf_edma); int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs, void *buf_addr) { - struct ar9003_rxs *rxsp = (struct ar9003_rxs *) buf_addr; + struct ar9003_rxs *rxsp = buf_addr; unsigned int phyerr; if ((rxsp->status11 & AR_RxDone) == 0) @@ -610,7 +610,7 @@ void ath9k_hw_setup_statusring(struct ath_hw *ah, void *ts_start, ah->ts_paddr_start = ts_paddr_start; ah->ts_paddr_end = ts_paddr_start + (size * sizeof(struct ar9003_txs)); ah->ts_size = size; - ah->ts_ring = (struct ar9003_txs *) ts_start; + ah->ts_ring = ts_start; ath9k_hw_reset_txstatus_ring(ah); } diff --git a/drivers/net/wireless/ath/ath9k/dfs.c b/drivers/net/wireless/ath/ath9k/dfs.c index 1ece42c..40a397f 100644 --- a/drivers/net/wireless/ath/ath9k/dfs.c +++ b/drivers/net/wireless/ath/ath9k/dfs.c @@ -326,7 +326,7 @@ void ath9k_dfs_process_phyerr(struct ath_softc *sc, void *data, if (ard.ext_rssi & 0x80) ard.ext_rssi = 0; - vdata_end = (char *)data + datalen; + vdata_end = data + datalen; ard.pulse_bw_info = vdata_end[-1]; ard.pulse_length_ext = vdata_end[-2]; ard.pulse_length_pri = vdata_end[-3]; diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 0d9687a..71d1725 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -424,7 +424,7 @@ static int hif_usb_send_tx(struct hif_device_usb *hif_dev, struct sk_buff *skb) static void hif_usb_start(void *hif_handle) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; unsigned long flags; hif_dev->flags |= HIF_USB_START; @@ -436,7 +436,7 @@ static void hif_usb_start(void *hif_handle) static void hif_usb_stop(void *hif_handle) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; struct tx_buf *tx_buf = NULL, *tx_buf_tmp = NULL; unsigned long flags; @@ -457,7 +457,7 @@ static void hif_usb_stop(void *hif_handle) static int hif_usb_send(void *hif_handle, u8 pipe_id, struct sk_buff *skb) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; int ret = 0; switch (pipe_id) { @@ -492,7 +492,7 @@ static inline bool check_index(struct sk_buff *skb, u8 idx) static void hif_usb_sta_drain(void *hif_handle, u8 idx) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; struct sk_buff *skb, *tmp; unsigned long flags; diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c index 2c0e4d2..f20c839 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c @@ -384,7 +384,7 @@ void ath9k_htc_set_tsfadjust(struct ath9k_htc_priv *priv, static void ath9k_htc_beacon_iter(void *data, u8 *mac, struct ieee80211_vif *vif) { - bool *beacon_configured = (bool *)data; + bool *beacon_configured = data; struct ath9k_htc_vif *avp = (struct ath9k_htc_vif *) vif->drv_priv; if (vif->type == NL80211_IFTYPE_STATION && diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c index defacc6..9e0c237 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c @@ -233,7 +233,7 @@ static void ath9k_reg_notifier(struct wiphy *wiphy, static unsigned int ath9k
[PATCH] wl1251: add a missing spin_lock_init()
From: Cong Wang wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5668.773803] [] (show_stack) from [] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [] (__ieee80211_tx) from [] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by: Pavel Machek Cc: Kalle Valo Signed-off-by: Cong Wang Acked-by: Pavel Machek Signed-off-by: Kalle Valo Signed-off-by: Pavel Machek Cc: sta...@kernel.org --- > >> Yeah, you are right there. I did actually ponder which I tree should > >> commit it back in July but due to various reasons decided differently. > > > > Can we still get the fix to v4.13-final? :-). > > I'm not planning to submit pull requests to 4.13 anymore. If you think > this is so important that it needs to be applied in the last minute (I > don't) you could always try to convince Dave to take it directly. > > Or better yet, push it to the stable tree. If the merge window opens on > Sunday I suspect that the commit will be in Linus' tree sometime next > week. Then you can submit the request to the stable team to take it. I don't think we should use stable tree as an excuse for not fixing the bugs in mainline. Original patch is from Jul 6, thats 7 weeks ago. Dave, Linus -- can you still take the patch? Thanks, Pavel diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c index 08f0477..9915d83 100644 --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1571,6 +1571,7 @@ struct ieee80211_hw *wl1251_alloc_hw(void) wl->state = WL1251_STATE_OFF; mutex_init(&wl->mutex); + spin_lock_init(&wl->wl_lock); wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] rtlwifi: btcoexist: 23b 1ant: fix duplicated code for different branches
A typo led to this issue, which was detected with the help of Coccinelle. In addition to fixing the error, the code is refactored to eliminate an if statement. Addresses-Coverity-ID: 1226788 Reported-by: Gustavo A. R. Silva Signed-off-by: Larry Finger Cc: Ping-Ke Shih Cc: Yan-Hsuan Chuang Cc: Birming Chiu Cc: Shaofu Cc: Steven Ting --- .../wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c index c04425236ce4..5f726f6d3567 100644 --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c @@ -2260,14 +2260,11 @@ static void halbtc8723b1ant_run_coexist_mechanism(struct btc_coexist *btcoexist) if (iot_peer != BTC_IOT_PEER_CISCO && iot_peer != BTC_IOT_PEER_BROADCOM) { - if (bt_link_info->sco_exist) - halbtc8723b1ant_limited_rx(btcoexist, - NORMAL_EXEC, false, - false, 0x5); - else - halbtc8723b1ant_limited_rx(btcoexist, - NORMAL_EXEC, false, - false, 0x5); + bool sco_exist = bt_link_info->sco_exist; + + halbtc8723b1ant_limited_rx(btcoexist, + NORMAL_EXEC, sco_exist, + false, 0x5); } else { if (bt_link_info->sco_exist) { halbtc8723b1ant_limited_rx(btcoexist, -- 2.12.3
Re: [PATCH 01/30] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
On 30/08/17 19:51, Arend van Spriel wrote: > On 22-08-17 13:25, Ian Molton wrote: >> All the other IO functions are the other way round in this >> driver. Make this one match. > > Sorry for being a nit, but not sure why the commit message starts with a > tab. Not a problem - I don't mind nits being pointed out. Not at all. > Other than that... Will update it in the next (hopefully last!) rev. > Acked-by: Arend van Spriel Ta :) >> Signed-off-by: Ian Molton >> --- >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) -Ian
Re: [PATCH 03/30] brcmfmac: Split brcmf_sdiod_regrw_helper() up.
On 30/08/17 19:59, Arend van Spriel wrote: >> +static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 >> addr, >> + u8 regsz, void *data) > > Thought I mentioned this before, but the indentation should be aligned > to opening bracket. I checked this locally, and its fine. I suspect its getting mangled somewhere along the way. It looks fine in my original email - I see 4 tabs and a space. -Ian
Re: [PATCH] rtlwifi: refactor code in halbtcoutsrc module
On 08/30/2017 11:46 AM, Gustavo A. R. Silva wrote: Function halbtc_get_wifi_rssi always returns rtlpriv->dm.undec_sm_pwdb. So this function can be removed and the value of rtlpriv->dm.undec_sm_pwdb assigned to *s32_tmp directly. This issue was first reported by Coverity as "identical code for different branches" in function halbtc_get_wifi_rssi. Addresses-Coverity-ID: 1226793 Signed-off-by: Gustavo A. R. Silva --- This code was reported by Coverity and it was tested by compilation only. Chances are this may be a copy/paste error in function halbtc_get_wifi_rssi. Please, verify. Also, notice this code has been there since 2014. The value of *s32_tmp is not dependent on the link state, thus this patch is correct, but I request that it be changed. Future developments will modify halbtc_get_wifi_rssi() making it more complicated and not as easily inlined as this patch. In short, if you remove it here, we will have to add it later. Thanks, Larrt .../net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c index c1eacd8..2a47b97 100644 --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c @@ -373,17 +373,6 @@ u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist) return ret_val; } -static s32 halbtc_get_wifi_rssi(struct rtl_priv *rtlpriv) -{ - int undec_sm_pwdb = 0; - - if (rtlpriv->mac80211.link_state >= MAC80211_LINKED) - undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb; - else /* associated entry pwdb */ - undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb; - return undec_sm_pwdb; -} - static bool halbtc_get(void *void_btcoexist, u8 get_type, void *out_buf) { struct btc_coexist *btcoexist = (struct btc_coexist *)void_btcoexist; @@ -479,7 +468,7 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type, void *out_buf) *bool_tmp = false; break; case BTC_GET_S4_WIFI_RSSI: - *s32_tmp = halbtc_get_wifi_rssi(rtlpriv); + *s32_tmp = rtlpriv->dm.undec_sm_pwdb; break; case BTC_GET_S4_HS_RSSI: *s32_tmp = 0;
Re: RT2870 failure in kernel 4.12.8
On 08/31/2017 02:55 AM, Stanislaw Gruszka wrote: I think it is the issue addressed by this 4.12 patch: https://marc.info/?l=linux-wireless&m=150366111408179&w=2 Patch for 4.13+ kernels is here: https://marc.info/?l=linux-wireless&m=150367345912061&w=2 A potential problem with this solution is that commit 41977e86c984 ("rt2x00: add support for MT7620") has been in the kernel since 4.12.0, but the openSUSE problem was reported not to occur until 4.12.8. I have asked that this patch be applied to the openSUSE source and a special test kernel be generated for our OP. I will let you know what develops. I do not have the necessary hardware to do the test in house. Should the patch to wireless-drivers be annotated with a Stable reference so that it is added to 4.12 and 4.13? Thanks, Larry
Re: [PATCH 13/30] brcmfmac: Clarify if using braces.
On 30/08/17 20:11, Arend van Spriel wrote: >> Whilst this if () statement is technically correct, it lacks clarity. > > I don't see the unclarity here. In my opinion people reading the code > should have a good level in C language and a decent level of curiosity > when they come across a function/macro like skb_queue_walk(). I thought it to be part of the general codingstyle for the kernel that multi-line ifs and elses should be in braces, although I accept that technically the if-clause is a single block-level statement. Having said that, *this* specific example falls into a grey area in the codingstyle, which covers multi-statement, multi-line if() clauses and single-statement, single-line ones. It does not cover single-statement, multi-line examples such as the one here. Whilst I can't therefore definitively justify my position, I can show, for example, line 999 in net/mac80211/iface.c where a for() statement uses braces around the skb_queue_walk() for (i = 0; i < IEEE80211_MAX_QUEUES; i++) { skb_queue_walk_safe(&local->pending[i], skb, tmp) { struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb); if (info->control.vif == &sdata->vif) { __skb_unlink(skb, &local->pending[i]); ieee80211_free_txskb(&local->hw, skb); } } } And the following in ath9k_htc_tx_cleanup_queue() if (process) { skb_queue_walk_safe(&queue, skb, tmp) { __skb_unlink(skb, &queue); ath9k_htc_tx_process(priv, skb, NULL); } } So I feel that we should do the same. -Ian
Re: [PATCH 18/30] brcmfmac: Cleanup offsetof()
On 30/08/17 20:37, Arend van Spriel wrote: > On 22-08-17 13:25, Ian Molton wrote: >> +#define __sd_reg(field) \ >> +(offsetof(struct sdpcmd_regs, field)) > > I really dislike __foo() stuff. Please just stick with uppercase for > macros, so SD_REG(). I am fine with dropping the base here. I'm fine with that. Will change. -Ian
Re: [PATCH] wl1251: add a missing spin_lock_init()
From: Pavel Machek Date: Thu, 31 Aug 2017 16:47:43 +0200 > Dave, Linus -- can you still take the patch? Pavel, please do not bypass maintainers like this. It's really rude, and if you do things like that instead of trying to work properly with us, your relationship with these maintainers will suffer in the long term. Thank you.
Re: [v3,1/2] ath10k: add the PCI PM core suspend/resume ops
ryan...@qti.qualcomm.com wrote: > The actual PCI suspend/resume in ath10k has been handled in wow.c, > but in the case of the device doesn't support remote wakeup, > the .hif_suspend() and .hif_resume() will never be handled. > > ath10k_wow_op_suspend() > { > if (WARN_ON(!test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT, > ar->running_fw->fw_file.fw_features))) { > ret = 1; > goto exit; > } > > > > ret = ath10k_hif_suspend(ar); > } > > So register the PCI PM core to support the suspend/resume if the device > doesn't support remote wakeup. > > Signed-off-by: Ryan Hsu > Signed-off-by: Kalle Valo 2 patches applied to ath-next branch of ath.git, thanks. 32faa3f0ee50 ath10k: add the PCI PM core suspend/resume ops 393b706cf20c ath10k: configure and enable the wakeup capability -- https://patchwork.kernel.org/patch/9916215/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] wl1251: add a missing spin_lock_init()
Hi! > From: Pavel Machek > Date: Thu, 31 Aug 2017 16:47:43 +0200 > > > Dave, Linus -- can you still take the patch? > > Pavel, please do not bypass maintainers like this. > > It's really rude, and if you do things like that instead of > trying to work properly with us, your relationship with > these maintainers will suffer in the long term. Do you mean I'm being rude to Kalle, or rude to you? In the part you snipped, Kalle asked me to do just that: # I'm not planning to submit pull requests to 4.13 anymore. If you think # this is so important that it needs to be applied in the last minute (I # don't) you could always try to convince Dave to take it directly. ..and as I still believe patch should go in, that's what I did. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] wl1251: add a missing spin_lock_init()
From: Pavel Machek Date: Thu, 31 Aug 2017 20:57:19 +0200 > Hi! > >> From: Pavel Machek >> Date: Thu, 31 Aug 2017 16:47:43 +0200 >> >> > Dave, Linus -- can you still take the patch? >> >> Pavel, please do not bypass maintainers like this. >> >> It's really rude, and if you do things like that instead of >> trying to work properly with us, your relationship with >> these maintainers will suffer in the long term. > > Do you mean I'm being rude to Kalle, or rude to you? He said "to David", not "David and Linus".
Re: [PATCH] wl1251: add a missing spin_lock_init()
Hi! On Thu 2017-08-31 12:26:45, David Miller wrote: > From: Pavel Machek > Date: Thu, 31 Aug 2017 20:57:19 +0200 > > > Hi! > > > >> From: Pavel Machek > >> Date: Thu, 31 Aug 2017 16:47:43 +0200 > >> > >> > Dave, Linus -- can you still take the patch? > >> > >> Pavel, please do not bypass maintainers like this. > >> > >> It's really rude, and if you do things like that instead of > >> trying to work properly with us, your relationship with > >> these maintainers will suffer in the long term. > > > > Do you mean I'm being rude to Kalle, or rude to you? > > He said "to David", not "David and Linus". Ok. If I knew you would be replying so quickly, I'd acted differently. I did not want to be rude. But I'd still like to get the patch in. Do you plan to send another pull request to Linus, and can you take the patch, please? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] wl1251: add a missing spin_lock_init()
From: Pavel Machek Date: Thu, 31 Aug 2017 21:59:33 +0200 > Do you plan to send another pull request to Linus, and can you take > the patch, please? Yes and yes.
Re: [PATCH] mwifiex: check for mfg_mode in add_virtual_intf
On Thu, Aug 31, 2017 at 12:16:58AM +0530, Ganapathi Bhat wrote: > If driver is loaded with 'mfg_mode' enabled, then the sending > commands are not allowed. So, when mwifiex_send_cmd fails in > mwifiex_add_virtual_intf, driver must check for 'mfg_mode' before > returning error. > > Fixes: 7311ea850079 ("mwifiex: fix AP start problem for newly added > interface") > Signed-off-by: Ganapathi Bhat > --- > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > index ffada17..1856205 100644 > --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > @@ -2967,11 +2967,11 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct > wiphy *wiphy, > > ret = mwifiex_send_cmd(priv, HostCmd_CMD_SET_BSS_MODE, > HostCmd_ACT_GEN_SET, 0, NULL, true); > - if (ret) > + if (ret && !adapter->mfg_mode) It doesn't feel like ignoring errors is the best approach here, especially when it's only a single command that we could easily just skip. So, why don't you just skip it, like this? if (!adapter->mfg_mode) { ret = mwifiex_send_cmd(...); if (ret) goto err_set_bss_mode; } > goto err_set_bss_mode; > > ret = mwifiex_sta_init_cmd(priv, false, false); > - if (ret) > + if (ret && !adapter->mfg_mode) > goto err_sta_init; Same here; I think it's safe to just completely skip mwifiex_sta_init_cmd(), no? Brian > > mwifiex_setup_ht_caps(&wiphy->bands[NL80211_BAND_2GHZ]->ht_cap, priv); > -- > 1.9.1 >
Re: [PATCH] ath9k: remove cast to void pointer
On Thu, 2017-08-31 at 18:37 +0530, Himanshu Jha wrote: > casting to void pointer from any pointer type and vice-versa is done > implicitly and therefore casting is not needed in such a case. You said you were going to remember to mention the tool and script that did this.
Re: [PATCH 1/2] iwlwifi: fix long debug print
On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote: > From: Liad Kaufman > > There is a debug print that sometimes reaches over > 110 chars, thus generating a warning in those cases. What emits a warning here?
[PATCH 13/31] timer: Remove meaningless .data/.function assignments
Several timer users needlessly reset their .function/.data fields during their timer callback, but nothing else changes them. Some users do not use their .data field at all. Each instance is removed here. Cc: Krzysztof Halasa Cc: Aditya Shankar Cc: Ganesh Krishna Cc: Greg Kroah-Hartman Cc: Jens Axboe Cc: net...@vger.kernel.org Cc: linux-wireless@vger.kernel.org Cc: de...@driverdev.osuosl.org Signed-off-by: Kees Cook --- drivers/block/amiflop.c | 3 +-- drivers/net/wan/hdlc_cisco.c | 2 -- drivers/net/wan/hdlc_fr.c | 2 -- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +--- 4 files changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c index c4b1cba27178..6680d75bc857 100644 --- a/drivers/block/amiflop.c +++ b/drivers/block/amiflop.c @@ -323,7 +323,7 @@ static void fd_deselect (int drive) } -static void motor_on_callback(unsigned long nr) +static void motor_on_callback(unsigned long ignored) { if (!(ciaa.pra & DSKRDY) || --on_attempts == 0) { complete_all(&motor_on_completion); @@ -344,7 +344,6 @@ static int fd_motor_on(int nr) fd_select(nr); reinit_completion(&motor_on_completion); - motor_on_timer.data = nr; mod_timer(&motor_on_timer, jiffies + HZ/2); on_attempts = 10; diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c index c696d42f4502..6c98d85f2773 100644 --- a/drivers/net/wan/hdlc_cisco.c +++ b/drivers/net/wan/hdlc_cisco.c @@ -276,8 +276,6 @@ static void cisco_timer(unsigned long arg) spin_unlock(&st->lock); st->timer.expires = jiffies + st->settings.interval * HZ; - st->timer.function = cisco_timer; - st->timer.data = arg; add_timer(&st->timer); } diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c index de42faca076a..7da2424c28a4 100644 --- a/drivers/net/wan/hdlc_fr.c +++ b/drivers/net/wan/hdlc_fr.c @@ -644,8 +644,6 @@ static void fr_timer(unsigned long arg) state(hdlc)->settings.t391 * HZ; } - state(hdlc)->timer.function = fr_timer; - state(hdlc)->timer.data = arg; add_timer(&state(hdlc)->timer); } diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index 68fd5b3b8b2d..2fca2b017093 100644 --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -275,7 +275,7 @@ static void update_scan_time(void) last_scanned_shadow[i].time_scan = jiffies; } -static void remove_network_from_shadow(unsigned long arg) +static void remove_network_from_shadow(unsigned long unused) { unsigned long now = jiffies; int i, j; @@ -296,7 +296,6 @@ static void remove_network_from_shadow(unsigned long arg) } if (last_scanned_cnt != 0) { - hAgingTimer.data = arg; mod_timer(&hAgingTimer, jiffies + msecs_to_jiffies(AGING_TIME)); } } @@ -313,7 +312,6 @@ static int is_network_in_shadow(struct network_info *pstrNetworkInfo, int i; if (last_scanned_cnt == 0) { - hAgingTimer.data = (unsigned long)user_void; mod_timer(&hAgingTimer, jiffies + msecs_to_jiffies(AGING_TIME)); state = -1; } else { -- 2.7.4
[PATCH] Correctly fail to suspend when SDIO does not support power on suspend
Return error when failing to set power management capabilities flag. This will cause the suspend to fail but the radio will continue to operate. Allowing this to fail without reporting error will cause the radio to be non-functional on resume as it will have lost power. Signed-off-by: Eric Bentley --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 72139b5..2f7d03f 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -1264,8 +1264,10 @@ static int brcmf_ops_sdio_suspend(struct device *dev) else sdio_flags |= MMC_PM_WAKE_SDIO_IRQ; } - if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) + if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) ( brcmf_err("Failed to set pm_flags %x\n", sdio_flags); + return -EINVAL; + } return 0; } -- 2.6.0.GIT
[PATCH] Correctly fail to suspend when SDIO does not support power on suspend
Return error when failing to set power management capabilities flag. This will cause the suspend to fail but the radio will continue to operate. Allowing this to fail without reporting error will cause the radio to be non-functional on resume as it will have lost power. Signed-off-by: Eric Bentley --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 72139b5..2f7d03f 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -1264,8 +1264,10 @@ static int brcmf_ops_sdio_suspend(struct device *dev) else sdio_flags |= MMC_PM_WAKE_SDIO_IRQ; } - if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) + if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) ( brcmf_err("Failed to set pm_flags %x\n", sdio_flags); + return -EINVAL; + } return 0; } -- 2.6.0.GIT
Re: [PATCH] Correctly fail to suspend when SDIO does not support power on suspend
On Thu, Aug 31, 2017 at 4:44 PM, Eric Bentley wrote: > - if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) > + if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) ( Hi Eric, Shouldn't that be a '{' instead of '('? Maybe I'm missing some context, but that doesn't look compilable. :) - Steve
Re: [PATCH] Correctly fail to suspend when SDIO does not support power on suspend
Yep – tried to clean some white space up at the last minute…ugh On 8/31/17, 7:49 PM, "steve.deros...@gmail.com on behalf of Steve deRosier" wrote: On Thu, Aug 31, 2017 at 4:44 PM, Eric Bentley wrote: > - if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) > + if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) ( Hi Eric, Shouldn't that be a '{' instead of '('? Maybe I'm missing some context, but that doesn't look compilable. :) - Steve
Re: [PATCH v2] Correctly fail to suspend when SDIO does not support power on suspend
Return error when failing to set power management capabilities flag. This will cause the suspend to fail but the radio will continue to operate. Allowing this to fail without reporting error will cause the radio to be non-functional on resume as it will have lost power. Signed-off-by: Eric Bentley eric.bent...@lairdtech.com --- v2: corrected errant ( with { --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 72139b5..2f7d03f 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -1264,8 +1264,10 @@ static int brcmf_ops_sdio_suspend(struct device *dev) else sdio_flags |= MMC_PM_WAKE_SDIO_IRQ; } - if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) + if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) { brcmf_err("Failed to set pm_flags %x\n", sdio_flags); + return -EINVAL; + } return 0; } -- 2.6.0.GIT
Re: RT2870 failure in kernel 4.12.8
On 08/31/2017 02:55 AM, Stanislaw Gruszka wrote: On Wed, Aug 30, 2017 at 12:03:06PM -0500, Larry Finger wrote: Stanislaw and Helmut, In a bug report at https://bugzilla.suse.com/show_bug.cgi?id=1055826, the OP reports that his RT3572 fails to work after an upgrade from the openSUSE Tumbleweed kernel 4.12.7 to 4.12.8. I checked the kernel configuration and did not see any problems. Are you aware of anyone reporting problems with rt2800usb in 4.12.8 kernels? I think it is the issue addressed by this 4.12 patch: https://marc.info/?l=linux-wireless&m=150366111408179&w=2 Patch for 4.13+ kernels is here: https://marc.info/?l=linux-wireless&m=150367345912061&w=2 That patch did fix the problem. Thanks for the help. Larry
Re: [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps
On Thu, 2017-08-31 at 01:21 +0530, Ganapathi Bhat wrote: > Current driver prints dev_alloc_skb failures everytime while > submitting RX URBs. This failure might be frequent in some > low resource platforms. So, wait for a threshold failure > count before start priting the error. This change is a follow > up for the 'commit 7b368e3d15c3 > ("mwifiex: resubmit failed to submit RX URBs in main thread")' [] > diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c > b/drivers/net/wireless/marvell/mwifiex/usb.c [] > @@ -300,9 +300,16 @@ static int mwifiex_usb_submit_rx_urb(struct urb_context > *ctx, int size) > if (card->rx_cmd_ep != ctx->ep) { > ctx->skb = dev_alloc_skb(size); > if (!ctx->skb) { > - mwifiex_dbg(adapter, ERROR, > - "%s: dev_alloc_skb failed\n", __func__); > + if (++card->rx_urb_failure_count > > + MWIFIEX_RX_URB_FAILURE_THRESHOLD) { > + mwifiex_dbg(adapter, ERROR, > + "%s: dev_alloc_skb failed, failure > count = %u\n", > + __func__, > + card->rx_urb_failure_count); > + } > return -ENOMEM; Why not use a ratelimit?
Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments
On Thu, Aug 31, 2017 at 04:29:25PM -0700, Kees Cook wrote: > Several timer users needlessly reset their .function/.data fields during > their timer callback, but nothing else changes them. Some users do not > use their .data field at all. Each instance is removed here. > > Cc: Krzysztof Halasa > Cc: Aditya Shankar > Cc: Ganesh Krishna > Cc: Greg Kroah-Hartman > Cc: Jens Axboe > Cc: net...@vger.kernel.org > Cc: linux-wireless@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Signed-off-by: Kees Cook > --- > drivers/block/amiflop.c | 3 +-- > drivers/net/wan/hdlc_cisco.c | 2 -- > drivers/net/wan/hdlc_fr.c | 2 -- > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +--- > 4 files changed, 2 insertions(+), 9 deletions(-) For the staging driver: Acked-by: Greg Kroah-Hartman
Re: [PATCH v2] Correctly fail to suspend when SDIO does not support power on suspend
Eric Bentley writes: > Return error when failing to set power management capabilities flag. This > will cause the suspend to fail but the radio > will continue to operate. Allowing this to fail without reporting error will > cause the radio to be non-functional on > resume as it will have lost power. > > Signed-off-by: Eric Bentley eric.bent...@lairdtech.com Word wrap the commit log to 72 chars (or so) per line. Also add a prefix to the title: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong -- Kalle Valo
Re: [PATCH 1/2] iwlwifi: fix long debug print
On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote: > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote: > > From: Liad Kaufman > > > > There is a debug print that sometimes reaches over > > 110 chars, thus generating a warning in those cases. > > What emits a warning here? We have a WARN_ON in iwl-devtrace-msg.h: #define MAX_MSG_LEN 110 DECLARE_EVENT_CLASS(iwlwifi_msg_event, TP_PROTO(struct va_format *vaf), TP_ARGS(vaf), TP_STRUCT__entry( __dynamic_array(char, msg, MAX_MSG_LEN) ), TP_fast_assign( WARN_ON_ONCE(vsnprintf(__get_dynamic_array(msg), MAX_MSG_LEN, vaf->fmt, *vaf->va) >= MAX_MSG_LEN); ), TP_printk("%s", __get_str(msg)) ); We limit all our tracing messages to 110 bytes. Anything longer than that starts getting annoying to read. In mac80211 we limit it even further, to 100 bytes, so this is not unique to the iwlwifi driver. -- Cheers, Luca.
Re: [PATCH 1/2] iwlwifi: fix long debug print
On Fri, 2017-09-01 at 08:37 +0300, Luca Coelho wrote: > On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote: > > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote: > > > From: Liad Kaufman > > > > > > There is a debug print that sometimes reaches over > > > 110 chars, thus generating a warning in those cases. > > > > What emits a warning here? > > We have a WARN_ON in iwl-devtrace-msg.h: > > #define MAX_MSG_LEN 110 OK, thanks for the hint. The commit message is a bit obscure. It might make sense to add a comment to describe these trace events coming from TRACE_EVENT(iwlwifi_dbg, All the IWL_DEBUG_ use this trace message maximum.
Incorrect mesh path seq num
Hi guys, I'm seeing a problem when I work on the wireless mesh between two linux devices. The root node has 3.18 kernel while the next hop station runs 2.6.37 kernel. I found the mpath->sn value is incorrect most of the time on the device having 2.6.37 kernel. After examining the code, in function hwmp_route_info_get [mesh_hwmp.c], after mesh_path_lookup, the sequence number (i.e, mpath->sn) is incorrect. For instance, I see mpath->sn having value 0x3095. It should be 0x9530, while the orig_sn is having value 0x9531. This results in the last hop metric to become zero in function mesh_rx_path_sel_frame and hwmp_preq_frame_process doesn't get called. Is this a known problem? Can anyone provide suggestions to debug further?
[PATCH v2] ath9k: remove cast to void pointer
casting to void pointer from any pointer type and vice-versa is done implicitly and therefore casting is not needed in such a case. Done using Coccinellle. Semantic Patch used : @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T *)x)->f | - (T *) e ) Signed-off-by: Himanshu Jha --- drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 ++-- drivers/net/wireless/ath/ath9k/dfs.c| 2 +- drivers/net/wireless/ath/ath9k/hif_usb.c| 8 drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 24 drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 6 +++--- drivers/net/wireless/ath/ath9k/init.c | 8 drivers/net/wireless/ath/ath9k/main.c | 2 +- drivers/net/wireless/ath/ath9k/mci.c| 2 +- drivers/net/wireless/ath/ath9k/wmi.c| 4 ++-- 11 files changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c index b3f20b3..e1fe7a7 100644 --- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c +++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c @@ -480,7 +480,7 @@ EXPORT_SYMBOL(ath9k_hw_addrxbuf_edma); int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs, void *buf_addr) { - struct ar9003_rxs *rxsp = (struct ar9003_rxs *) buf_addr; + struct ar9003_rxs *rxsp = buf_addr; unsigned int phyerr; if ((rxsp->status11 & AR_RxDone) == 0) @@ -610,7 +610,7 @@ void ath9k_hw_setup_statusring(struct ath_hw *ah, void *ts_start, ah->ts_paddr_start = ts_paddr_start; ah->ts_paddr_end = ts_paddr_start + (size * sizeof(struct ar9003_txs)); ah->ts_size = size; - ah->ts_ring = (struct ar9003_txs *) ts_start; + ah->ts_ring = ts_start; ath9k_hw_reset_txstatus_ring(ah); } diff --git a/drivers/net/wireless/ath/ath9k/dfs.c b/drivers/net/wireless/ath/ath9k/dfs.c index 1ece42c..40a397f 100644 --- a/drivers/net/wireless/ath/ath9k/dfs.c +++ b/drivers/net/wireless/ath/ath9k/dfs.c @@ -326,7 +326,7 @@ void ath9k_dfs_process_phyerr(struct ath_softc *sc, void *data, if (ard.ext_rssi & 0x80) ard.ext_rssi = 0; - vdata_end = (char *)data + datalen; + vdata_end = data + datalen; ard.pulse_bw_info = vdata_end[-1]; ard.pulse_length_ext = vdata_end[-2]; ard.pulse_length_pri = vdata_end[-3]; diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 0d9687a..71d1725 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -424,7 +424,7 @@ static int hif_usb_send_tx(struct hif_device_usb *hif_dev, struct sk_buff *skb) static void hif_usb_start(void *hif_handle) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; unsigned long flags; hif_dev->flags |= HIF_USB_START; @@ -436,7 +436,7 @@ static void hif_usb_start(void *hif_handle) static void hif_usb_stop(void *hif_handle) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; struct tx_buf *tx_buf = NULL, *tx_buf_tmp = NULL; unsigned long flags; @@ -457,7 +457,7 @@ static void hif_usb_stop(void *hif_handle) static int hif_usb_send(void *hif_handle, u8 pipe_id, struct sk_buff *skb) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; int ret = 0; switch (pipe_id) { @@ -492,7 +492,7 @@ static inline bool check_index(struct sk_buff *skb, u8 idx) static void hif_usb_sta_drain(void *hif_handle, u8 idx) { - struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle; + struct hif_device_usb *hif_dev = hif_handle; struct sk_buff *skb, *tmp; unsigned long flags; diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c index 2c0e4d2..f20c839 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c @@ -384,7 +384,7 @@ void ath9k_htc_set_tsfadjust(struct ath9k_htc_priv *priv, static void ath9k_htc_beacon_iter(void *data, u8 *mac, struct ieee80211_vif *vif) { - bool *beacon_configured = (bool *)data; + bool *beacon_configured = data; struct ath9k_htc_vif *avp = (struct ath9k_htc_vif *) vif->drv_priv; if (vif->type == NL80211_IFTYPE_STATION && diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c index defacc6..9e0c237 100644 --- a/drivers/net/wireless/ath/ath9k/h
[PATCH] iw: Null check before accessing n_mcs variable
From: Amit Khatri Date: Thu, 24 Aug 2017 00:16:26 -0700 Subject: [PATCH] iw: Null check before accessing n_mcs variable If all cases will fail n_mcs variable fail to get any assignement and remain NULL. so better to check NULL before dereference. Signed-off-by: Amit Khatri --- bitrate.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bitrate.c b/bitrate.c index 4a026a4..3e58337 100644 --- a/bitrate.c +++ b/bitrate.c @@ -185,7 +185,8 @@ static int handle_bitrates(struct nl80211_state *state, return 1; if (tmpl < 0 || tmpl > 255) return 1; - mcs[(*n_mcs)++] = tmpl; + if(n_mcs!=NULL) + mcs[(*n_mcs)++] = tmpl; break; case S_VHT: if (*vht_argc >= VHT_ARGC_MAX) -- 1.7.9.5