[PATCH V2 2/2] ath6kl: replace semaphore with mutex

[Chaehyun Lim]

It replaces struct semaphore sem with struct mutex mutex

Reported-by: kbuild test robot 
Signed-off-by: Chaehyun Lim 
---
V2: fix build failure reported by kbuild test robot

 drivers/net/wireless/ath/ath6kl/cfg80211.c | 30 +++---
 drivers/net/wireless/ath/ath6kl/core.c |  2 +-
 drivers/net/wireless/ath/ath6kl/core.h |  2 +-
 drivers/net/wireless/ath/ath6kl/debug.c| 12 ++--
 drivers/net/wireless/ath/ath6kl/init.c |  6 +++---
 5 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f6b5390..d4eb066 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -480,14 +480,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
return -EINVAL;
}
 
-   if (down_interruptible(>sem)) {
+   if (mutex_lock_interruptible(>mutex)) {
ath6kl_err("busy, couldn't get access\n");
return -ERESTARTSYS;
}
 
if (test_bit(DESTROY_IN_PROGRESS, >flag)) {
ath6kl_err("busy, destroy in progress\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EBUSY;
}
 
@@ -500,14 +500,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
 WMI_TIMEOUT);
if (signal_pending(current)) {
ath6kl_err("cmd queue drain timeout\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EINTR;
}
}
 
status = ath6kl_set_assoc_req_ies(vif, sme->ie, sme->ie_len);
if (status) {
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
 
@@ -522,7 +522,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
  vif->req_bssid,
  vif->ch_hint);
 
-   up(>sem);
+   mutex_unlock(>mutex);
if (status) {
ath6kl_err("wmi_reconnect_cmd failed\n");
return -EIO;
@@ -548,7 +548,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
 
status = ath6kl_set_auth_type(vif, sme->auth_type);
if (status) {
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
 
@@ -570,7 +570,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
if (sme->key_idx > WMI_MAX_KEY_INDEX) {
ath6kl_err("key index %d out of bounds\n",
   sme->key_idx);
-   up(>sem);
+   mutex_unlock(>mutex);
return -ENOENT;
}
 
@@ -594,7 +594,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
if (ath6kl_wmi_bssfilter_cmd(ar->wmi, vif->fw_vif_idx,
 ALL_BSS_FILTER, 0) != 0) {
ath6kl_err("couldn't set bss filtering\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EIO;
}
}
@@ -626,7 +626,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
   0);
if (status) {
ath6kl_err("couldn't set listen intervel\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
}
@@ -651,7 +651,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
ath6kl_wmi_scanparams_cmd(ar->wmi, vif->fw_vif_idx, 0, 0,
  sme->bg_scan_period, 0, 0, 0, 3, 0, 0, 0);
 
-   up(>sem);
+   mutex_unlock(>mutex);
 
if (status == -EINVAL) {
memset(vif->ssid, 0, sizeof(vif->ssid));
@@ -832,7 +832,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
return -EBUSY;
}
 
-   if (down_interruptible(>sem)) {
+   if (mutex_lock_interruptible(>mutex)) {
ath6kl_err("busy, couldn't get access\n");
return -ERESTARTSYS;
}
@@ -845,7 +845,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
if (!test_bit(SKIP_SCAN, >flag))
memset(vif->req_bssid, 0, sizeof(vif->req_bssid));
 
-   up(>sem);
+   mutex_unlock(>mutex);
 
vif->sme_state = SME_DISCONNECTED;
 
@@ -1775,7 +1775,7 @@ 

Re: [PATCH] mac80211: Fix mesh estab_plinks counting in STA removal case

[Bob Copeland]

On Tue, Jun 21, 2016 at 06:26:02PM -0400, Bob Copeland wrote:
> Looks further buggy, so perhaps this untested patch would work, i.e.
    (still)

> @@ -370,13 +372,19 @@ u32 mesh_plink_deactivate(struct sta_info *sta)
>  
>   spin_lock_bh(>mesh->plink_lock);
>   changed = __mesh_plink_deactivate(sta);
> - sta->mesh->reason = WLAN_REASON_MESH_PEER_CANCELED;
> - mesh_plink_frame_tx(sdata, sta, WLAN_SP_MESH_PEERING_CLOSE,
> - sta->sta.addr, sta->mesh->llid, sta->mesh->plid,
> - sta->mesh->reason);
> +
> + if (sdata->u.mesh.user_mpm) {

should be !sdata->u.mesh.user_mpm :)

> + sta->mesh->reason = WLAN_REASON_MESH_PEER_CANCELED;
> + mesh_plink_frame_tx(sdata, sta, WLAN_SP_MESH_PEERING_CLOSE,
> + sta->sta.addr, sta->mesh->llid, 
> sta->mesh->plid,
> + sta->mesh->reason);
> + }
>   spin_unlock_bh(>mesh->plink_lock);
>   mesh_path_flush_by_nexthop(sta);
>  
> + /* make sure no readers can access nexthop sta from here on */
> + synchronize_net();
> +
>   return changed;
>  }
>  
> -- 
> 2.9.0
> 

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Fix mesh estab_plinks counting in STA removal case

[Bob Copeland]

On Tue, Jun 21, 2016 at 09:09:10PM +0200, Johannes Berg wrote:
> 
> >      */
> > -   changed = mesh_accept_plinks_update(sdata);
> > +   if (sdata->u.mesh.user_mpm &&
> > +   sta->mesh->plink_state == NL80211_PLINK_ESTAB)
> > +   changed |= mesh_plink_dec_estab_count(sdata);
> > +   changed |= mesh_accept_plinks_update(sdata);
> >     if (!sdata->u.mesh.user_mpm) {
> >     changed |= mesh_plink_deactivate(sta);
> >     del_timer_sync(>mesh->plink_timer);
> > 
> 
> Does it have to be done before the mesh_accept_plinks_update()?
> 
> If not, you should put it with the existing u.mesh.user_mpm check. If
> yes, then the code is further buggy since only mesh_plink_deactivate()
> will call it when the kernel MPM is used.

Looks further buggy, so perhaps this untested patch would work, i.e.
move the accepting-plinks change closer to the decrement, and push
the user_mpm check down into mesh_plink_deactivate to just
avoid sending the peering frames.  [There's also a bit there for
power saving that we likely want to keep for secure networks.]

Then again maybe accepting_plinks flag should just be computed when
used instead of tracking the state separately.

---
 net/mac80211/mesh.c   | 18 ++
 net/mac80211/mesh_plink.c | 16 
 2 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 21b1fdf..3c150f8 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -148,22 +148,8 @@ u32 mesh_accept_plinks_update(struct ieee80211_sub_if_data 
*sdata)
 void mesh_sta_cleanup(struct sta_info *sta)
 {
struct ieee80211_sub_if_data *sdata = sta->sdata;
-   u32 changed;
-
-   /*
-* maybe userspace handles peer allocation and peering, but in either
-* case the beacon is still generated by the kernel and we might need
-* an update.
-*/
-   changed = mesh_accept_plinks_update(sdata);
-   if (!sdata->u.mesh.user_mpm) {
-   changed |= mesh_plink_deactivate(sta);
-   del_timer_sync(>mesh->plink_timer);
-   }
-
-   /* make sure no readers can access nexthop sta from here on */
-   mesh_path_flush_by_nexthop(sta);
-   synchronize_net();
+   u32 changed = mesh_plink_deactivate(sta);
+   del_timer_sync(>mesh->plink_timer);
 
if (changed)
ieee80211_mbss_info_change_notify(sdata, changed);
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 79f2a0a..69ac7a8 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -349,6 +349,8 @@ static u32 __mesh_plink_deactivate(struct sta_info *sta)
changed = mesh_plink_dec_estab_count(sdata);
sta->mesh->plink_state = NL80211_PLINK_BLOCKED;
 
+   changed |= mesh_accept_plinks_update(sdata);
+
ieee80211_mps_sta_status_update(sta);
changed |= ieee80211_mps_set_sta_local_pm(sta,
NL80211_MESH_POWER_UNKNOWN);
@@ -370,13 +372,19 @@ u32 mesh_plink_deactivate(struct sta_info *sta)
 
spin_lock_bh(>mesh->plink_lock);
changed = __mesh_plink_deactivate(sta);
-   sta->mesh->reason = WLAN_REASON_MESH_PEER_CANCELED;
-   mesh_plink_frame_tx(sdata, sta, WLAN_SP_MESH_PEERING_CLOSE,
-   sta->sta.addr, sta->mesh->llid, sta->mesh->plid,
-   sta->mesh->reason);
+
+   if (sdata->u.mesh.user_mpm) {
+   sta->mesh->reason = WLAN_REASON_MESH_PEER_CANCELED;
+   mesh_plink_frame_tx(sdata, sta, WLAN_SP_MESH_PEERING_CLOSE,
+   sta->sta.addr, sta->mesh->llid, 
sta->mesh->plid,
+   sta->mesh->reason);
+   }
spin_unlock_bh(>mesh->plink_lock);
mesh_path_flush_by_nexthop(sta);
 
+   /* make sure no readers can access nexthop sta from here on */
+   synchronize_net();
+
return changed;
 }
 
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] wlcore: spi: add wl18xx support

[Rob Herring]

On Tue, Jun 21, 2016 at 12:02:06PM +, Reizer, Eyal wrote:
> Add support for using with both wl12xx and wl18xx.
> 
> - all wilink family needs special init command for entering wspi mode.
>   extra clock cycles should be sent after the spi init command while the
>   cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
>   completes the init stage and puts the wilink chip into wspi mode.
> 
> Signed-off-by: Eyal Reizer 
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select instead
> for sending the extra init cycle, which achieves the same hardware purpose.
> update device tree bindings docucmentation accordingly
> 
>  .../bindings/net/wireless/ti,wlcore,spi.txt|  47 ++--
>  drivers/net/wireless/ti/wlcore/spi.c   | 124 
> +
>  2 files changed, 145 insertions(+), 26 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
> b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> index 9180724..35467cf 100644
> --- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> @@ -1,19 +1,30 @@
> -* Texas Instruments wl1271 wireless lan controller
> +* Texas Instruments wl12xx/wl18xx wireless lan controller
>  
> -The wl1271 chip can be connected via SPI or via SDIO. This
> +The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
>  document describes the binding for the SPI connected chip.
>  
>  Required properties:
> -- compatible :  Should be "ti,wl1271"
> +- compatible :  Should be one of the following:
> +* "ti,wl1271"
> +* "ti,wl1273"
> +* "ti,wl1281"
> +* "ti,wl1283"
> +* "ti,wl1801"
> +* "ti,wl1805"
> +* "ti,wl1807"
> +* "ti,wl1831"
> +* "ti,wl1835"
> +* "ti,wl1837"
>  - reg : Chip select address of device
>  - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
> -- ref-clock-frequency : Reference clock frequency
>  - interrupt-parent, interrupts :
>  Should contain parameters for 1 interrupt line.
>  Interrupt parameters: parent, line number, type.
> -- vwlan-supply :Point the node of the regulator that powers/enable 
> the wl1271 chip
> +- vwlan-supply :Point the node of the regulator that powers/enable 
> the
> +wl12xx/wl18xx chip
>  
>  Optional properties:
> +- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
>  - clock-xtal :  boolean, clock is generated from XTAL
>  
>  - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
> @@ -21,10 +32,15 @@ Optional properties:
>  
>  Examples:
>  
> +For wl12xx family:
>   {
> - wl1271@1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;

None of this is really relevant to this binding.

> + wlcore: wlcore@0 {

Now your unit-address and reg value don't match.

>   compatible = "ti,wl1271";
> -
>   reg = <1>;
>   spi-max-frequency = <4800>;
>   clock-xtal;
> @@ -34,3 +50,20 @@ Examples:
>   vwlan-supply = <_fixed>;
>   };
>  };
> +
> +For wl18xx family:
> +{
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + wlcore: wlcore@0 {
> + compatible = "ti,wl1835";
> + vwlan-supply = <_en_reg>;
> + spi-max-frequency = <4800>;
> + reg = <0>;
> + interrupt-parent = <>;
> + interrupts = <27 IRQ_TYPE_EDGE_RISING>;
> + };
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Encrypt "Group addressed privacy" action frames

[Johannes Berg]

> We actually cover (2) for some cases by "accident" since
> ieee80211_rx_h_decrypt() assigns rx->key to rx->sta->gtk[i] if one is
> available. I'm not completely sure this is correct since it applies
> to management frame as well, but that's the way commit
> 897bed8b4320774e56f282cdc1cceb4d77442797 ('mac80211: clean up RX key
> checks') implemented it (Johannes: Could you please take a look
> whether that gtk[] case was really supposed to apply for non-Data
> frames?).
> 

Hm, yeah, that's kinda questionable.

AFAICT we still do the right thing since ieee80211_drop_unencrypted()
contains a check for ieee80211_is_data() and we return in this if
branch, so we never get to the TAINTED check or the actual decrypt.

We could try to just drop unencrypted data frames (that aren't control
port protocol) right here, but it might wreak havoc with the reorder
buffer in case it (erroneously) happens.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Fix mesh estab_plinks counting in STA removal case

[Johannes Berg]

>    */
> - changed = mesh_accept_plinks_update(sdata);
> + if (sdata->u.mesh.user_mpm &&
> + sta->mesh->plink_state == NL80211_PLINK_ESTAB)
> + changed |= mesh_plink_dec_estab_count(sdata);
> + changed |= mesh_accept_plinks_update(sdata);
>   if (!sdata->u.mesh.user_mpm) {
>   changed |= mesh_plink_deactivate(sta);
>   del_timer_sync(>mesh->plink_timer);
> 

Does it have to be done before the mesh_accept_plinks_update()?

If not, you should put it with the existing u.mesh.user_mpm check. If
yes, then the code is further buggy since only mesh_plink_deactivate()
will call it when the kernel MPM is used.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: Add USB ID for Cisco Linksys AE1200

[Arend van Spriel]

On 21-06-16 02:18, Ismael Luceno wrote:
> Signed-off-by: Ismael Luceno 

A bit more description would be nice. I am actually wondering why you
would be adding this. If I am not mistaken the AE1200 can not be handled
by brcmfmac. Otherwise I am interested in a kernel log showing the
device probe sequence with brcmfmac loaded with parameter debug=0x1416.

Regards,
Arend

> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 4 
>  drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 +++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> index 98b15a9..455fc69 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> @@ -1462,11 +1462,15 @@ static int brcmf_usb_reset_resume(struct 
> usb_interface *intf)
>  #define BRCMF_USB_DEVICE(dev_id) \
>   { USB_DEVICE(BRCM_USB_VENDOR_ID_BROADCOM, dev_id) }
>  
> +#define LINKSYS_USB_DEVICE(dev_id)   \
> + { USB_DEVICE(BRCM_USB_VENDOR_ID_LINKSYS, dev_id) }
> +
>  static struct usb_device_id brcmf_usb_devid_table[] = {
>   BRCMF_USB_DEVICE(BRCM_USB_43143_DEVICE_ID),
>   BRCMF_USB_DEVICE(BRCM_USB_43236_DEVICE_ID),
>   BRCMF_USB_DEVICE(BRCM_USB_43242_DEVICE_ID),
>   BRCMF_USB_DEVICE(BRCM_USB_43569_DEVICE_ID),
> + LINKSYS_USB_DEVICE(BRCM_USB_43235_LINKSYS_DEVICE_ID),
>   { USB_DEVICE(BRCM_USB_VENDOR_ID_LG, BRCM_USB_43242_LG_DEVICE_ID) },
>   /* special entry for device with firmware loaded and running */
>   BRCMF_USB_DEVICE(BRCM_USB_BCMFW_DEVICE_ID),
> diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h 
> b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
> index 699f2c2..513 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
> @@ -22,6 +22,7 @@
>  
>  #define BRCM_USB_VENDOR_ID_BROADCOM  0x0a5c
>  #define BRCM_USB_VENDOR_ID_LG0x043e
> +#define BRCM_USB_VENDOR_ID_LINKSYS   0x13b1
>  #define BRCM_PCIE_VENDOR_ID_BROADCOM PCI_VENDOR_ID_BROADCOM
>  
>  /* Chipcommon Core Chip IDs */
> @@ -56,6 +57,8 @@
>  
>  /* USB Device IDs */
>  #define BRCM_USB_43143_DEVICE_ID 0xbd1e
> +#define BRCM_USB_43235_LINKSYS_DEVICE_ID \
> + 0x0039
>  #define BRCM_USB_43236_DEVICE_ID 0xbd17
>  #define BRCM_USB_43242_DEVICE_ID 0xbd1f
>  #define BRCM_USB_43242_LG_DEVICE_ID  0x3101
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: Add USB ID for Cisco Linksys AE1200

[Rafał Miłecki]

On 21 June 2016 at 18:58, Ismael Luceno  wrote:
> On 21/Jun/2016 07:45, Rafał Miłecki wrote:
>> On 21 June 2016 at 02:18, Ismael Luceno  wrote:
>> > @@ -56,6 +57,8 @@
>> >
>> >  /* USB Device IDs */
>> >  #define BRCM_USB_43143_DEVICE_ID   0xbd1e
>> > +#define BRCM_USB_43235_LINKSYS_DEVICE_ID \
>> > +   0x0039
>>
>> I guess you wanted to have number aligned to the column of other ones?
>> I'm not sure if that improves readability at all.
>
> Yes. Would you suggest to align more to the right? I didn't want to
> modify everything just to add a new one.

I wouldn't care that much about alignment. I'm sure there already some
misaligned numbers, fields & comments in brcm80211 header.

I would just use name\t0x0039 pattern.

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Encrypt "Group addressed privacy" action frames

[Jouni Malinen]

On Tue, Jun 21, 2016 at 03:16:22PM +0900, Masashi Honma wrote:
> On 2016年06月21日 06:25, Jouni Malinen wrote:
> > What about RX side?
> 
> Previously, MGTK and IGTK was identical key.
> Now new wpa_supplicant can provide correct IGTK.

> I have tested with new IGTK, RX side can work without
> modification.

Please keep in mind that "working" here means two things:
(1) being able decrypt the frame,
(2) being able to reject the frame if it was not properly protected. It
is that (2) that is unlikely to be covered here..

We actually cover (2) for some cases by "accident" since
ieee80211_rx_h_decrypt() assigns rx->key to rx->sta->gtk[i] if one is
available. I'm not completely sure this is correct since it applies to
management frame as well, but that's the way commit
897bed8b4320774e56f282cdc1cceb4d77442797 ('mac80211: clean up RX key
checks') implemented it (Johannes: Could you please take a look whether
that gtk[] case was really supposed to apply for non-Data frames?).
Interestingly, even on the TX side, we had code that picked tx->key for
these group addressed Action frames, but that got then cleared later..

That said, if rx->sta->gtk[i] is not set for any value of i, we would
not enforce encryption of "group addressed privacy" Action frames as far
as I can tell. This may be a pretty small window since RX MGTK is
supposed to get set immediately for each peer. However, I would not be
surprised if there were indeed a window between adding the STA entry and
marking it authorized and configuring the RX MGTK. And even if this is
not possible, this should really be commented somewhere so that there is
less of a change of accidentally optimizing or cleaning up something
that is needed for this to be protected..

And when operating with PMF enabled, this is clearly broken, i.e., the
RX path accepts BIP protected version of the broadcast Mesh Action frame
while that frame needs to be rejected since it was not encrypted with
CCMP/GCMP.

To cover all these RX cases properly, I'd expect there to be RX path
changes that use ieee80211_is_group_privacy_action() and reject some
cases.. This should like be there in the !ieee80211_has_protected(fc)
case in ieee80211_rx_h_decrypt() before selecting the key and if
ieee80211_is_group_privacy_action() returns true, return RX_DROP_MONITOR
would be needed.

-- 
Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: Add USB ID for Cisco Linksys AE1200

[Ismael Luceno]

On 21/Jun/2016 07:45, Rafał Miłecki wrote:
> On 21 June 2016 at 02:18, Ismael Luceno  wrote:
> > @@ -56,6 +57,8 @@
> >
> >  /* USB Device IDs */
> >  #define BRCM_USB_43143_DEVICE_ID   0xbd1e
> > +#define BRCM_USB_43235_LINKSYS_DEVICE_ID \
> > +   0x0039
> 
> I guess you wanted to have number aligned to the column of other ones?
> I'm not sure if that improves readability at all.

Yes. Would you suggest to align more to the right? I didn't want to
modify everything just to add a new one.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mac80211: Encrypt "Group addressed privacy" action frames

[Jouni Malinen]

On Tue, Jun 21, 2016 at 03:23:39PM +0900, Masashi Honma wrote:

> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> +static inline bool ieee80211_is_group_privacy_action(struct ieee80211_hdr 
> *hdr)

This is somewhat problematic since no indication of the frame length is
passed in here and we are reading beyond the frame header below.. Maybe
this should use the same style as ieee80211_is_robust_mgmt_frame()
instead, i.e., use skb as the argument and define
_ieee80211_is_group_privacy_action() to take in struct ieee80211_hdr *.

> + return mgmt->u.action.category == WLAN_CATEGORY_MESH_ACTION ||
> + mgmt->u.action.category == WLAN_CATEGORY_MULTIHOP_ACTION;

These read the buffer at offset 24, i.e., just after the header. This
should do same as ieee80211_is_robust_mgmt_frame(), i.e., return false
if skb->len < 25.

> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> @@ -608,7 +611,6 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
>   bool skip_hw = false;
>  
>   /* TODO: add threshold stuff again */
> -
>   switch (tx->key->conf.cipher) {
>   case WLAN_CIPHER_SUITE_WEP40:
>   case WLAN_CIPHER_SUITE_WEP104:

This looks completely separate item and I don't see why we would even
delete that empty line.. In any case, it should probably not be in this
patch.
 
-- 
Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mwifiex: Reduce endian conversion for REG Host Commands

[kbuild test robot]

Hi,

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Prasun-Maiti/mwifiex-Reduce-endian-conversion-for-REG-Host-Commands/20160621-224149
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:17: sparse: 
>> incompatible types in comparison expression (different base types)
   In file included from include/linux/list.h:8:0,
from include/linux/wait.h:6,
from drivers/net/wireless/marvell/mwifiex/decl.h:26,
from drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:20:
   drivers/net/wireless/marvell/mwifiex/sta_ioctl.c: In function 
'mwifiex_eeprom_read':
   include/linux/kernel.h:742:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:34: note: in expansion 
of macro 'min'
  memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
 ^~~
--
   include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:820:25: sparse: 
>> incompatible types in comparison expression (different base types)
   In file included from include/linux/list.h:8:0,
from include/linux/wait.h:6,
from drivers/net/wireless/marvell/mwifiex/decl.h:26,
from drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:20:
   drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c: In function 
'mwifiex_ret_reg_access':
   include/linux/kernel.h:742:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:821:6: note: in expansion 
of macro 'min'
 min(MAX_EEPROM_DATA, eeprom->byte_count));
 ^~~

vim +1339 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c

  1323   */
  1324  int
  1325  mwifiex_eeprom_read(struct mwifiex_private *priv, u16 offset, u16 bytes,
  1326  u8 *value)
  1327  {
  1328  int ret;
  1329  struct mwifiex_ds_read_eeprom rd_eeprom;
  1330  
  1331  rd_eeprom.offset =  offset;
  1332  rd_eeprom.byte_count = bytes;
  1333  
  1334  /* Send request to firmware */
  1335  ret = mwifiex_send_cmd(priv, HostCmd_CMD_802_11_EEPROM_ACCESS,
  1336 HostCmd_ACT_GEN_GET, 0, _eeprom, 
true);
  1337  
  1338  if (!ret)
> 1339  memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
  1340  rd_eeprom.byte_count));
  1341  return ret;
  1342  }
  1343  
  1344  /*
  1345   * This function sets a generic IE. In addition to generic IE, it can
  1346   * also handle WPA, WPA2 and WAPI IEs.
  1347   */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] staging: wilc1000: Replace kthread with workqueue for host interface

[Arnd Bergmann]

On Monday, June 20, 2016 3:40:19 PM CEST Binoy Jayan wrote:
> Deconstruct the kthread / message_queue logic, replacing it with
> create_singlethread_workqueue() / queue_work() setup, by adding a
> 'struct work_struct' to 'struct host_if_msg'. The current kthread
> hostIFthread() is converted to a work queue helper with the name
> 'host_if_work'.
> 
> Signed-off-by: Binoy Jayan 
> Reviewed-by: Arnd Bergmann 

Hi Binoy,

You made a mistake here in adding the 'Reviewed-by:' tag before I replied with
that tag. I did a review of an earlier version and you addressed the comments
that I had for that, but you can only add the tag after I send that reply.

That said, the patch looks very good to me, and I see no remaining
problems that would prevent it from getting merged (after Atmel have tested
it), just a couple of things that would make it easier to review:

> +static int wilc_enqueue_cmd(struct host_if_msg *msg);
> +static void host_if_work(struct work_struct *work);

A small comment on coding style: we try to avoid forward declaration for local
functions. Instead, you can reorder the code to have the callee first. This
is the order which most readers will expect, and having no forward declarations
in the code makes it more likely that there are no recursions that would
be problematic for stack overflow.

>  /*!
>   *  @author  syounan
> @@ -336,95 +276,19 @@ static int wilc_mq_destroy(struct message_queue *mq)
>   *  @notecopied from FLO glue implementatuion
>   *  @version 1.0
>   */
> -static int wilc_mq_send(struct message_queue *mq,
> -  const void *send_buf, u32 send_buf_size)
> +static int wilc_enqueue_cmd(struct host_if_msg *msg)

I think this API change can be done as a separate patch: the mq and 
send_buf_size
arguments are both constant for all callers, so you can have one patch just
removes them and renames the function, to make the patch that does the
tricky rework smaller.


> - }
> + if (msg->id == HOST_IF_MSG_CONNECT &&
> + msg->vif->hif_drv->usr_scan_req.scan_result) {
> + wilc_enqueue_cmd(msg);
> + usleep_range(2 * 1000, 2 * 1000);
> + goto end;
> + }
>  
> - switch (msg.id) {
> - case HOST_IF_MSG_SCAN:

A similar trick could apply here: we can leave the switch()
indented at the original level by putting it in an 'else'
clause. This again makes the patch shorter and easier to
review, and the optional reformatting can be done as a follow-up.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug with: ath10k: enable parsing per station rx duration for 10.4?

[Mohammed Shafi Shajakhan]

On Tue, Jun 21, 2016 at 07:10:28AM -0700, Ben Greear wrote:
> 
> 
> On 06/20/2016 10:18 PM, Mohammed Shafi Shajakhan wrote:
> >Hi Ben,
> >
> >thanks for reporting ...
> >
> >On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote:
> >>I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 
> >>firmware, and I think
> >>I may have found a regression.
> >
> >[shafi] let me know what is the issue.. some steps to recreate the issue.
> 
> ethtool -S wlan0
> or similar should reproduce it.
> 
> You would see stats timeout messages in dmesg, and with a bit more debugging,
> you notice that the driver is basically busy-spinning trying to get stats over
> WMI and/or it is giving errors because skb pull fails because there actually 
> is
> not extd stats struct.

https://patchwork.kernel.org/patch/9149357/
 should help (Kalle had a cleaned up version in his pending branch
> 
> >>
> >>My 10.4.3-ish firmware source has a bunch of:
> >>
> >>if (stats_id == WMI_REQUEST_PEER_STAT)
> >>logic in it.  In other words, it is not using that id as a bitfield.
> >
> >[shafi] will check this.
> 
> I fixed my firmware to treat it as a bitfield, and to specifically un-set the 
> EXTD stats
> bit, and now it works with my 4.7.  Firmware fix should be backwards 
> compatible.
> 
> 
> >>Now, I can fix the firmware, but I am guessing that at least some stock
> >>10.4 firmware has this same issue, and of course any older firmware
> >>that does not have this change will still be broken.
> >>
> >>So, do you want to back out this patch below, at least the part where it 
> >>sends
> >>in 0x9 as the stats_id?
> >
> >[shafi] request if you can check this please, there was some misunderstanding
> >in the design when this feature got enabled in 10.4, we fixed it in
> >https://patchwork.kernel.org/patch/9149357/
> 
> That might have fixed it, but it is not in 4.7, so I didn't have it
> in my tree when testing yesterday.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mac80211: Encrypt "Group addressed privacy" action frames

[Masashi Honma]

Previously, the action frames to group address was not encrypted. But
[1] "Table 8-38 Category values" indicates "Mesh" and "Multihop" category
action frames should be encrypted (Group addressed privacy == yes). And the
encyption key should be MGTK ([1] 10.13 Group addressed robust management frame
procedures). So this patch modifies the code to make it suitable for spec.

[1] IEEE Std 802.11-2012

Signed-off-by: Masashi Honma 
---
 include/linux/ieee80211.h | 20 
 net/mac80211/tx.c |  7 +--
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b118744..3ff7d3f 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -2487,6 +2488,25 @@ static inline bool ieee80211_is_public_action(struct 
ieee80211_hdr *hdr,
 }
 
 /**
+ * ieee80211_is_group_privacy_action - check if frame is a group addressed
+ * privacy action frame
+ * @hdr: the frame
+ */
+static inline bool ieee80211_is_group_privacy_action(struct ieee80211_hdr *hdr)
+{
+   struct ieee80211_mgmt *mgmt;
+
+   if (!ieee80211_is_action(hdr->frame_control) ||
+   !is_multicast_ether_addr(hdr->addr1))
+   return false;
+
+   mgmt = (struct ieee80211_mgmt *)hdr;
+
+   return mgmt->u.action.category == WLAN_CATEGORY_MESH_ACTION ||
+   mgmt->u.action.category == WLAN_CATEGORY_MULTIHOP_ACTION;
+}
+
+/**
  * ieee80211_tu_to_usec - convert time units (TU) to microseconds
  * @tu: the TUs
  */
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 2030443..5ad205e 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -590,6 +590,9 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
else if (tx->sta &&
 (key = rcu_dereference(tx->sta->ptk[tx->sta->ptk_idx])))
tx->key = key;
+   else if (ieee80211_is_group_privacy_action(hdr) &&
+(key = rcu_dereference(tx->sdata->default_multicast_key)))
+   tx->key = key;
else if (ieee80211_is_mgmt(hdr->frame_control) &&
 is_multicast_ether_addr(hdr->addr1) &&
 ieee80211_is_robust_mgmt_frame(tx->skb) &&
@@ -608,7 +611,6 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
bool skip_hw = false;
 
/* TODO: add threshold stuff again */
-
switch (tx->key->conf.cipher) {
case WLAN_CIPHER_SUITE_WEP40:
case WLAN_CIPHER_SUITE_WEP104:
@@ -622,7 +624,8 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
case WLAN_CIPHER_SUITE_GCMP_256:
if (!ieee80211_is_data_present(hdr->frame_control) &&
!ieee80211_use_mfp(hdr->frame_control, tx->sta,
-  tx->skb))
+  tx->skb) &&
+   !ieee80211_is_group_privacy_action(hdr))
tx->key = NULL;
else
skip_hw = (tx->key->conf.flags &
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mwifiex: Reduce endian conversion for REG Host Commands

[kbuild test robot]

Hi,

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Prasun-Maiti/mwifiex-Reduce-endian-conversion-for-REG-Host-Commands/20160621-224149
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All warnings (new ones prefixed by >>):

   drivers/net/wireless/marvell/mwifiex/sta_ioctl.c: In function 
'mwifiex_eeprom_read':
>> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:34: warning: 
>> comparison of distinct pointer types lacks a cast [enabled by default]
--
   drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c: In function 
'mwifiex_ret_reg_access':
>> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:821:6: warning: 
>> comparison of distinct pointer types lacks a cast [enabled by default]

vim +1339 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c

  1323   */
  1324  int
  1325  mwifiex_eeprom_read(struct mwifiex_private *priv, u16 offset, u16 bytes,
  1326  u8 *value)
  1327  {
  1328  int ret;
  1329  struct mwifiex_ds_read_eeprom rd_eeprom;
  1330  
  1331  rd_eeprom.offset =  offset;
  1332  rd_eeprom.byte_count = bytes;
  1333  
  1334  /* Send request to firmware */
  1335  ret = mwifiex_send_cmd(priv, HostCmd_CMD_802_11_EEPROM_ACCESS,
  1336 HostCmd_ACT_GEN_GET, 0, _eeprom, 
true);
  1337  
  1338  if (!ret)
> 1339  memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
  1340  rd_eeprom.byte_count));
  1341  return ret;
  1342  }
  1343  
  1344  /*
  1345   * This function sets a generic IE. In addition to generic IE, it can
  1346   * also handle WPA, WPA2 and WAPI IEs.
  1347   */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] mwifiex: Reduce endian conversion for REG Host Commands

[kbuild test robot]

Hi,

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Prasun-Maiti/mwifiex-Reduce-endian-conversion-for-REG-Host-Commands/20160621-224149
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   In file included from arch/sparc/include/asm/string.h:4:0,
from include/linux/string.h:18,
from include/linux/bitmap.h:8,
from include/linux/cpumask.h:11,
from include/linux/rcupdate.h:40,
from include/linux/sysctl.h:25,
from include/linux/timer.h:244,
from drivers/net/wireless/marvell/mwifiex/decl.h:27,
from drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:20:
   drivers/net/wireless/marvell/mwifiex/sta_ioctl.c: In function 
'mwifiex_eeprom_read':
   include/linux/kernel.h:742:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   arch/sparc/include/asm/string_64.h:25:48: note: in definition of macro 
'memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
   ^
>> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:34: note: in expansion 
>> of macro 'min'
  memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
 ^
--
   In file included from arch/sparc/include/asm/string.h:4:0,
from include/linux/string.h:18,
from include/linux/bitmap.h:8,
from include/linux/cpumask.h:11,
from include/linux/rcupdate.h:40,
from include/linux/sysctl.h:25,
from include/linux/timer.h:244,
from drivers/net/wireless/marvell/mwifiex/decl.h:27,
from drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:20:
   drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c: In function 
'mwifiex_ret_reg_access':
   include/linux/kernel.h:742:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   arch/sparc/include/asm/string_64.h:25:48: note: in definition of macro 
'memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
   ^
>> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:821:6: note: in expansion 
>> of macro 'min'
 min(MAX_EEPROM_DATA, eeprom->byte_count));
 ^

vim +/min +1339 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c

  1323   */
  1324  int
  1325  mwifiex_eeprom_read(struct mwifiex_private *priv, u16 offset, u16 bytes,
  1326  u8 *value)
  1327  {
  1328  int ret;
  1329  struct mwifiex_ds_read_eeprom rd_eeprom;
  1330  
  1331  rd_eeprom.offset =  offset;
  1332  rd_eeprom.byte_count = bytes;
  1333  
  1334  /* Send request to firmware */
  1335  ret = mwifiex_send_cmd(priv, HostCmd_CMD_802_11_EEPROM_ACCESS,
  1336 HostCmd_ACT_GEN_GET, 0, _eeprom, 
true);
  1337  
  1338  if (!ret)
> 1339  memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
  1340  rd_eeprom.byte_count));
  1341  return ret;
  1342  }
  1343  
  1344  /*
  1345   * This function sets a generic IE. In addition to generic IE, it can
  1346   * also handle WPA, WPA2 and WAPI IEs.
  1347   */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 1/2] ath10k: remove unused

[Sergei Shtylyov]

Hello.

On 6/21/2016 2:45 PM, Chaehyun Lim wrote:


 is not used anymore, so just remove it.


   s/it/#include/?


Signed-off-by: Chaehyun Lim 

[...]


diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
b/drivers/net/wireless/ath/ath10k/htc.h
index cc82718..0c55cd9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 struct ath10k;


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station ioctl file

[Javier Martinez Canillas]

Hello Kalle,

On 06/10/2016 03:54 PM, Kalle Valo wrote:
> Javier Martinez Canillas  writes:
> 
>>> This patch (2/3) is only for code rearrangement and adds an
>>> unnecessary wrapper function. We can simply drop the patch.
>>
>> Agreed.
>>
>> Kalle,
>>
>> Patch 3/3 applies cleanly even after dropping patch 2/3.
>> Is that Ok for you or do you want me to re-resend a v3
>> with only patches 1/3 and 3/3?
> 
> I can drop patch 2, no need to resend. Thanks.
> 

I saw that you sent your pull request for v4.8 but the
patches from this series were not included:

https://lkml.org/lkml/2016/6/21/400

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mwifiex: Reduce endian conversion for REG Host Commands

[Prasun Maiti]

For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are
saved to driver. So, "leX_to_cpu" conversion is required too many
times afterwards in driver.

This patch reduces the endian: conversion without saving "cpu_to_leX"
converted values in driver. This will convert endianness in prepare
command and command response path.

Signed-off-by: Prasun Maiti 
---
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 -
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 35 +++---
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++---
 3 files changed, 40 insertions(+), 44 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index e436574..9df02ba 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct 
host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
mac_reg = >params.mac_reg;
mac_reg->action = cpu_to_le16(cmd_action);
-   mac_reg->offset =
-   cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
-   mac_reg->value = reg_rw->value;
+   mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+   mac_reg->value = cpu_to_le32(reg_rw->value);
break;
}
case HostCmd_CMD_BBP_REG_ACCESS:
@@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct 
host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
bbp_reg = >params.bbp_reg;
bbp_reg->action = cpu_to_le16(cmd_action);
-   bbp_reg->offset =
-   cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
-   bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
+   bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+   bbp_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_RF_REG_ACCESS:
@@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct 
host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
rf_reg = >params.rf_reg;
rf_reg->action = cpu_to_le16(cmd_action);
-   rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
-   rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
+   rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+   rf_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_PMIC_REG_ACCESS:
@@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct 
host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
pmic_reg = >params.pmic_reg;
pmic_reg->action = cpu_to_le16(cmd_action);
-   pmic_reg->offset =
-   cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
-   pmic_reg->value = (u8) le32_to_cpu(reg_rw->value);
+   pmic_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+   pmic_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_CAU_REG_ACCESS:
@@ -1177,9 +1174,8 @@ static int mwifiex_cmd_reg_access(struct 
host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*cau_reg) + S_DS_GEN);
cau_reg = >params.rf_reg;
cau_reg->action = cpu_to_le16(cmd_action);
-   cau_reg->offset =
-   cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
-   cau_reg->value = (u8) le32_to_cpu(reg_rw->value);
+   cau_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+   cau_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_802_11_EEPROM_ACCESS:
@@ -1190,8 +1186,8 @@ static int mwifiex_cmd_reg_access(struct 
host_cmd_ds_command *cmd,

cmd->size = cpu_to_le16(sizeof(*cmd_eeprom) + S_DS_GEN);
cmd_eeprom->action = cpu_to_le16(cmd_action);
-   cmd_eeprom->offset = rd_eeprom->offset;
-   cmd_eeprom->byte_count = rd_eeprom->byte_count;
+   cmd_eeprom->offset = cpu_to_le16(rd_eeprom->offset);
+   cmd_eeprom->byte_count = cpu_to_le16(rd_eeprom->byte_count);
cmd_eeprom->value = 0;
break;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index d18c797..d7a9c79 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -781,44 +781,43 @@ static int 

Re: [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter.

[Dave Taht]

On Tue, Jun 21, 2016 at 2:41 AM, Jouni Malinen  wrote:
> On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote:
>> I've only done this work as I hate to see people's efforts go to
>> waste and I feel that there's enough roadblocks in the way of
>> actually using this functionality that casual idiots won't be able
>> to.
>
> Are these really ready to go to the upstream kernel in this state and
> without the other changes that would be needed to operate correctly?
> What is the use case for these and how have these been tested?

So far as I know the use case for these is to make it possible to build
open source wifi systems that enable emergency services. This
strikes me as a worthy goal.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter.

[Ben Greear]

On 06/21/2016 02:41 AM, Jouni Malinen wrote:

On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote:

I've only done this work as I hate to see people's efforts go to
waste and I feel that there's enough roadblocks in the way of
actually using this functionality that casual idiots won't be able
to.


Are these really ready to go to the upstream kernel in this state and
without the other changes that would be needed to operate correctly?
What is the use case for these and how have these been tested?


More patches are needed to make this work properly.  My full patchset, with
modifications to supplicant, *has* been tested, including against a Cisco
AP running 5Mhz channels.



This is compile tested only as I cannot test this for real as I lack
both the hardware and license required.


I don't think this is sufficient when touching this type of area. I
would not apply these without proper testing and full set of
functionality being available. I see no point in ath9k defining
additional channels if all those new channels can cause is harm and not
correct functionality. This channel list addition looks like the easiest
part to handle compared to the other patches needed for 4.9 GHz and this
would be the last patch on my list to get accepted..



diff --git a/drivers/net/wireless/ath/ath9k/common-init.c 
b/drivers/net/wireless/ath/ath9k/common-init.c
+#ifdef ATH9K_49_GHZ_CHAN
+   /* 4.9Ghz channels, public safety channels, license is required in US
+* and most other regulatory domains!
+*/
+   CHAN5G(4915, 38), /* Channel 183 */
+   CHAN5G(4920, 39), /* Channel 184 */
+   CHAN5G(4925, 40), /* Channel 185 */
+   CHAN5G(4935, 41), /* Channel 187 */
+   CHAN5G(4940, 42), /* Channel 188 */
+   CHAN5G(4945, 43), /* Channel 189 */
+   CHAN5G(4960, 44), /* Channel 192 */
+   CHAN5G(4970, 45), /* Channel 194 */
+   CHAN5G(4980, 46), /* Channel 196 */


Where are these channels defined and are these really correct
frequencies for them? Please note that many of the 4.9 GHz channels have
channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e.,
fractional MHz.. While US public safety may not have all those cases,
even there are some 0.5 MHz cases. In addition, those channel numbers
sound more like some of the channels defined in Japan rather than US
public safety operating class. In addition, some of these channels seem
to be outside the US public safety range.


I got these from WiKi pedia.  There is a later patch that adds the 5Mhz
channels that Cisco uses.  I figured that since this is all restricted anyway,
that users of it would know how to make it work (and they would have to hack
regdb in order to use any of them anyway).


Is this trying to add 4.9 GHz channels in general for multiple different
use cases? And if so, what are those use cases? Or is this only for some
public safety cases? And if so, for which regulatory domains?

To be frank, I really don't see how this would be even close to a state
that should be accepted into the upstream tree.


It was a starting point, and posted mainly to let folks know how to get started.

As I said, I don't have interest in trying to push all the changes upstream,
but they are in my kernel tree on dmz2.candelatech.com and hostap tree on
github, so maybe someone who has interest in dealing with upstreaming them
can take them over.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Ben Greear]

On 06/21/2016 02:40 AM, Johannes Berg wrote:

On Fri, 2016-06-10 at 11:43 -0700, Ben Greear wrote:

On 03/15/2016 01:20 PM, Johannes Berg wrote:

On Tue, 2016-03-15 at 09:10 -0700, Ben Greear wrote:


The logic I wrote is basically exactly this.  It uses the
configured
rates to specify which of the hardware's rates are allowed and
disabled.



I understand that. I just take issue with the fact that we have to
sprinkle "magic pixie dust" (in form of the override function
calls)
everywhere throughout the code.

johannes



So, I never could think up a way to make this more acceptable and
meet my own goals.

Any chance I could get just the netlink enum in place, even if it is
called something like 'api_placeholder_x'?



No, I don't think I want to do that.

But if you're not too worried about space consumption, you could pick a
higher number:

/* add attributes here, update the policy in nl80211.c */

NL80211_ATTR_TX_ADVERT_RATEMASK = 300,

__NL80211_ATTR_AFTER_LAST,

We currently use about 230 attributes, so that'll give you lots of
breathing room.


From a pure hack point of view, maybe re-purposing some already existing
attribute that has nothing to do with scanning is the way to go.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug with: ath10k: enable parsing per station rx duration for 10.4?

[Ben Greear]

On 06/20/2016 10:18 PM, Mohammed Shafi Shajakhan wrote:

Hi Ben,

thanks for reporting ...

On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote:

I'm working on bringing up my hacked up version of 4.7 ath10k and 10.4 
firmware, and I think
I may have found a regression.


[shafi] let me know what is the issue.. some steps to recreate the issue.


ethtool -S wlan0
or similar should reproduce it.

You would see stats timeout messages in dmesg, and with a bit more debugging,
you notice that the driver is basically busy-spinning trying to get stats over
WMI and/or it is giving errors because skb pull fails because there actually is
not extd stats struct.



My 10.4.3-ish firmware source has a bunch of:

if (stats_id == WMI_REQUEST_PEER_STAT)
logic in it.  In other words, it is not using that id as a bitfield.


[shafi] will check this.


I fixed my firmware to treat it as a bitfield, and to specifically un-set the 
EXTD stats
bit, and now it works with my 4.7.  Firmware fix should be backwards compatible.



Now, I can fix the firmware, but I am guessing that at least some stock
10.4 firmware has this same issue, and of course any older firmware
that does not have this change will still be broken.

So, do you want to back out this patch below, at least the part where it sends
in 0x9 as the stats_id?


[shafi] request if you can check this please, there was some misunderstanding
in the design when this feature got enabled in 10.4, we fixed it in
https://patchwork.kernel.org/patch/9149357/


That might have fixed it, but it is not in 4.7, so I didn't have it
in my tree when testing yesterday.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Johannes Berg]

Very brief review:

> +/* */

That seems slightly odd.

> + /* bus private data */
> + char bus_priv[0];

You might want to - for future proofing - add some aligned() attribute.
Otherwise, if struct mutex doesn't have a size that's a multiple of the
pointer size, fields in here will not be aligned right.

> +static inline void *get_bus_priv(struct qtnf_bus *bus)
> +{
> + if (WARN_ON(!bus)) {
> + pr_err("qtnfmac: invalid bus pointer!\n");
> + return NULL;

Better to just use "WARN(!bus, "qtnfmac: invalid bus pointer!\n");"

Also, for pr_* the "qtnfmac: " prefix should be done with pr_fmt, not
manually.

> +#define QLINK_HT_MCS_MASK_LEN10
> +#define QLINK_ETH_ALEN   6
> +#define QLINK_MAX_SSID_LEN   32

These seem a bit strange? Why bother? They are standard values.
(not entirely sure what the MCS_MASK_LEN is used for though)

> +/*
> + * struct qlink_ht_mcs_info - MCS information
> + *
> + * See  ieee80211_mcs_info.
> + */
> +struct qlink_ht_mcs_info {
> + u8 rx_mask[QLINK_HT_MCS_MASK_LEN];
> + __le16 rx_highest;
> + u8 tx_params;
> + u8 reserved[3];
> +} __packed;
> +
> +/*
> + * struct qlink_ht_cap - HT capabilities
> + *
> + * "HT capabilities element", see  ieee80211_ht_cap.
> + */
> +struct qlink_ht_cap {
> + struct qlink_ht_mcs_info mcs;
> + __le32 tx_BF_cap_info;
> + __le16 cap_info;
> + __le16 extended_ht_cap_info;
> + u8 ampdu_params_info;
> + u8 antenna_selection_info;
> +} __packed;
> +
> +/*
> + * struct qlink_vht_mcs_info - VHT MCS information
> + *
> + * See  ieee80211_vht_mcs_info.
> + */
> +struct qlink_vht_mcs_info {
> + __le16 rx_mcs_map;
> + __le16 rx_highest;
> + __le16 tx_mcs_map;
> + __le16 tx_highest;
> +} __packed;
> +
> +/*
> + * struct qlink_vht_cap - VHT capabilities
> + *
> + * "VHT capabilities element", see  ieee80211_vht_cap.
> + */
> +struct qlink_vht_cap {
> + __le32 vht_cap_info;
> + struct qlink_vht_mcs_info supp_mcs;
> +} __packed;


I think you shouldn't duplicate these, there's no sane way they can
ever be changed in ieee80211.h


> +enum qlink_iface_type {
> + QLINK_IFTYPE_AP = BIT(0),
> + QLINK_IFTYPE_STATION= BIT(1),
> + QLINK_IFTYPE_ADHOC  = BIT(2),
> + QLINK_IFTYPE_MONITOR= BIT(3),
> + QLINK_IFTYPE_WDS= BIT(4),
> +};

Not sure how you use these, but BIT() doesn't make a lot of sense for
something that's mutually exclusive?

> +/**
> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + **/

You should probably not have those double asterisks since they're
reserved for kernel-doc.

> + if (qtnf_cmd_send_start_ap(vif)) {
> + pr_err("failed to issue start AP command\n");
> + return -EFAULT;
> + }
> +
> + if (!(vif->bss_status & QTNF_STATE_AP_START)) {
> + pr_err("failed to start AP operations in FW\n");
> + return -EFAULT;
> + }

This is strange - I'd expect send_start_ap() to not actually just send
it, but also wait for a response, and then it can return an error if
the flag didn't get set. If it doesn't, then it's racy, no?

> +static int
> +qtnf_connect(struct wiphy *wiphy, struct net_device *dev,
> +  struct cfg80211_connect_params *sme)
> +{
> + struct qtnf_vif *vif;
> + struct qtnf_bss_config *bss_cfg;
> +
> + vif = qtnf_netdev_get_priv(dev);
> + if (!vif) {
> + pr_err("core_attach: could not get valid vif
> pointer\n");
> + return -EFAULT;
> + }

It seems that you're overdoing the error checks a bit - I don't see how
this could possibly fail?

> + memcpy(_cfg->crypto, >crypto, sizeof(bss_cfg-
> >crypto));

This makes no sense at all - you have to convert the format of this
somehow to make it work - at least endianness has to be fixed, even if
you copied all of the cfg80211 struct.

[snip - lots of stuff I didn't really look at]

> +/* sysfs knobs: stats and other diagnistics */

I think you should not have these - maybe add those with separate
patches later that really can't be done otherwise, and then give very
good rationale for it. Having driver-specific sysfs is not a good idea
in general.

> +static inline u64 qtnf_get_unaligned_le64(const __le64 *ptr)
> +{
> + return le64_to_cpu(get_unaligned(ptr));
> +}
> +
> +static inline u32 qtnf_get_unaligned_le32(const __le32 *ptr)
> +{
> + return 

RE: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

[Machani, Yaniv]

Yes,
TI driver have added support in our latest release (TI git).
http://software-dl.ti.com/ecs/WiLink8/R8_7/exports/release_notes_R8_7.html

Patches will be shared with mainline in the near future.

Thanks,
Yaniv Machani

-Original Message-
From: Bob Copeland [mailto:m...@bobcopeland.com] 
Sent: Tuesday, June 21, 2016 15:19
To: Altshul, Maxim
Cc: johan...@sipsolutions.net; kv...@codeaurora.org; el...@wizery.com; Machani, 
Yaniv; Mishol, Guy; a...@wizery.com; linux-wireless@vger.kernel.org; 
net...@vger.kernel.org; da...@davemloft.net
Subject: Re: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

On Mon, Jun 20, 2016 at 04:00:19PM +0300, Maxim Altshul wrote:
> 2. Implements the opcode and the mechanism that reports the rates in 
> TI driver.

Does this mean TI driver will support mesh at some point?

--
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

[Bob Copeland]

On Mon, Jun 20, 2016 at 04:00:19PM +0300, Maxim Altshul wrote:
> 2. Implements the opcode and the mechanism that reports the rates
> in TI driver.

Does this mean TI driver will support mesh at some point?

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iw: support and enable separate build dir

[Maxin B. John]

Hi,

On Tue, Jun 21, 2016 at 12:41 PM, Johannes Berg
 wrote:
> On Fri, 2016-06-10 at 13:58 +0300, Maxin B. John wrote:
>> Hi Johannes,
>>
>> On Thu, Jun 9, 2016 at 11:25 AM, Johannes Berg
>>  wrote:
>> > On Wed, 2016-06-01 at 11:40 +0300, maxin.j...@gmail.com wrote:
>> > > From: "Maxin B. John" 
>> > >
>> > > Support separation of SRCDIR and OBJDIR
>> > >
>> > Doesn't seem to work:
>> >
>> > $ mkdir /tmp/obj
>> > $ make clean
>> > $ make OBJDIR=/tmp/obj
>> > [...]
>> >  GEN  version.c
>> >  CC   version.o
>> > cc: error: version.c: No such file or directory
>> > cc: fatal error: no input files
>> > compilation terminated.
>> > Makefile:104: recipe for target 'version.o' failed
>> > make: *** [version.o] Error 1
>> > $ ls *.o
>> > event.o  genl.o  ibss.o  info.o  interface.o  iw.o  mesh.o  mpath.o
>> > mpp.o  ocb.o  phy.o  reg.o  scan.o  station.o  survey.o  util.o
>> >
>> > (object files are in the wrong place too)
>>
>> I was following the below listed steps to verify this patch:
>>
>> # mkdir build
>> # cd build
>> #  make -f /iw/Makefile
>>
>
> Oh. Any chance you could make both work, since the "make O=..." is
> something kernel people are used to/familiar with?

I will look into that. Thanks for the suggestion !

> johannes

Best Regards,
Maxin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath6kl: replace semaphore with mutex

[kbuild test robot]

Hi,

[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chaehyun-Lim/ath10k-remove-unused-linux-semaphore-h/20160621-195511
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/ath/ath6kl/debug.c: In function 
'ath6kl_roam_table_read':
>> drivers/net/wireless/ath/ath6kl/debug.c:1177:19: error: 'struct ath6kl' has 
>> no member named 'sem'
  mutex_unlock(>sem);
  ^

vim +1177 drivers/net/wireless/ath/ath6kl/debug.c

  1171  return -EBUSY;
  1172  
  1173  set_bit(ROAM_TBL_PEND, >flag);
  1174  
  1175  ret = ath6kl_wmi_get_roam_tbl_cmd(ar->wmi);
  1176  if (ret) {
> 1177  mutex_unlock(>sem);
  1178  return ret;
  1179  }
  1180  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCHv3] wlcore: spi: add wl18xx support

[Reizer, Eyal]

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage and puts the wilink chip into wspi mode.

Signed-off-by: Eyal Reizer 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle, which achieves the same hardware purpose.
update device tree bindings docucmentation accordingly

 .../bindings/net/wireless/ti,wlcore,spi.txt|  47 ++--
 drivers/net/wireless/ti/wlcore/spi.c   | 124 +
 2 files changed, 145 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..35467cf 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
 
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.
 
 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
 
 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL
 
 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,10 +32,15 @@ Optional properties:
 
 Examples:
 
+For wl12xx family:
  {
-   wl1271@1 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
clock-xtal;
@@ -34,3 +50,20 @@ Examples:
vwlan-supply = <_fixed>;
};
 };
+
+For wl18xx family:
+  {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   vwlan-supply = <_en_reg>;
+   spi-max-frequency = <4800>;
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   };
+};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 020ac1a..bd1253d 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092
 
 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
 
 /* Maximum number of SPI write chunks */
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+   struct spi_device *spi = to_spi_device(glue->dev);
u8 

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

[Andrew F. Davis]

On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:
> Hi Andrew,
> 
> This patch doesn't apply, please rebase onto recent LED tree.
> 
> On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
>> Some systems use 'gpio_led_register_device' to make an in-memory copy of
>> their LED device table so the original can be removed as .init.rodata.
>> When the LED subsystem is not enabled source in the led directory is not
>> built and so this function may be undefined. Fix this here.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>   include/linux/leds.h | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/include/linux/leds.h b/include/linux/leds.h
>> index d2b1306..a4a3da6 100644
>> --- a/include/linux/leds.h
>> +++ b/include/linux/leds.h
>> @@ -386,8 +386,16 @@ struct gpio_led_platform_data {
>>  unsigned long *delay_off);
> 
> Currently there is some stuff here, and in fact it has been for
> a long time.
> 
> Patch "[PATCH 12/12] leds: Only descend into leds directory when
> CONFIG_NEW_LEDS is set" also doesn't apply.
> What repository are you using?
> 

v4.7-rc4, it may not apply due to the surrounding lines being changed in
the other patches which may not be applied to your tree. It is a single
line change per patch so hopefully the merge conflict resolutions will
be trivial.

A better solution could have been getting an ack from each maintainer
and having someone pull the whole series into one tree, but parts have
already been picked so it may be a little late for that.

>>   };
>>
>> +#ifdef CONFIG_NEW_LEDS
>>   struct platform_device *gpio_led_register_device(
>>  int id, const struct gpio_led_platform_data *pdata);
>> +#else
>> +static inline struct platform_device *gpio_led_register_device(
>> +   int id, const struct gpio_led_platform_data *pdata)
>> +{
>> +   return 0;
>> +}
>> +#endif
>>
>>   enum cpu_led_event {
>>  CPU_LED_IDLE_START, /* CPU enters idle */
>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ath10k: remove unused

[Chaehyun Lim]

 is not used anymore, so just remove it.

Signed-off-by: Chaehyun Lim 
---
 drivers/net/wireless/ath/ath10k/htc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
b/drivers/net/wireless/ath/ath10k/htc.h
index cc82718..0c55cd9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 struct ath10k;
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ath6kl: replace semaphore with mutex

[Chaehyun Lim]

It replaces struct semaphore sem with struct mutex mutex

Signed-off-by: Chaehyun Lim 
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c | 30 +++---
 drivers/net/wireless/ath/ath6kl/core.c |  2 +-
 drivers/net/wireless/ath/ath6kl/core.h |  2 +-
 drivers/net/wireless/ath/ath6kl/debug.c| 12 ++--
 drivers/net/wireless/ath/ath6kl/init.c |  6 +++---
 5 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f6b5390..d4eb066 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -480,14 +480,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
return -EINVAL;
}
 
-   if (down_interruptible(>sem)) {
+   if (mutex_lock_interruptible(>mutex)) {
ath6kl_err("busy, couldn't get access\n");
return -ERESTARTSYS;
}
 
if (test_bit(DESTROY_IN_PROGRESS, >flag)) {
ath6kl_err("busy, destroy in progress\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EBUSY;
}
 
@@ -500,14 +500,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
 WMI_TIMEOUT);
if (signal_pending(current)) {
ath6kl_err("cmd queue drain timeout\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EINTR;
}
}
 
status = ath6kl_set_assoc_req_ies(vif, sme->ie, sme->ie_len);
if (status) {
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
 
@@ -522,7 +522,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
  vif->req_bssid,
  vif->ch_hint);
 
-   up(>sem);
+   mutex_unlock(>mutex);
if (status) {
ath6kl_err("wmi_reconnect_cmd failed\n");
return -EIO;
@@ -548,7 +548,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
 
status = ath6kl_set_auth_type(vif, sme->auth_type);
if (status) {
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
 
@@ -570,7 +570,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
if (sme->key_idx > WMI_MAX_KEY_INDEX) {
ath6kl_err("key index %d out of bounds\n",
   sme->key_idx);
-   up(>sem);
+   mutex_unlock(>mutex);
return -ENOENT;
}
 
@@ -594,7 +594,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
if (ath6kl_wmi_bssfilter_cmd(ar->wmi, vif->fw_vif_idx,
 ALL_BSS_FILTER, 0) != 0) {
ath6kl_err("couldn't set bss filtering\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EIO;
}
}
@@ -626,7 +626,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
   0);
if (status) {
ath6kl_err("couldn't set listen intervel\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
}
@@ -651,7 +651,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
ath6kl_wmi_scanparams_cmd(ar->wmi, vif->fw_vif_idx, 0, 0,
  sme->bg_scan_period, 0, 0, 0, 3, 0, 0, 0);
 
-   up(>sem);
+   mutex_unlock(>mutex);
 
if (status == -EINVAL) {
memset(vif->ssid, 0, sizeof(vif->ssid));
@@ -832,7 +832,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
return -EBUSY;
}
 
-   if (down_interruptible(>sem)) {
+   if (mutex_lock_interruptible(>mutex)) {
ath6kl_err("busy, couldn't get access\n");
return -ERESTARTSYS;
}
@@ -845,7 +845,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
if (!test_bit(SKIP_SCAN, >flag))
memset(vif->req_bssid, 0, sizeof(vif->req_bssid));
 
-   up(>sem);
+   mutex_unlock(>mutex);
 
vif->sme_state = SME_DISCONNECTED;
 
@@ -1775,7 +1775,7 @@ static int ath6kl_get_station(struct wiphy *wiphy, struct 
net_device *dev,
if (memcmp(mac, 

Re: NL80211_ATTR_PAD question

[Johannes Berg]

On Mon, 2016-06-13 at 21:25 +0200, Arend van Spriel wrote:
> 
> On 10-06-16 23:08, Johannes Berg wrote:
> > On Fri, 2016-06-10 at 12:47 -0700, Ben Greear wrote:
> > > I see this was added sometime recently:  NL80211_ATTR_PAD
> > > 
> > > If another enum member is added, should it replace the PAD enum?
> > 
> > No.
> > 
> > > At the least, I think we need some comments about how this is to
> > > be
> > > dealt with.
> > > 
> > 
> > You simply ignore it :)
> 
> So do you know why the caller of nla_put_u64_64bit() would need to
> specify the padattr. I mean, why is this not an generic attribute
> that
> netlink deals with internally. It has probably been discussed on the
> netdev list but I could not find the right thread.
> 

Netlink attribute numbers are always specific to the (generic) netlink
family used. There was a discussion about using the attribute number 0
since that's reserved, but unfortunately it's only reserved in *most*
families, some actually use it (despite that being broken with libnl.)

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Johannes Berg]

On Fri, 2016-06-10 at 11:43 -0700, Ben Greear wrote:
> On 03/15/2016 01:20 PM, Johannes Berg wrote:
> > On Tue, 2016-03-15 at 09:10 -0700, Ben Greear wrote:
> > > 
> > > The logic I wrote is basically exactly this.  It uses the
> > > configured
> > > rates to specify which of the hardware's rates are allowed and
> > > disabled.
> > > 
> > 
> > I understand that. I just take issue with the fact that we have to
> > sprinkle "magic pixie dust" (in form of the override function
> > calls)
> > everywhere throughout the code.
> > 
> > johannes
> > 
> 
> So, I never could think up a way to make this more acceptable and
> meet my own goals.
> 
> Any chance I could get just the netlink enum in place, even if it is
> called something like 'api_placeholder_x'?
> 

No, I don't think I want to do that.

But if you're not too worried about space consumption, you could pick a
higher number:

/* add attributes here, update the policy in nl80211.c */

NL80211_ATTR_TX_ADVERT_RATEMASK = 300,

__NL80211_ATTR_AFTER_LAST,

We currently use about 230 attributes, so that'll give you lots of
breathing room.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iw: support and enable separate build dir

[Johannes Berg]

On Fri, 2016-06-10 at 13:58 +0300, Maxin B. John wrote:
> Hi Johannes,
> 
> On Thu, Jun 9, 2016 at 11:25 AM, Johannes Berg
>  wrote:
> > On Wed, 2016-06-01 at 11:40 +0300, maxin.j...@gmail.com wrote:
> > > From: "Maxin B. John" 
> > > 
> > > Support separation of SRCDIR and OBJDIR
> > > 
> > Doesn't seem to work:
> > 
> > $ mkdir /tmp/obj
> > $ make clean
> > $ make OBJDIR=/tmp/obj
> > [...]
> >  GEN  version.c
> >  CC   version.o
> > cc: error: version.c: No such file or directory
> > cc: fatal error: no input files
> > compilation terminated.
> > Makefile:104: recipe for target 'version.o' failed
> > make: *** [version.o] Error 1
> > $ ls *.o
> > event.o  genl.o  ibss.o  info.o  interface.o  iw.o  mesh.o  mpath.o
> > mpp.o  ocb.o  phy.o  reg.o  scan.o  station.o  survey.o  util.o
> > 
> > (object files are in the wrong place too)
> 
> I was following the below listed steps to verify this patch:
> 
> # mkdir build
> # cd build
> #  make -f /iw/Makefile
> 

Oh. Any chance you could make both work, since the "make O=..." is
something kernel people are used to/familiar with?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull-request: wireless-drivers-next 2016-06-21

[Kalle Valo]

Hi Dave,

I hope it's ok to send two pull requests the same day, both for net and
net-next? This is targeted to 4.8 so it is for net-next.

Even though is this the first pull request for 4.8 we actually remove
more code than add, thanks to Guenter Roeck's on removing unused "phy_a"
support from b43. Otherwise there's not really anything standing out,
adding new chipset support to brcmfmac and ath10k, lots of fixes and the
usual.

Please let me know if there any issues.

Kalle

The following changes since commit 76f21b99004ef1f16be6184678f660eab911b8b8:

  net: Add docbook description for 'mtu' arg to skb_gso_validate_mtu() 
(2016-06-03 22:56:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2016-06-21

for you to fetch changes up to 1bb57c8a5e33bcbec031ce0c629968922d5af89d:

  Merge ath-next from ath.git (2016-06-19 11:19:30 +0300)



wireless-drivers patches for 4.8

Major changes:

ath10k

* enable btcoex support without restarting firmware
* enable ipq4019 support using AHB bus
* add QCA9887 chipset support
* retrieve calibration data from EEPROM, currently only for QCA9887

wil6210

* add pm_notify handling

brcmfmac

* add support for the PCIE devices 43525 and 43465


Adrian Chadd (1):
  b43: don't unconditionally fall back to CCK if the rate is 6MB OFDM.

Amitkumar Karwar (1):
  mwifiex: inform disconnection initiator correctly.

Arend van Spriel (1):
  brcm80211: update maintainers email addresses

Arnd Bergmann (4):
  iwlegacy: avoid warning about missing braces
  wl3501_cs: avoid bogus gcc-6 warning
  rtlwifi: fix error handling in *_read_adapter_info()
  mwifiex: fix link error against sdio

Ashok Raj Nagarajan (1):
  ath10k: fix diag_read to collect data for larger memory

Bhaktipriya Shridhar (1):
  libertas: Remove create_workqueue

Bob Copeland (1):
  ath5k: fix misplaced default label in sifs switch

Christian Daudt (2):
  brcmfmac: Fix kernel oops in failed chip_attach
  brcmfmac: Fix 'did not remove int handler' warning

Eduardo Abinader (3):
  ath9k: Remove empty test condition
  ath9k: allow tx99 for ar9002 based cards
  ath9k: Proper TX99 interrupt ref count

Guenter Roeck (3):
  libertas_tf: Drop unused variable and define
  b43: Remove unused phy_a code
  b43: Completely remove support for phy_a

Hante Meuleman (2):
  brcmfmac: fix skb priority handling
  brcmfmac: add support for the PCIE devices 43525 and 43465

Heinrich Schuchardt (7):
  ath6kl: simplify logical condition
  rsi: eliminate superfluous NULL check
  mwifiex: illegal assignment
  rtlwifi: rtl8723be: avoid undefined behavior
  mwiflex: avoid possible null pointer dereference
  rtlwifi: rtl8192ee: simplify coding
  brcm80211: simplify assignment

Javier Martinez Canillas (8):
  mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node
  mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()
  mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()
  mwifiex: consolidate mwifiex_sdio_probe() error paths
  mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()
  mwifiex: check if mwifiex_sdio_probe_of() fails and return error
  mwifiex: don't print an error if an optional DT property is missing
  mwifiex: use better message and error code when OF node doesn't match

Julia Lawall (2):
  ath6kl: fix typo
  mwifiex: fix typo

Kalle Valo (1):
  Merge ath-next from ath.git

Lauri Kasanen (1):
  carl9170: Clarify kconfig text

Lior David (1):
  wil6210: abort P2P search when stopping P2P device

Lucas Stach (1):
  b43: only hardcode LED behavior if SPROM doesn't encode any

Mathias Krause (1):
  mwifiex: remove misleading GFP_DMA flag in buffer allocations

Maya Erez (7):
  wil6210: fix race conditions between TX send and completion
  wil6210: guarantee safe access to rx descriptors shared memory
  wil6210: protect wil_vring_fini_tx in parallel to tx completions
  wil6210: fix dma mapping error cleanup in __wil_tx_vring_tso
  wil6210: add pm_notify handling
  wil6210: align wil log functions to wil_dbg_ratelimited implementation
  wil6210: fix chan check in wil_p2p_listen

Michal Kazior (1):
  ath10k: improve tx scheduling

Mohammed Shafi Shajakhan (5):
  ath10k: reduce warning messages during rx without proper channel context
  ath10k: fix legacy rate packet debug messages
  ath10k: fix error while writing 'simulate_fw_crash' debugfs
  ath10k: remove duplicate and unused rx rate flags
  ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

Muhammad Falak R Wani (1):
  brcmfmac: use kmemdup

Rafał Miłecki 

Re: [Query] mwifiex: few observations to reduce number of endian conversions

[Prasun Maiti]

Hi Amitkumar,


On Tue, Jun 21, 2016 at 3:47 PM, Amitkumar Karwar  wrote:

> I agree with your observations. We'll prepare a cleanup patch to address this.
>
> Regards,
> Amitkumar

I have already made some changes. I will send you a patch for this.

-- 
Thanks,
Prasun
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull-request: wireless-drivers 2016-06-21

[Kalle Valo]

Hi Dave,

here is a pull request for 4.7, really small fixes this time, some of
them fix important regressions. Please let me know if there are any
problems.

Kalle

The following changes since commit 182fd9eecb287e696c82b30d06c6150d80a49c5b:

  MAINTAINERS: Add file patterns for wireless device tree bindings (2016-06-04 
17:24:02 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2016-06-21

for you to fetch changes up to 034fdd4a17ff089c2428ece18efa65c5396810d2:

  Merge ath-current from ath.git (2016-06-16 17:55:19 +0300)



wireless-drivers fixes for 4.7

iwlwifi

* fix the scan timeout for long scans
* fix an RCU splat caused when updating the TKIP key
* fix a potential NULL-derefence introduced recently
* fix a IGTK key bug that has existed since the MVM driver was introduced
* fix some fw capabilities checks that got accidentally inverted

rtl8xxxu

* fix typo on variable name

ath10k

* fix deadlock when peer cannot be created
* fix crash related to printing features
* fix deadlock while processing rx_in_ord_ind

ath9k

* fix GPIO mask regression for AR9462 and AR9565


Ayala Beker (1):
  iwlwifi: mvm: set the encryption type of an IGTK key

Ben Greear (2):
  ath10k: fix deadlock when peer cannot be created
  ath10k: fix crash related to printing features

Colin Ian King (1):
  rtl8xxxu: fix typo on variable name, compare against correct variable

Emmanuel Grumbach (1):
  iwlwifi: mvm: fix RCU splat in TKIP's update_key

Johannes Berg (1):
  iwlwifi: mvm: fix a few firmware capability checks

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2016-06-10' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge ath-current from ath.git

Luca Coelho (2):
  iwlwifi: mvm: increase scan timeout to 20 seconds
  iwlwifi: mvm: fix potential NULL-dereference in iwl_mvm_reorder()

Miaoqing Pan (1):
  ath9k: fix GPIO mask for AR9462 and AR9565

Rajkumar Manoharan (1):
  ath10k: fix deadlock while processing rx_in_ord_ind

 drivers/net/wireless/ath/ath10k/core.c |2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c   |1 -
 drivers/net/wireless/ath/ath10k/mac.c  |2 +-
 drivers/net/wireless/ath/ath9k/reg.h   |8 
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |8 
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  |4 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c  |2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |   16 +++-
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c |2 +-
 9 files changed, 30 insertions(+), 15 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter.

[Julian Calaby]

Hi Jouni,

On Tue, Jun 21, 2016 at 7:41 PM, Jouni Malinen  wrote:
> On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote:
>> I've only done this work as I hate to see people's efforts go to
>> waste and I feel that there's enough roadblocks in the way of
>> actually using this functionality that casual idiots won't be able
>> to.
>
> Are these really ready to go to the upstream kernel in this state and
> without the other changes that would be needed to operate correctly?
> What is the use case for these and how have these been tested?

This patch is a edited version (adding the Kconfig option) of Ben's
patch. I picked it up as he seemed to have given up on it and I could
see nothing directly wrong with the patch.

>> This is compile tested only as I cannot test this for real as I lack
>> both the hardware and license required.
>
> I don't think this is sufficient when touching this type of area. I
> would not apply these without proper testing and full set of
> functionality being available. I see no point in ath9k defining
> additional channels if all those new channels can cause is harm and not
> correct functionality. This channel list addition looks like the easiest
> part to handle compared to the other patches needed for 4.9 GHz and this
> would be the last patch on my list to get accepted..

It isn't, Ben himself has said that fractional MHz need to be
supported for this to be 100% correct, however I believe that defining
the channels is minimally sufficient for his purposes. I do know he's
done more work than this, however I can't pick that up as getting it
ready for upstream requires testing I can't do.

>> diff --git a/drivers/net/wireless/ath/ath9k/common-init.c 
>> b/drivers/net/wireless/ath/ath9k/common-init.c
>> +#ifdef ATH9K_49_GHZ_CHAN
>> + /* 4.9Ghz channels, public safety channels, license is required in US
>> +  * and most other regulatory domains!
>> +  */
>> + CHAN5G(4915, 38), /* Channel 183 */
>> + CHAN5G(4920, 39), /* Channel 184 */
>> + CHAN5G(4925, 40), /* Channel 185 */
>> + CHAN5G(4935, 41), /* Channel 187 */
>> + CHAN5G(4940, 42), /* Channel 188 */
>> + CHAN5G(4945, 43), /* Channel 189 */
>> + CHAN5G(4960, 44), /* Channel 192 */
>> + CHAN5G(4970, 45), /* Channel 194 */
>> + CHAN5G(4980, 46), /* Channel 196 */
>
> Where are these channels defined and are these really correct
> frequencies for them? Please note that many of the 4.9 GHz channels have
> channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e.,
> fractional MHz.. While US public safety may not have all those cases,
> even there are some 0.5 MHz cases. In addition, those channel numbers
> sound more like some of the channels defined in Japan rather than US
> public safety operating class. In addition, some of these channels seem
> to be outside the US public safety range.

>From my perspective, this is enough to reject the patch outright. I
assumed the frequencies and numbers were correct, which is why I
picked it up.

> Is this trying to add 4.9 GHz channels in general for multiple different
> use cases? And if so, what are those use cases? Or is this only for some
> public safety cases? And if so, for which regulatory domains?

I believe he has a client that requires this support in a Linux kernel.

> To be frank, I really don't see how this would be even close to a state
> that should be accepted into the upstream tree.

Fair enough I'm dropping this.

Kalle, I've marked this as rejected and archived on Patchwork.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [Query] mwifiex: few observations to reduce number of endian conversions

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 17, 2016 6:42 PM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: Linux Kernel; Linux Next; WiFi Mailing List; Johannes Berg
> Subject: [Query] mwifiex: few observations to reduce number of endian
> conversions
> 
> Hi Amitkumar,
> 
> I have two observations:
> 
> 1. I have found that in the command response path for host command
> "HostCmd_CMD_802_11_EEPROM_ACCESS", a "0" value has been endian
> converted. It can only be a safe futuristic approach for any non-zero
> value there however! Otherwise, the endian conversion can be removed.
> 
> 2. For multiple Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS
> etc.) "cpu_to_leX"-converted values are saved to driver. So "leX_to_cpu"
> conversion is required too many times afterwards in driver.
> On the contrary, we can save the values to driver without any
> conversion, and only command buffer(s) are prepared with endian
> converted values. In this way we can gain some efficiency [code size /
> time] by reducing the number of endian conversion considerably.
> 

I agree with your observations. We'll prepare a cleanup patch to address this.

Regards,
Amitkumar
N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter.

[Jouni Malinen]

On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote:
> I've only done this work as I hate to see people's efforts go to
> waste and I feel that there's enough roadblocks in the way of
> actually using this functionality that casual idiots won't be able
> to.

Are these really ready to go to the upstream kernel in this state and
without the other changes that would be needed to operate correctly?
What is the use case for these and how have these been tested?

> This is compile tested only as I cannot test this for real as I lack
> both the hardware and license required.

I don't think this is sufficient when touching this type of area. I
would not apply these without proper testing and full set of
functionality being available. I see no point in ath9k defining
additional channels if all those new channels can cause is harm and not
correct functionality. This channel list addition looks like the easiest
part to handle compared to the other patches needed for 4.9 GHz and this
would be the last patch on my list to get accepted..


> diff --git a/drivers/net/wireless/ath/ath9k/common-init.c 
> b/drivers/net/wireless/ath/ath9k/common-init.c
> +#ifdef ATH9K_49_GHZ_CHAN
> + /* 4.9Ghz channels, public safety channels, license is required in US
> +  * and most other regulatory domains!
> +  */
> + CHAN5G(4915, 38), /* Channel 183 */
> + CHAN5G(4920, 39), /* Channel 184 */
> + CHAN5G(4925, 40), /* Channel 185 */
> + CHAN5G(4935, 41), /* Channel 187 */
> + CHAN5G(4940, 42), /* Channel 188 */
> + CHAN5G(4945, 43), /* Channel 189 */
> + CHAN5G(4960, 44), /* Channel 192 */
> + CHAN5G(4970, 45), /* Channel 194 */
> + CHAN5G(4980, 46), /* Channel 196 */

Where are these channels defined and are these really correct
frequencies for them? Please note that many of the 4.9 GHz channels have
channel starting frequencies like 4.9375 GHz and 4.0025 GHz, i.e.,
fractional MHz.. While US public safety may not have all those cases,
even there are some 0.5 MHz cases. In addition, those channel numbers
sound more like some of the channels defined in Japan rather than US
public safety operating class. In addition, some of these channels seem
to be outside the US public safety range.

Is this trying to add 4.9 GHz channels in general for multiple different
use cases? And if so, what are those use cases? Or is this only for some
public safety cases? And if so, for which regulatory domains?

To be frank, I really don't see how this would be even close to a state
that should be accepted into the upstream tree.

-- 
Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

[Johannes Berg]

On Mon, 2016-06-13 at 23:21 +0200, Pavel Machek wrote:
> 
> (Actually, "::wifi" is super confusing, I'd expect that to be a led
> that blinks when wifi is active.)

Agree with that, yeah, that'd be confusing.

> Well... "airplane" is quite confusing. I'd we use "rfkill" for
> disabling radios, and I believe we should stick with that.
> 
> But small problem might be polarity. You may need both "::rfkill" and
> "::not-rfkill".

I'd argue that "airplane" matches better what you're likely to find on
the chassis of the system.

In either case I think the suffixes should be documented, for both
future kernel and application developers.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mac80211: mesh: Add support for HW RC implementation

[Johannes Berg]

> - if (sta->mesh->fail_avg >= 100)
> - return MAX_METRIC;
> + /* try to get rate based on HW RC algorithm */
> + rate = drv_get_expected_throughput(local, >sta);

This doesn't look correct, since you should use the rate control op if
available, to get data from rate control algorithms.

You should call sta_set_sinfo(), but that's far too much, so more
likely you should factor out the last few lines of that into a new
function and call that new function in both places.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mwifiex: disable MSIx interrupt for 8997 chipset

[Amitkumar Karwar]

From: Shengzhen Li 

Sometimes MSIx interrupts are received out of order on multi-core
system. This creates a problem when there is a race between data
packet and SLEEP event from firmware. We will disable MSIx interrupt
mode to solve the problem and go with MSI mode.

Signed-off-by: Shengzhen Li 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 2592e63..9c00c7e 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -258,7 +258,7 @@ static const struct mwifiex_pcie_card_reg mwifiex_reg_8997 
= {
.fw_dump_end = 0xcff,
.fw_dump_host_ready = 0xcc,
.fw_dump_read_done = 0xdd,
-   .msix_support = 1,
+   .msix_support = 0,
 };
 
 static struct memory_type_mapping mem_type_mapping_tbl_w8897[] = {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Troubleshooting mwl8k driver issue

[Lennert Buytenhek]

On Mon, Jun 20, 2016 at 07:36:30PM -0500, David Gilman wrote:

> > Nothing in here seems particularly bad.  So whatever the problem is,
> > I don't think it can be diagnosed from these messages alone.
> > 
> > I went back to the email thread, and it seems that the problem is that
> > you're trying to run the card in AP mode but no traffic is making it
> > through?  Is AP association working at all, or is that failing too?
> 
> The mwl8k is in AP mode and it gets associated just fine.  It'll work
> for five or so minutes and then you'll get the disconnect and the log
> messages in the earlier emails.  And it only happens with one of my
> wireless devices - the other one will browse all day with a stable
> connection to the mwl8k router.
> 
> Back in the OpenWRT issue a few more people have stuck their heads in
> to say they're also seeing the same issue.
> 
> https://dev.openwrt.org/ticket/21284

The only thing the log tells me is that this disconnect happens
voluntarily, so I see nothing wrong from just those log messages.
Can you run a sniffer to see what happens on the air when this
disconnect occurs, or increase hostapd verbosity/debugging somehow?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

[Jacek Anaszewski]

Hi Andrew,

This patch doesn't apply, please rebase onto recent LED tree.

On 06/21/2016 12:13 AM, Andrew F. Davis wrote:

Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.

Signed-off-by: Andrew F. Davis 
---
  include/linux/leds.h | 8 
  1 file changed, 8 insertions(+)

diff --git a/include/linux/leds.h b/include/linux/leds.h
index d2b1306..a4a3da6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -386,8 +386,16 @@ struct gpio_led_platform_data {
 unsigned long *delay_off);


Currently there is some stuff here, and in fact it has been for
a long time.

Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?


  };

+#ifdef CONFIG_NEW_LEDS
  struct platform_device *gpio_led_register_device(
 int id, const struct gpio_led_platform_data *pdata);
+#else
+static inline struct platform_device *gpio_led_register_device(
+   int id, const struct gpio_led_platform_data *pdata)
+{
+   return 0;
+}
+#endif

  enum cpu_led_event {
 CPU_LED_IDLE_START, /* CPU enters idle */




--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

[Kalle Valo]

Peter Oh  writes:

> where is 2/3 ?

You can find the patches from patchwork:

https://patchwork.kernel.org/patch/9187367/
https://patchwork.kernel.org/patch/9187361/
https://patchwork.kernel.org/patch/9187355/

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Encrypt "Group addressed privacy" action frames

[Masashi Honma]

On 2016年06月21日 06:25, Jouni Malinen wrote:

Do we really want that?


Sorry, I mis-understood your previous massage.
I have thought you required backward compatibility.
Ok, I will remove backward compatibility code.


> What about RX side?

Previously, MGTK and IGTK was identical key.
Now new wpa_supplicant can provide correct IGTK.
(Because of your great works !)
I have tested with new IGTK, RX side can work without
modification.

I will send new patch.
The patch move ieee80211_is_group_privacy_action()
to appropriate file and fix a bug of skip_hw flag.


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html