Re: RT2870 failure in kernel 4.12.8

[Stanislaw Gruszka]

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

[Kalle Valo]

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

[Karel Zak]

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

[Sergey Matyukevich]

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

[Simon Dinkin]

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

[Kalle Valo]

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

[Kalle Valo]

(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

[Kalle Valo]

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

[Kalle Valo]

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

[Kalle Valo]

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

[Kalle Valo]

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

[Anna-Maria Gleixner]

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

[Kalle Valo]

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

[Kalle Valo]

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

[Kalle Valo]

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

[Kalle Valo]

"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

[Himanshu Jha]

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()

[Pavel Machek]

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

[Larry Finger]

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()

[Ian Molton]

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.

[Ian Molton]

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

[Larry Finger]

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

[Larry Finger]

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.

[Ian Molton]

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()

[Ian Molton]

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()

[David Miller]

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

[Kalle Valo]

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()

[Pavel Machek]

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()

[David Miller]

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()

[Pavel Machek]

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()

[David Miller]

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

[Brian Norris]

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

[Joe Perches]

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

[Joe Perches]

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

[Kees Cook]

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

[Eric Bentley]

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

[Eric Bentley]

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

[Steve deRosier]

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

[Eric Bentley]

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

[Eric Bentley]

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

[Larry Finger]

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

[Joe Perches]

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

[Greg Kroah-Hartman]

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

[Kalle Valo]

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

[Luca Coelho]

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

[Joe Perches]

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

[Greg Maitz]

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

[Himanshu Jha]

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

[Amit Khatri]

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