Re: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station ioctl file
Javier Martinez Canillas writes: >>> 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 I had forgotten to change the state of patches 1 and 3 from 'Changes Requested' back to 'New' and that's why I missed them. I did that now so they are back in my queue: https://patchwork.kernel.org/patch/9158855/ https://patchwork.kernel.org/patch/9158851/ Thanks for checking. -- 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: [PATCHv3] wlcore: spi: add wl18xx support
> > > > - 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: > > &spi1 { > > - wl1271@1 { > > + status = "okay"; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&spi1_pins>; > > + #address-cells = <1>; > > + #size-cells = <0>; > > None of this is really relevant to this binding. > Understood. Will remove in v4 > > + wlcore: wlcore@0 { > > Now your unit-address and reg value don't match. You are right. Will fix in v4 > > > compatible = "ti,wl1271"; > > - > > reg = <1>; > > spi-max-frequency = <4800>; > > clock-xtal; > > @@ -34,3 +50,20 @@ Examples: > > vwlan-supply = <&vwlan_fixed>; > > }; > > }; > > + > > +For wl18xx family: > > +&spi0 { > > + status = "okay"; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&spi0_pins>; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + wlcore: wlcore@0 { > > + compatible = "ti,wl1835"; > > + vwlan-supply = <&wlan_en_reg>; > > + spi-max-frequency = <4800>; > > + reg = <0>; > > + interrupt-parent = <&gpio0>; > > + 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
[PATCH V2 2/2] ath6kl: replace semaphore with mutex
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(&ar->sem)) { + if (mutex_lock_interruptible(&ar->mutex)) { ath6kl_err("busy, couldn't get access\n"); return -ERESTARTSYS; } if (test_bit(DESTROY_IN_PROGRESS, &ar->flag)) { ath6kl_err("busy, destroy in progress\n"); - up(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->mutex); return -EINTR; } } status = ath6kl_set_assoc_req_ies(vif, sme->ie, sme->ie_len); if (status) { - up(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem)) { + if (mutex_lock_interruptible(&ar->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, &ar->flag)) memset(vif->req_bssid, 0, sizeof(vif->req_bssid)); - up(&ar->sem); + mutex_unlock(&ar->mutex);
Re: [PATCH] mac80211: Fix mesh estab_plinks counting in STA removal case
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(&sta->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(&sta->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
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(&sta->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(&sta->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(&sta->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(&sta->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(&sta->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
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: > &spi1 { > - wl1271@1 { > + status = "okay"; > + pinctrl-names = "default"; > + pinctrl-0 = <&spi1_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 = <&vwlan_fixed>; > }; > }; > + > +For wl18xx family: > +&spi0{ > + status = "okay"; > + pinctrl-names = "default"; > + pinctrl-0 = <&spi0_pins>; > + #address-cells = <1>; > + #size-cells = <0>; > + wlcore: wlcore@0 { > + compatible = "ti,wl1835"; > + vwlan-supply = <&wlan_en_reg>; > + spi-max-frequency = <4800>; > + reg = <0>; > + interrupt-parent = <&gpio0>; > + 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
> 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
> */ > - 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(&sta->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
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
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
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
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] mwifiex: Reduce endian conversion for REG Host Commands
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, &rd_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] mac80211: Encrypt "Group addressed privacy" action frames
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 v2 2/2] staging: wilc1000: Replace kthread with workqueue for host interface
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?
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
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
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, &rd_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
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, &rd_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
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
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
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 = &cmd->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 = &cmd->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 = &cmd->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 = &cmd->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 = &cmd->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 mwifiex_ret_re
Re: [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter.
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.
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.
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?
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] leds: Add no-op gpio_led_register_device when LED subsystem is disabled
On 06/21/2016 01:48 PM, Andrew F. Davis wrote: 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. OK, I resolved the issues and applied, thanks. }; +#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 v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
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 &struct 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 &struct 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 &struct 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 &struct 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(&bss_cfg->crypto, &sme->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 *p
RE: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***
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 ***
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
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
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(&ar->sem); ^ vim +1177 drivers/net/wireless/ath/ath6kl/debug.c 1171 return -EBUSY; 1172 1173 set_bit(ROAM_TBL_PEND, &ar->flag); 1174 1175 ret = ath6kl_wmi_get_roam_tbl_cmd(ar->wmi); 1176 if (ret) { > 1177 mutex_unlock(&ar->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
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: &spi1 { - wl1271@1 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&spi1_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 = <&vwlan_fixed>; }; }; + +For wl18xx family: +&spi0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&spi0_pins>; + #address-cells = <1>; + #size-cells = <0>; + wlcore: wlcore@0 { + compatible = "ti,wl1835"; + vwlan-supply = <&wlan_en_reg>; + spi-max-frequency = <4800>; + reg = <0>; + interrupt-parent = <&gpio0>; + 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(glu
Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled
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
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
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(&ar->sem)) { + if (mutex_lock_interruptible(&ar->mutex)) { ath6kl_err("busy, couldn't get access\n"); return -ERESTARTSYS; } if (test_bit(DESTROY_IN_PROGRESS, &ar->flag)) { ath6kl_err("busy, destroy in progress\n"); - up(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->mutex); return -EINTR; } } status = ath6kl_set_assoc_req_ies(vif, sme->ie, sme->ie_len); if (status) { - up(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem); + mutex_unlock(&ar->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(&ar->sem)) { + if (mutex_lock_interruptible(&ar->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, &ar->flag)) memset(vif->req_bssid, 0, sizeof(vif->req_bssid)); - up(&ar->sem); + mutex_unlock(&ar->mutex); vif->sme_state = SME_DISCONNECTED; @@ -1775,7 +1775,7 @@ static int ath6kl_get_s
Re: NL80211_ATTR_PAD question
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.
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
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
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 (8
Re: [Query] mwifiex: few observations to reduce number of endian conversions
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
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.
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
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.
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
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
> - 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->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
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
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
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