Re: [RFC v3] mac80211: lock rate control
On Mon, 2015-04-13 at 17:26 -0400, Bob Copeland wrote: mac80211: introduce plink lock for plink fields The mesh plink code uses sta-lock to serialize access to the plink state fields between the peer link state machine and the peer link timer. Some paths (e.g. those involving mps_qos_null_tx()) unfortunately hold this spinlock across frame tx, which is soon to be disallowed. Add a new spinlock just for plink access. Signed-off-by: Bob Copeland m...@bobcopeland.com Thank you! I've applied both this and the rate control locking patch. We may later want to pick that up for stable perhaps, but let's let it bake a little longer, it's pretty big. 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: [RFC] mac80211_hwsim: notify user-space about channel change.
On Tue, 2015-03-31 at 08:56 -0700, Ben Greear wrote: Well, depends. Our driver just asks the firmware to do the scan, and it will do all the scheduling by itself, i.e. it'll go through the channels at convenient times etc. I do not want to offload scanning in user-space, which is the equivalent of what your driver is doing as far as the kernel is concerned? If someone wants to do that in the future, then sure, they can implement such a thing. Well, the question isn't really that offloading, the question is what happens with the hw-scan logic in hwsim? Though I guess now that I think about it, that wouldn't show up in userspace at all with your changes. 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 mac80211.h docbook comments
On Mon, 2015-04-13 at 18:27 +0200, Jonathan Corbet wrote: A couple of enums in mac80211.h became structures recently, but the comments didn't follow suit, leading to errors like: Error(.//include/net/mac80211.h:367): Cannot parse enum! Documentation/DocBook/Makefile:93: recipe for target 'Documentation/DocBook/80211.xml' failed make[1]: *** [Documentation/DocBook/80211.xml] Error 1 Makefile:1361: recipe for target 'mandocs' failed make: *** [mandocs] Error 2 Fix the comments comments accordingly. Added a couple of other small comment fixes while I was there to silence other recently-added docbook warnings. Applied, thanks! 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: [linux-wireless] was [wireless-regdb] [RFC] [PATCH] crda: enforce ETSI CAC timer of 600s on the weather band
De : Seth Forshee [mailto:seth.fors...@canonical.com] Envoyé : lundi 13 avril 2015 21:54 On Mon, Apr 13, 2015 at 09:36:33PM +0200, Johannes Berg wrote: On Mon, 2015-04-13 at 14:18 -0500, Seth Forshee wrote: On Mon, Apr 13, 2015 at 08:56:36PM +0200, Johannes Berg wrote: On Mon, 2015-04-13 at 11:23 -0500, Seth Forshee wrote: On Mon, Apr 13, 2015 at 05:31:14PM +0200, Jean-Pierre Tosoni wrote: A really weird patch that splits the U-NII-2e band into 1, 2 or 3 sub-bands to enforce a CAC time of 10 minutes in the range 5600-5650 MHz. Wrong maintainer / list. CRDA patches should be directed to Luis and the linux-wireless list (feel free to Cc wireless-regdb if you like). However, I'm not convinced that this actually *belongs* into the crda code? That seems like the wrong approach - shouldn't these rules be captured in the database? We do have AUTO-BW now so it should be possible, no? And if the timings aren't captured in the db.txt file they really should be. Yeah with AUTO-BW the bands could be broken up in db.txt, and we could even put in the CAC times. But we still can't get the CAC times into the current regulatory.bin format, so it doesn't really accomplish anything. But then there's also little point in putting any code for it into the crda binary, no? I agree that this belongs to db.txt and regulatory.bin rather than crda, but until the problem of defining a new format for regulatory.bin is settled, there is no other way. However I am not sure my patch should go to mainstream since in my mind it is temporary approach. But it does enforce ETSI regulations and still allow using weather frequencies. Just to be clear, I'm not arguing for or against the patch at all. I'm only trying to explain why Jean-Pierre is proposing to change CRDA rather than db.txt. Maybe I should just let him speak for himself ... As I understand it Jean-Pierre is looking for a stop-gap to get CAC times into the kernel until such time as we have a file format which allows getting them from regulatory.bin. Changing CRDA can accomplish this, whereas modifying db.txt cannot. That's exactly what I meant. Jean-Pierre -- 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: CT ath10k firmware now supports IBSS + RSN
On 04/13/2015 10:34 PM, Michal Kazior wrote: On 14 April 2015 at 02:10, Ben Greear gree...@candelatech.com wrote: On 04/13/2015 10:41 AM, Ben Greear wrote: Looks like I have some more work to do. For any moderately large frames, I am now dropping the last 16 bytes. Looks like the skb_put_padto logic was working around a more serious issue... A better-tested version of kernel and firmware is uploaded now. Looks like I needed to add a hack to firmware to bump pkt-size by 16 for IBSS + RSN encrypted frames. Not sure exactly why, but seems to work in light testing. I removed the skb-padto hack from the kernel, and kernel is rebased on top of official 4.0 now. Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must be different from frame length (ath10k_htt_tx(), htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1] needs to be applied..? [1]: https://www.mail-archive.com/ath10k@lists.infradead.org/msg00241.html This IBSS+RSN hack could be done in the kernel, but if my firmware is the only thing that needs it, then it is more convenient for me to hack firmware than have it incompatible with upstream drivers. If you do find similar problems with other firmware, then certainly a driver patch is welcome, and I will back out my firmware hack accordingly. And, it would be nice if someone put some version if your raw-tx patch upstream. I can also adjust length for raw pkts in firmware too, but again, in many cases it is better to be similarly broken to existing firmware than to be technically correct but break compatibility with the driver. If I ever get a 'ct-firmware' feature flag upstream, then we could of course do the changes to take advantage of my firmwares differences as needed. Thanks, Ben -- Ben Greear gree...@candelatech.com 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
[RFC/RFT 06/11] wlcore: enable IEEE80211_HW_SUPPORT_FAST_XMIT
From: Johannes Berg johannes.b...@intel.com The driver can clearly enable fast-xmit since it does rate control in the device and thus must do duration calculation there as well. Signed-off-by: Johannes Berg johannes.b...@intel.com --- drivers/net/wireless/ti/wlcore/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c index 1e136993580f..34cef10aefc5 100644 --- a/drivers/net/wireless/ti/wlcore/main.c +++ b/drivers/net/wireless/ti/wlcore/main.c @@ -6077,7 +6077,8 @@ static int wl1271_init_ieee80211(struct wl1271 *wl) IEEE80211_HW_AMPDU_AGGREGATION | IEEE80211_HW_TX_AMPDU_SETUP_IN_HW | IEEE80211_HW_QUEUE_CONTROL | - IEEE80211_HW_CHANCTX_STA_CSA; + IEEE80211_HW_CHANCTX_STA_CSA | + IEEE80211_HW_SUPPORT_FAST_XMIT; wl-hw-wiphy-cipher_suites = cipher_suites; wl-hw-wiphy-n_cipher_suites = ARRAY_SIZE(cipher_suites); -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] brcmfmac: add additional 43602 pcie device id.
From: Hante Meuleman meule...@broadcom.com
Reviewed-by: Arend Van Spriel ar...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Hante Meuleman meule...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 1 +
drivers/net/wireless/brcm80211/include/brcm_hw_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
index 8815de7..5e97a97 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
@@ -1862,6 +1862,7 @@ static struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_2G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_5G_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_RAW_DEVICE_ID),
{ /* end: all zeroes */ }
};
diff --git a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
index 2543282..7a6daa3 100644
--- a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
@@ -64,6 +64,7 @@
#define BRCM_PCIE_43602_DEVICE_ID 0x43ba
#define BRCM_PCIE_43602_2G_DEVICE_ID 0x43bb
#define BRCM_PCIE_43602_5G_DEVICE_ID 0x43bc
+#define BRCM_PCIE_43602_RAW_DEVICE_ID 43602
/* brcmsmac IDs */
#define BCM4313_D11N2G_ID 0x4727 /* 4313 802.11n 2.4G device */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.18.y] brcmfmac: Perform bound checking on vendor command buffer
From: Pontus Fuchs pont...@broadcom.com
commit 3f1615340acea54e21f4b9d4d65921540dca84b2 upstream.
A short or malformed vendor command buffer could cause reads outside
the command buffer.
Signed-off-by: Pontus Fuchs pont...@broadcom.com
[ar...@broadcom.com: slightly modified debug trace output]
Signed-off-by: Arend van Spriel ar...@broadcom.com
Signed-off-by: Kalle Valo kv...@codeaurora.org
---
drivers/net/wireless/brcm80211/brcmfmac/vendor.c | 30 +---
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/vendor.c
b/drivers/net/wireless/brcm80211/brcmfmac/vendor.c
index 5960d82..e29674e 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/vendor.c
@@ -31,18 +31,30 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct
wiphy *wiphy,
struct wireless_dev *wdev,
const void *data, int len)
{
- struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
- struct net_device *ndev = cfg_to_ndev(cfg);
+ struct brcmf_cfg80211_vif *vif;
+ struct brcmf_if *ifp;
const struct brcmf_vndr_dcmd_hdr *cmdhdr = data;
struct sk_buff *reply;
int ret, payload, ret_len;
void *dcmd_buf = NULL, *wr_pointer;
u16 msglen, maxmsglen = PAGE_SIZE - 0x100;
- brcmf_dbg(TRACE, cmd %x set %d len %d\n, cmdhdr-cmd, cmdhdr-set,
- cmdhdr-len);
+ if (len sizeof(*cmdhdr)) {
+ brcmf_err(vendor command too short: %d\n, len);
+ return -EINVAL;
+ }
+
+ vif = container_of(wdev, struct brcmf_cfg80211_vif, wdev);
+ ifp = vif-ifp;
+
+ brcmf_dbg(TRACE, ifidx=%d, cmd=%d\n, ifp-ifidx, cmdhdr-cmd);
+
+ if (cmdhdr-offset len) {
+ brcmf_err(bad buffer offset %d %d\n, cmdhdr-offset, len);
+ return -EINVAL;
+ }
- len -= sizeof(struct brcmf_vndr_dcmd_hdr);
+ len -= cmdhdr-offset;
ret_len = cmdhdr-len;
if (ret_len 0 || len 0) {
if (len BRCMF_DCMD_MAXLEN) {
@@ -63,11 +75,11 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct
wiphy *wiphy,
}
if (cmdhdr-set)
- ret = brcmf_fil_cmd_data_set(netdev_priv(ndev), cmdhdr-cmd,
-dcmd_buf, ret_len);
+ ret = brcmf_fil_cmd_data_set(ifp, cmdhdr-cmd, dcmd_buf,
+ret_len);
else
- ret = brcmf_fil_cmd_data_get(netdev_priv(ndev), cmdhdr-cmd,
-dcmd_buf, ret_len);
+ ret = brcmf_fil_cmd_data_get(ifp, cmdhdr-cmd, dcmd_buf,
+ret_len);
if (ret != 0)
goto exit;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] brcmfmac: device support and fixes
This series include some fixes related to SDIO suspend and resume, wiphy band info and changes in regulatory settings. Furthermore, support for BCM4324 SDIO and BCM4358 PCIe is added. Finally, some patches from Hante that should enable support of PCIe devices on router platforms. This series is intended for v4.2 and applies to the master branch of the wireless-drivers-next repository. Arend van Spriel (8): brcmfmac: use static superset of channels for wiphy bands brcmfmac: update wiphy band information upon updating regulatory domain brcmfmac: add description for feature flags brcmfmac: make scheduled scan support conditional brcmfmac: add support for BCM4324 rev B5 chipset brcmfmac: process interrupt regardless sdiod state brcmfmac: fix sdio suspend and resume brcmfmac: add support for BCM4358 PCIe device Hante Meuleman (2): brcmfmac: add additional 43602 pcie device id. brcmfmac: Add support for multiple PCIE devices in nvram. drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 18 +- drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 202 - drivers/net/wireless/brcm80211/brcmfmac/chip.c | 1 + drivers/net/wireless/brcm80211/brcmfmac/feature.c | 1 + drivers/net/wireless/brcm80211/brcmfmac/feature.h | 4 + drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 189 ++- drivers/net/wireless/brcm80211/brcmfmac/firmware.h | 6 + drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 25 ++- drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 11 +- .../net/wireless/brcm80211/include/brcm_hw_ids.h | 3 + 10 files changed, 348 insertions(+), 112 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] brcmfmac: fix sdio suspend and resume
commit 330b4e4be937 (brcmfmac: Add wowl support for SDIO devices.)
changed the behaviour by removing the MMC_PM_KEEP_POWER flag for
non-wowl scenario, which needs to be restored. Another necessary
change is to mark the card as being non-removable. With this in place
the suspend resume test passes successfully doing:
# echo devices /sys/power/pm_test
# echo mem /sys/power/state
Note that power may still be switched off when system is going
in S3 state.
Reported-by: Fu, Zhonghui zhonghui...@linux.intel.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 9b508bd..8a69544 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -1011,6 +1011,14 @@ static int brcmf_sdiod_remove(struct brcmf_sdio_dev
*sdiodev)
return 0;
}
+static void brcmf_sdiod_host_fixup(struct mmc_host *host)
+{
+ /* runtime-pm powers off the device */
+ pm_runtime_forbid(host-parent);
+ /* avoid removal detection upon resume */
+ host-caps |= MMC_CAP_NONREMOVABLE;
+}
+
static int brcmf_sdiod_probe(struct brcmf_sdio_dev *sdiodev)
{
struct sdio_func *func;
@@ -1076,7 +1084,7 @@ static int brcmf_sdiod_probe(struct brcmf_sdio_dev
*sdiodev)
ret = -ENODEV;
goto out;
}
- pm_runtime_forbid(host-parent);
+ brcmf_sdiod_host_fixup(host);
out:
if (ret)
brcmf_sdiod_remove(sdiodev);
@@ -1246,15 +1254,15 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
brcmf_sdiod_freezer_on(sdiodev);
brcmf_sdio_wd_timer(sdiodev-bus, 0);
+ sdio_flags = MMC_PM_KEEP_POWER;
if (sdiodev-wowl_enabled) {
- sdio_flags = MMC_PM_KEEP_POWER;
if (sdiodev-pdata-oob_irq_supported)
enable_irq_wake(sdiodev-pdata-oob_irq_nr);
else
- sdio_flags = MMC_PM_WAKE_SDIO_IRQ;
- if (sdio_set_host_pm_flags(sdiodev-func[1], sdio_flags))
- brcmf_err(Failed to set pm_flags %x\n, sdio_flags);
+ sdio_flags |= MMC_PM_WAKE_SDIO_IRQ;
}
+ if (sdio_set_host_pm_flags(sdiodev-func[1], sdio_flags))
+ brcmf_err(Failed to set pm_flags %x\n, sdio_flags);
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] brcmfmac: make scheduled scan support conditional
The scheduled scan support depends on firmware supporting the PNO feature. This feature is optional so add a feature flag for this in the driver and announce scheduled scan support accordingly. Reviewed-by: Hante Meuleman meule...@broadcom.com Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com Signed-off-by: Arend van Spriel ar...@broadcom.com --- drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 3 ++- drivers/net/wireless/brcm80211/brcmfmac/feature.c | 1 + drivers/net/wireless/brcm80211/brcmfmac/feature.h | 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c index 84d9ab1..6fe2b75 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c @@ -5783,7 +5783,8 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp) wiphy-flags |= WIPHY_FLAG_SUPPORTS_FW_ROAM; wiphy-mgmt_stypes = brcmf_txrx_stypes; wiphy-max_remain_on_channel_duration = 5000; - brcmf_wiphy_pno_params(wiphy); + if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO)) + brcmf_wiphy_pno_params(wiphy); /* vendor commands/events support */ wiphy-vendor_commands = brcmf_vendor_cmds; diff --git a/drivers/net/wireless/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/brcm80211/brcmfmac/feature.c index 7748a1c..2c5fad3 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/feature.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/feature.c @@ -124,6 +124,7 @@ void brcmf_feat_attach(struct brcmf_pub *drvr) struct brcmf_if *ifp = drvr-iflist[0]; brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_MCHAN, mchan); + brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_PNO, pfn); if (drvr-bus_if-wowl_supported) brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_WOWL, wowl); if (drvr-bus_if-chip != BRCM_CC_43362_CHIP_ID) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/brcm80211/brcmfmac/feature.h index 4bf40ff..5469625 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/feature.h +++ b/drivers/net/wireless/brcm80211/brcmfmac/feature.h @@ -21,11 +21,13 @@ * * MBSS: multiple BSSID support (eg. guest network in AP mode). * MCHAN: multi-channel for concurrent P2P. + * PNO: preferred network offload. * WOWL: Wake-On-WLAN. */ #define BRCMF_FEAT_LIST \ BRCMF_FEAT_DEF(MBSS) \ BRCMF_FEAT_DEF(MCHAN) \ + BRCMF_FEAT_DEF(PNO) \ BRCMF_FEAT_DEF(WOWL) /* * Quirks: -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] brcmfmac: use static superset of channels for wiphy bands
The driver was constructing a list of channels per wiphy band
by querying the device. This list is not what the hardware is
able to do as it is already filtered by the country setting in
the device. As user-space may change the country this would
require updating the channel list which is not recommended [1].
This patch introduces a superset of channels. The individual
channels are disabled appropriately by querying the device.
[1] http://mid.gmane.org/1426706320.3001.21.ca...@sipsolutions.net
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Daniel (Deognyoun) Kim de...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 193 +++--
1 file changed, 106 insertions(+), 87 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
index 8a15ebb..76dff0e 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -129,13 +129,47 @@ static struct ieee80211_rate __wl_rates[] = {
RATETAB_ENT(BRCM_RATE_54M, 0),
};
-#define wl_a_rates (__wl_rates + 4)
-#define wl_a_rates_size8
#define wl_g_rates (__wl_rates + 0)
-#define wl_g_rates_size12
+#define wl_g_rates_sizeARRAY_SIZE(__wl_rates)
+#define wl_a_rates (__wl_rates + 4)
+#define wl_a_rates_size(wl_g_rates_size - 4)
+
+#define CHAN2G(_channel, _freq) { \
+ .band = IEEE80211_BAND_2GHZ, \
+ .center_freq= (_freq), \
+ .hw_value = (_channel), \
+ .flags = IEEE80211_CHAN_DISABLED, \
+ .max_antenna_gain = 0,\
+ .max_power = 30, \
+}
+
+#define CHAN5G(_channel) { \
+ .band = IEEE80211_BAND_5GHZ, \
+ .center_freq= 5000 + (5 * (_channel)), \
+ .hw_value = (_channel), \
+ .flags = IEEE80211_CHAN_DISABLED, \
+ .max_antenna_gain = 0,\
+ .max_power = 30, \
+}
+
+static struct ieee80211_channel __wl_2ghz_channels[] = {
+ CHAN2G(1, 2412), CHAN2G(2, 2417), CHAN2G(3, 2422), CHAN2G(4, 2427),
+ CHAN2G(5, 2432), CHAN2G(6, 2437), CHAN2G(7, 2442), CHAN2G(8, 2447),
+ CHAN2G(9, 2452), CHAN2G(10, 2457), CHAN2G(11, 2462), CHAN2G(12, 2467),
+ CHAN2G(13, 2472), CHAN2G(14, 2484)
+};
+
+static struct ieee80211_channel __wl_5ghz_channels[] = {
+ CHAN5G(34), CHAN5G(36), CHAN5G(38), CHAN5G(40), CHAN5G(42),
+ CHAN5G(44), CHAN5G(46), CHAN5G(48), CHAN5G(52), CHAN5G(56),
+ CHAN5G(60), CHAN5G(64), CHAN5G(100), CHAN5G(104), CHAN5G(108),
+ CHAN5G(112), CHAN5G(116), CHAN5G(120), CHAN5G(124), CHAN5G(128),
+ CHAN5G(132), CHAN5G(136), CHAN5G(140), CHAN5G(144), CHAN5G(149),
+ CHAN5G(153), CHAN5G(157), CHAN5G(161), CHAN5G(165)
+};
/* Band templates duplicated per wiphy. The channel info
- * is filled in after querying the device.
+ * above is added to the band during setup.
*/
static const struct ieee80211_supported_band __wl_band_2ghz = {
.band = IEEE80211_BAND_2GHZ,
@@ -143,7 +177,7 @@ static const struct ieee80211_supported_band __wl_band_2ghz
= {
.n_bitrates = wl_g_rates_size,
};
-static const struct ieee80211_supported_band __wl_band_5ghz_a = {
+static const struct ieee80211_supported_band __wl_band_5ghz = {
.band = IEEE80211_BAND_5GHZ,
.bitrates = wl_a_rates,
.n_bitrates = wl_a_rates_size,
@@ -5253,40 +5287,6 @@ dongle_scantime_out:
return err;
}
-/* Filter the list of channels received from firmware counting only
- * the 20MHz channels. The wiphy band data only needs those which get
- * flagged to indicate if they can take part in higher bandwidth.
- */
-static void brcmf_count_20mhz_channels(struct brcmf_cfg80211_info *cfg,
- struct brcmf_chanspec_list *chlist,
- u32 chcnt[])
-{
- u32 total = le32_to_cpu(chlist-count);
- struct brcmu_chan ch;
- int i;
-
- for (i = 0; i total; i++) {
- ch.chspec = (u16)le32_to_cpu(chlist-element[i]);
- cfg-d11inf.decchspec(ch);
-
- /* Firmware gives a ordered list. We skip non-20MHz
-* channels is 2G. For 5G we can abort upon reaching
-* a non-20MHz channel in the list.
-*/
- if (ch.bw != BRCMU_CHAN_BW_20) {
- if (ch.band == BRCMU_CHAN_BAND_5G)
-
[PATCH 06/10] brcmfmac: process interrupt regardless sdiod state
When the sdio bus state is not ready to process we abort the
interrupt service routine. This is not wanted as it keeps the
interrupt source active. Better clear the interrupt source.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index cbdda54..bf7a8b1 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -3555,10 +3555,6 @@ void brcmf_sdio_isr(struct brcmf_sdio *bus)
return;
}
- if (bus-sdiodev-state != BRCMF_SDIOD_DATA) {
- brcmf_err(bus is down. we have nothing to do\n);
- return;
- }
/* Count the interrupt call */
bus-sdcnt.intrcount++;
if (in_interrupt())
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] brcmfmac: add description for feature flags
Some feature flags were not described in the header file. Adding the description. Reviewed-by: Hante Meuleman meule...@broadcom.com Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com Signed-off-by: Arend van Spriel ar...@broadcom.com --- drivers/net/wireless/brcm80211/brcmfmac/feature.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/brcm80211/brcmfmac/feature.h index f5832e0..4bf40ff 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/feature.h +++ b/drivers/net/wireless/brcm80211/brcmfmac/feature.h @@ -19,7 +19,9 @@ /* * Features: * + * MBSS: multiple BSSID support (eg. guest network in AP mode). * MCHAN: multi-channel for concurrent P2P. + * WOWL: Wake-On-WLAN. */ #define BRCMF_FEAT_LIST \ BRCMF_FEAT_DEF(MBSS) \ -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] brcmfmac: update wiphy band information upon updating regulatory domain
When change the country code the available channels may change. So
the wiphy bands should be updated accordingly.
Reviewed-by: Daniel (Deognyoun) Kim de...@broadcom.com
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
index 76dff0e..84d9ab1 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -6023,7 +6023,11 @@ static void brcmf_cfg80211_reg_notifier(struct wiphy
*wiphy,
memset(ccreq, 0, sizeof(ccreq));
ccreq.rev = cpu_to_le32(-1);
memcpy(ccreq.ccode, req-alpha2, sizeof(req-alpha2));
- brcmf_fil_iovar_data_set(ifp, country, ccreq, sizeof(ccreq));
+ if (brcmf_fil_iovar_data_set(ifp, country, ccreq, sizeof(ccreq))) {
+ brcmf_err(firmware rejected country setting\n);
+ return;
+ }
+ brcmf_setup_wiphybands(wiphy);
}
static void brcmf_free_wiphy(struct wiphy *wiphy)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
From: Hante Meuleman meule...@broadcom.com
With PCIE it is possible to support multiple devices with the
same device type. They all load the same nvram file. In order to
support this the nvram can specify which part of the nvram is
for which pcie device. This patch adds support for these new
types of nvram files.
Reviewed-by: Arend Van Spriel ar...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Reviewed-by: Daniel (Deognyoun) Kim de...@broadcom.com
Signed-off-by: Hante Meuleman meule...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 189 -
drivers/net/wireless/brcm80211/brcmfmac/firmware.h | 6 +
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 15 +-
3 files changed, 197 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
index 9cb9915..8ff31ff 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
@@ -23,6 +23,10 @@
#include debug.h
#include firmware.h
+#define BRCMF_FW_MAX_NVRAM_SIZE64000
+#define BRCMF_FW_NVRAM_DEVPATH_LEN 19 /* devpath0=pcie/1/4/ */
+#define BRCMF_FW_NVRAM_PCIEDEV_LEN 9 /* pcie/1/4/ */
+
char brcmf_firmware_path[BRCMF_FW_PATH_LEN];
module_param_string(firmware_path, brcmf_firmware_path,
BRCMF_FW_PATH_LEN, 0440);
@@ -46,6 +50,8 @@ enum nvram_parser_state {
* @column: current column in line.
* @pos: byte offset in input buffer.
* @entry: start position of key,value entry.
+ * @multi_dev_v1: detect pcie multi device v1 (compressed).
+ * @multi_dev_v2: detect pcie multi device v2.
*/
struct nvram_parser {
enum nvram_parser_state state;
@@ -56,6 +62,8 @@ struct nvram_parser {
u32 column;
u32 pos;
u32 entry;
+ bool multi_dev_v1;
+ bool multi_dev_v2;
};
static bool is_nvram_char(char c)
@@ -108,6 +116,10 @@ static enum nvram_parser_state
brcmf_nvram_handle_key(struct nvram_parser *nvp)
st = COMMENT;
else
st = VALUE;
+ if (strncmp(nvp-fwnv-data[nvp-entry], devpath, 7) == 0)
+ nvp-multi_dev_v1 = true;
+ if (strncmp(nvp-fwnv-data[nvp-entry], pcie/, 5) == 0)
+ nvp-multi_dev_v2 = true;
} else if (!is_nvram_char(c)) {
brcmf_dbg(INFO, warning: ln=%d:col=%d: '=' expected, skip
invalid key entry\n,
nvp-line, nvp-column);
@@ -133,6 +145,8 @@ brcmf_nvram_handle_value(struct nvram_parser *nvp)
ekv = (u8 *)nvp-fwnv-data[nvp-pos];
skv = (u8 *)nvp-fwnv-data[nvp-entry];
cplen = ekv - skv;
+ if (nvp-nvram_len + cplen + 1 = BRCMF_FW_MAX_NVRAM_SIZE)
+ return END;
/* copy to output buffer */
memcpy(nvp-nvram[nvp-nvram_len], skv, cplen);
nvp-nvram_len += cplen;
@@ -180,10 +194,18 @@ static enum nvram_parser_state
static int brcmf_init_nvram_parser(struct nvram_parser *nvp,
const struct firmware *nv)
{
+ size_t size;
+
memset(nvp, 0, sizeof(*nvp));
nvp-fwnv = nv;
+ /* Limit size to MAX_NVRAM_SIZE, some files contain lot of comment */
+ if (nv-size BRCMF_FW_MAX_NVRAM_SIZE)
+ size = BRCMF_FW_MAX_NVRAM_SIZE;
+ else
+ size = nv-size;
/* Alloc for extra 0 byte + roundup by 4 + length field */
- nvp-nvram = kzalloc(nv-size + 1 + 3 + sizeof(u32), GFP_KERNEL);
+ size += 1 + 3 + sizeof(u32);
+ nvp-nvram = kzalloc(size, GFP_KERNEL);
if (!nvp-nvram)
return -ENOMEM;
@@ -192,12 +214,136 @@ static int brcmf_init_nvram_parser(struct nvram_parser
*nvp,
return 0;
}
+/* brcmf_fw_strip_multi_v1 :Some nvram files contain settings for multiple
+ * devices. Strip it down for one device, use domain_nr/bus_nr to determine
+ * which data is to be returned. v1 is the version where nvram is stored
+ * compressed and devpath maps to index for valid entries.
+ */
+static void brcmf_fw_strip_multi_v1(struct nvram_parser *nvp, u16 domain_nr,
+ u16 bus_nr)
+{
+ u32 i, j;
+ bool found;
+ u8 *nvram;
+ u8 id;
+
+ nvram = kzalloc(nvp-nvram_len + 1 + 3 + sizeof(u32), GFP_KERNEL);
+ if (!nvram)
+ goto fail;
+
+ /* min length: devpath0=pcie/1/4/ + 0:x=y */
+ if (nvp-nvram_len BRCMF_FW_NVRAM_DEVPATH_LEN + 6)
+ goto fail;
+
+ /* First search for the devpathX and see if it is the configuration
+* for domain_nr/bus_nr. Search complete nvp
+*/
+ found = false;
[PATCH 08/10] brcmfmac: add support for BCM4358 PCIe device
This patch adds support for the BCM4358 2x2 11ac device.
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/chip.c | 1 +
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 9 +
drivers/net/wireless/brcm80211/include/brcm_hw_ids.h | 2 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/chip.c
b/drivers/net/wireless/brcm80211/brcmfmac/chip.c
index ab2fac8..288f831 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/chip.c
@@ -649,6 +649,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv
*ci)
case BRCM_CC_43567_CHIP_ID:
case BRCM_CC_43569_CHIP_ID:
case BRCM_CC_43570_CHIP_ID:
+ case BRCM_CC_4358_CHIP_ID:
case BRCM_CC_43602_CHIP_ID:
return 0x18;
default:
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
index 1831ecd..8815de7 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
@@ -51,6 +51,8 @@ enum brcmf_pcie_state {
#define BRCMF_PCIE_4356_NVRAM_NAME brcm/brcmfmac4356-pcie.txt
#define BRCMF_PCIE_43570_FW_NAME brcm/brcmfmac43570-pcie.bin
#define BRCMF_PCIE_43570_NVRAM_NAMEbrcm/brcmfmac43570-pcie.txt
+#define BRCMF_PCIE_4358_FW_NAME
brcm/brcmfmac4358-pcie.bin
+#define BRCMF_PCIE_4358_NVRAM_NAME brcm/brcmfmac4358-pcie.txt
#define BRCMF_PCIE_FW_UP_TIMEOUT 2000 /* msec */
@@ -189,6 +191,8 @@ MODULE_FIRMWARE(BRCMF_PCIE_4356_FW_NAME);
MODULE_FIRMWARE(BRCMF_PCIE_4356_NVRAM_NAME);
MODULE_FIRMWARE(BRCMF_PCIE_43570_FW_NAME);
MODULE_FIRMWARE(BRCMF_PCIE_43570_NVRAM_NAME);
+MODULE_FIRMWARE(BRCMF_PCIE_4358_FW_NAME);
+MODULE_FIRMWARE(BRCMF_PCIE_4358_NVRAM_NAME);
struct brcmf_pcie_console {
@@ -1333,6 +1337,10 @@ static int brcmf_pcie_get_fwnames(struct
brcmf_pciedev_info *devinfo)
fw_name = BRCMF_PCIE_43570_FW_NAME;
nvram_name = BRCMF_PCIE_43570_NVRAM_NAME;
break;
+ case BRCM_CC_4358_CHIP_ID:
+ fw_name = BRCMF_PCIE_4358_FW_NAME;
+ nvram_name = BRCMF_PCIE_4358_NVRAM_NAME;
+ break;
default:
brcmf_err(Unsupported chip 0x%04x\n, devinfo-ci-chip);
return -ENODEV;
@@ -1850,6 +1858,7 @@ static struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_4358_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_2G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_5G_DEVICE_ID),
diff --git a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
index 4efdd51..2543282 100644
--- a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
@@ -45,6 +45,7 @@
#define BRCM_CC_43567_CHIP_ID 43567
#define BRCM_CC_43569_CHIP_ID 43569
#define BRCM_CC_43570_CHIP_ID 43570
+#define BRCM_CC_4358_CHIP_ID 0x4358
#define BRCM_CC_43602_CHIP_ID 43602
/* USB Device IDs */
@@ -59,6 +60,7 @@
#define BRCM_PCIE_4356_DEVICE_ID 0x43ec
#define BRCM_PCIE_43567_DEVICE_ID 0x43d3
#define BRCM_PCIE_43570_DEVICE_ID 0x43d9
+#define BRCM_PCIE_4358_DEVICE_ID 0x43e9
#define BRCM_PCIE_43602_DEVICE_ID 0x43ba
#define BRCM_PCIE_43602_2G_DEVICE_ID 0x43bb
#define BRCM_PCIE_43602_5G_DEVICE_ID 0x43bc
--
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
[RFC/RFT 11/11] mac80211: allow segmenation offloads
From: Johannes Berg johannes.b...@intel.com
Implement the necessary software segmentation on the normal
TX path so that fast-xmit can use segmentation offload if
the hardware (or driver) supports it.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/tx.c | 70 ++
2 files changed, 48 insertions(+), 25 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 25a456c48043..d912e614f53b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -87,7 +87,8 @@ struct ieee80211_local;
#define IEEE80211_SUPPORTED_NETDEV_FEATURES\
(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | \
NETIF_F_HW_CSUM | NETIF_F_RXCSUM | \
-NETIF_F_SG | NETIF_F_HIGHDMA)
+NETIF_F_SG | NETIF_F_HIGHDMA | \
+NETIF_F_GSO_SOFTWARE)
struct ieee80211_fragment_entry {
unsigned long first_frag_time;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 53a16257dfc1..24b082f65a20 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2827,6 +2827,7 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct sta_info *sta;
+ struct sk_buff *next;
if (unlikely(skb-len ETH_HLEN)) {
kfree_skb(skb);
@@ -2848,36 +2849,57 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
goto out;
}
- /* we cannot process non-linear frames on this path */
- if (skb_linearize(skb)) {
- kfree_skb(skb);
- goto out;
- }
+ if (netif_needs_gso(dev, skb, 0)) {
+ struct sk_buff *segs;
- /* the frame could be fragmented, software-encrypted, and other things
-* so we cannot really handle checksum offload with it - fix it up in
-* software before we handle anything else.
-*/
- if (skb-ip_summed == CHECKSUM_PARTIAL) {
- if (skb-encapsulation)
- skb_set_inner_transport_header(skb,
-
skb_checksum_start_offset(skb));
- else
- skb_set_transport_header(skb,
-
skb_checksum_start_offset(skb));
- if (skb_checksum_help(skb))
+ segs = skb_gso_segment(skb, 0);
+ if (IS_ERR(segs)) {
goto out_free;
+ } else if (segs) {
+ consume_skb(skb);
+ skb = segs;
+ }
+ } else {
+ /* we cannot process non-linear frames on this path */
+ if (skb_linearize(skb)) {
+ kfree_skb(skb);
+ goto out;
+ }
+
+ /* the frame could be fragmented, software-encrypted, and other
+* things so we cannot really handle checksum offload with it -
+* fix it up in software before we handle anything else.
+*/
+ if (skb-ip_summed == CHECKSUM_PARTIAL) {
+ if (skb-encapsulation)
+ skb_set_inner_transport_header(skb,
+
skb_checksum_start_offset(skb));
+ else
+ skb_set_transport_header(skb,
+
skb_checksum_start_offset(skb));
+ if (skb_checksum_help(skb))
+ goto out_free;
+ }
}
- skb = ieee80211_build_hdr(sdata, skb, info_flags, sta);
- if (IS_ERR(skb))
- goto out;
+ next = skb;
+ while (next) {
+ skb = next;
+ next = skb-next;
- dev-stats.tx_packets++;
- dev-stats.tx_bytes += skb-len;
- dev-trans_start = jiffies;
+ skb-prev = NULL;
+ skb-next = NULL;
+
+ skb = ieee80211_build_hdr(sdata, skb, info_flags, sta);
+ if (IS_ERR(skb))
+ goto out;
- ieee80211_xmit(sdata, sta, skb);
+ dev-stats.tx_packets++;
+ dev-stats.tx_bytes += skb-len;
+ dev-trans_start = jiffies;
+
+ ieee80211_xmit(sdata, sta, skb);
+ }
goto out;
out_free:
kfree_skb(skb);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT 08/11] mac80211: allow checksum offload only in fast-xmit
From: Johannes Berg johannes.b...@intel.com
When we go through the complete TX processing, there are a number
of things like fragmentation and software crypto that require the
checksum to be calculated already.
In favour of maintainability, instead of adding the necessary call
to skb_checksum_help() in all the places that need it, just do it
once before the regular TX processing.
Right now this only affects the TI wlcore and QCA ath10k drivers
since they're the only ones using checksum offload. The previous
commits enabled fast-xmit for them in almost all cases.
For wlcore this even fixes a corner case: when a key fails to be
programmed to hardware software encryption gets used, encrypting
frames with a bad checksum.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/tx.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 0f18ee11f097..e76f3e96eb84 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2835,10 +2835,8 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
rcu_read_lock();
- if (ieee80211_lookup_ra_sta(sdata, skb, sta)) {
- kfree_skb(skb);
- goto out;
- }
+ if (ieee80211_lookup_ra_sta(sdata, skb, sta))
+ goto out_free;
if (!IS_ERR_OR_NULL(sta)) {
struct ieee80211_fast_tx *fast_tx;
@@ -2850,6 +2848,21 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
goto out;
}
+ /* the frame could be fragmented, software-encrypted, and other things
+* so we cannot really handle checksum offload with it - fix it up in
+* software before we handle anything else.
+*/
+ if (skb-ip_summed == CHECKSUM_PARTIAL) {
+ if (skb-encapsulation)
+ skb_set_inner_transport_header(skb,
+
skb_checksum_start_offset(skb));
+ else
+ skb_set_transport_header(skb,
+
skb_checksum_start_offset(skb));
+ if (skb_checksum_help(skb))
+ goto out_free;
+ }
+
skb = ieee80211_build_hdr(sdata, skb, info_flags, sta);
if (IS_ERR(skb))
goto out;
@@ -2859,6 +2872,9 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
dev-trans_start = jiffies;
ieee80211_xmit(sdata, sta, skb);
+ goto out;
+ out_free:
+ kfree_skb(skb);
out:
rcu_read_unlock();
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT 00/11] mac80211: enable fast-xmit and some offloads
On Tue, 2015-04-14 at 17:03 +0200, Johannes Berg wrote: First, add the TX fastpath (fast-xmit) that I've been kicking around for a while. I'm pretty happy with the abstraction since it allows me to not have to worry about a lot of details in the regular TX path... Secondly, I want to enable more offloads. So the first thing to do is to actually fix checksum offload - the TI driver has a bug in that if it fails to upload keys or so, checksums will be completely bogus. So the first step to fix that bug is to enable checksum offload only on the fast-xmit path, while having a software fallback on the regular TX path to make software crypto etc. do the right thing. To not cause regressions for the TI/ath10k drivers, this requires extending fast-xmit to cover more cases, but that's easy. Secondly then, we can add code to do in software what the driver might do, which is actually what the network stack does for us anyway today, but now we can do it only on the non-fast-xmit path so that the fast-xmit path can pass packets with required checksumming or segmentation to the device. So far I've only tested the software fallbacks, not the actual hardware offloads. Forgot to say - for those who do want to play with this, this is also available in my mac80211-next tree in the fast-xmit branch. 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: increase number of probes for specific SSID scans
It's been observed that device sometimes fails to find AP
configured in hidden SSID in busy environment. We will increase
number of probes for specific SSID scans for getting better results.
Signed-off-by: Amitkumar Karwar akar...@marvell.com
Signed-off-by: Avinash Patil pat...@marvell.com
---
drivers/net/wireless/mwifiex/cfg80211.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index bf9020f..3783db5 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2269,6 +2269,12 @@ mwifiex_cfg80211_scan(struct wiphy *wiphy,
user_scan_cfg-num_ssids = request-n_ssids;
user_scan_cfg-ssid_list = request-ssids;
+ /* Increase number of probes for specific SSID scans for
+* better results
+*/
+ if (request-n_ssids 1)
+ user_scan_cfg-num_probes = 4;
+
if (request-ie request-ie_len) {
offset = 0;
for (i = 0; i MWIFIEX_MAX_VSIE_NUM; i++) {
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211_hwsim: notify user-space about channel change.
On Tue, 2015-04-14 at 07:56 -0700, Ben Greear wrote: Well, the question isn't really that offloading, the question is what happens with the hw-scan logic in hwsim? Though I guess now that I think about it, that wouldn't show up in userspace at all with your changes. I think for HW scan and related matters, you treat user-space like a firmware target, so you send it a message, and then get some response or action, similar to how you would request ath10k or some USB dongle NIC to do things for you. That's not really how it works today, but it's one possible (probably the only possible) approach. My own interest in hwsim user-space is to make it act more like ath9k than a firmware target driver, but I don't think my changes preclude doing target based emulation in the future. True, although I'd like to see the multi-channel issue addressed better. 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: [RFC] mac80211_hwsim: notify user-space about channel change.
On 04/14/2015 01:13 AM, Johannes Berg wrote: On Tue, 2015-03-31 at 08:56 -0700, Ben Greear wrote: Well, depends. Our driver just asks the firmware to do the scan, and it will do all the scheduling by itself, i.e. it'll go through the channels at convenient times etc. I do not want to offload scanning in user-space, which is the equivalent of what your driver is doing as far as the kernel is concerned? If someone wants to do that in the future, then sure, they can implement such a thing. Well, the question isn't really that offloading, the question is what happens with the hw-scan logic in hwsim? Though I guess now that I think about it, that wouldn't show up in userspace at all with your changes. I think for HW scan and related matters, you treat user-space like a firmware target, so you send it a message, and then get some response or action, similar to how you would request ath10k or some USB dongle NIC to do things for you. My own interest in hwsim user-space is to make it act more like ath9k than a firmware target driver, but I don't think my changes preclude doing target based emulation in the future. Thanks, Ben -- Ben Greear gree...@candelatech.com 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: [RFC] mac80211_hwsim: notify user-space about channel change.
On 04/14/2015 08:06 AM, Johannes Berg wrote: On Tue, 2015-04-14 at 07:56 -0700, Ben Greear wrote: Well, the question isn't really that offloading, the question is what happens with the hw-scan logic in hwsim? Though I guess now that I think about it, that wouldn't show up in userspace at all with your changes. I think for HW scan and related matters, you treat user-space like a firmware target, so you send it a message, and then get some response or action, similar to how you would request ath10k or some USB dongle NIC to do things for you. That's not really how it works today, but it's one possible (probably the only possible) approach. My own interest in hwsim user-space is to make it act more like ath9k than a firmware target driver, but I don't think my changes preclude doing target based emulation in the future. True, although I'd like to see the multi-channel issue addressed better. I need a hint or two on what exactly you want changed in my patch to address your request, or maybe you or someone else can just address the issue in follow-on patches? Thanks, Ben -- Ben Greear gree...@candelatech.com 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] mwifiex: increase number of probes for specific SSID scans
On Tue, 2015-04-14 at 07:49 -0700, Amitkumar Karwar wrote: It's been observed that device sometimes fails to find AP configured in hidden SSID in busy environment. We will increase number of probes for specific SSID scans for getting better results. I question the value of making the busy environment even more busy by sending a lot of probe requests at low rates ... Scans are never really guaranteed to be perfect and complete anyway. This is clearly your choice, but given, among other things, the broader industry direction of moving away from active scanning this seems like a bit short-sighted thing to do. 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
[RFC/RFT 04/11] mac80211: extend fast-xmit for more ciphers
From: Johannes Berg johannes.b...@intel.com
When crypto is offloaded then in some cases it's all handled
by the device, and in others only some space for the IV must
be reserved in the frame. Handle both of these cases in the
fast-xmit path, up to a limit of 18 bytes of space for IVs.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/sta_info.h | 10 +++---
net/mac80211/tx.c | 40 +---
2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index e365f6213702..1d4c73818c54 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -239,6 +239,8 @@ struct sta_ampdu_mlme {
/* Value to indicate no TID reservation */
#define IEEE80211_TID_UNRESERVED 0xff
+#define IEEE80211_FAST_XMIT_MAX_IV 18
+
/**
* struct ieee80211_fast_tx - TX fastpath information
* @key: key to use for hw crypto
@@ -250,15 +252,17 @@ struct sta_ampdu_mlme {
* @band: band this will be transmitted on, for tx_info
* @rcu_head: RCU head to free this struct
*
- * Try to keep this struct small so it fits into a single cacheline.
+ * This struct is small enough so that the common case (maximum crypto
+ * header length of 8 like for CCMP/GCMP) fits into a single 64-byte
+ * cache line.
*/
struct ieee80211_fast_tx {
struct ieee80211_key *key;
- u8 hdr[30 + 2 + IEEE80211_CCMP_HDR_LEN +
- sizeof(rfc1042_header)];
u8 hdr_len;
u8 sa_offs, da_offs, pn_offs;
u8 band;
+ u8 hdr[30 + 2 + IEEE80211_FAST_XMIT_MAX_IV +
+ sizeof(rfc1042_header)];
struct rcu_head rcu_head;
};
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 86d64bd11c01..02aafe1cc121 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2519,10 +2519,11 @@ void ieee80211_check_fast_xmit(struct sta_info *sta,
gfp_t gfp)
if (!build.key)
build.key = rcu_access_pointer(sdata-default_unicast_key);
if (build.key) {
- bool gen_iv, iv_spc;
+ bool gen_iv, iv_spc, mmic;
gen_iv = build.key-conf.flags IEEE80211_KEY_FLAG_GENERATE_IV;
iv_spc = build.key-conf.flags
IEEE80211_KEY_FLAG_PUT_IV_SPACE;
+ mmic = build.key-conf.flags IEEE80211_KEY_FLAG_GENERATE_MMIC;
/* don't handle software crypto */
if (!(build.key-flags KEY_FLAG_UPLOADED_TO_HARDWARE))
@@ -2551,9 +2552,42 @@ void ieee80211_check_fast_xmit(struct sta_info *sta,
gfp_t gfp)
if (gen_iv || iv_spc)
build.hdr_len += IEEE80211_GCMP_HDR_LEN;
break;
- default:
- /* don't do fast-xmit for these ciphers (yet) */
+ case WLAN_CIPHER_SUITE_TKIP:
+ /* cannot handle MMIC or IV generation in xmit-fast */
+ if (mmic || gen_iv)
+ return;
+ if (iv_spc)
+ build.hdr_len += IEEE80211_TKIP_IV_LEN;
+ break;
+ case WLAN_CIPHER_SUITE_WEP40:
+ case WLAN_CIPHER_SUITE_WEP104:
+ /* cannot handle IV generation in fast-xmit */
+ if (gen_iv)
+ return;
+ if (iv_spc)
+ build.hdr_len += IEEE80211_WEP_IV_LEN;
+ break;
+ case WLAN_CIPHER_SUITE_AES_CMAC:
+ case WLAN_CIPHER_SUITE_BIP_CMAC_256:
+ case WLAN_CIPHER_SUITE_BIP_GMAC_128:
+ case WLAN_CIPHER_SUITE_BIP_GMAC_256:
+ WARN(1,
+management cipher suite 0x%x enabled for data\n,
+build.key-conf.cipher);
return;
+ default:
+ /* we don't know how to generate IVs for this at all */
+ if (WARN_ON(gen_iv))
+ return;
+ /* pure hardware keys are OK, of course */
+ if (!(build.key-flags KEY_FLAG_CIPHER_SCHEME))
+ break;
+ /* cipher scheme might require space allocation */
+ if (iv_spc
+ build.key-conf.iv_len IEEE80211_FAST_XMIT_MAX_IV)
+ return;
+ if (iv_spc)
+ build.hdr_len += build.key-conf.iv_len;
}
fc |= cpu_to_le16(IEEE80211_FCTL_PROTECTED);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT 05/11] mac80211: extend fast-xmit to cover IBSS
From: Johannes Berg johannes.b...@intel.com
IBSS can be supported very easily since it uses the standard station
authorization state etc. so it just needs to be covered by the header
building switch statement.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/tx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 02aafe1cc121..0f18ee11f097 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2455,6 +2455,13 @@ void ieee80211_check_fast_xmit(struct sta_info *sta,
gfp_t gfp)
fc = cpu_to_le16(IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA);
switch (sdata-vif.type) {
+ case NL80211_IFTYPE_ADHOC:
+ /* DA SA BSSID */
+ build.da_offs = offsetof(struct ieee80211_hdr, addr1);
+ build.sa_offs = offsetof(struct ieee80211_hdr, addr2);
+ memcpy(hdr-addr3, sdata-u.ibss.bssid, ETH_ALEN);
+ build.hdr_len = 24;
+ break;
case NL80211_IFTYPE_STATION:
if (test_sta_flag(sta, WLAN_STA_TDLS_PEER)) {
/* DA SA BSSID */
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT 03/11] mac80211: extend fast-xmit to driver fragmentation
From: Johannes Berg johannes.b...@intel.com If the driver handles fragmentation then it wouldn't be done in software so we can still use the fast-xmit path in that case. Signed-off-by: Johannes Berg johannes.b...@intel.com --- net/mac80211/tx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index d5bfa6c4afd0..86d64bd11c01 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -2439,7 +2439,8 @@ void ieee80211_check_fast_xmit(struct sta_info *sta, gfp_t gfp) return; /* fast-xmit doesn't handle fragmentation at all */ - if (local-hw.wiphy-frag_threshold != (u32)-1) + if (local-hw.wiphy-frag_threshold != (u32)-1 + !local-ops-set_frag_threshold) return; rcu_read_lock(); -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT 02/11] mac80211_hwsim: enable IEEE80211_HW_SUPPORT_FAST_XMIT
From: Johannes Berg johannes.b...@intel.com For hwsim, the duration field in frames is already not valid for the common case of HT/VHT MCSes, so there's little point in trying to keep it accurate for the legacy rates. Enable the fast-xmit code to allow testing that, although given the dependency on hardware crypto it will only be enabled in open network configurations. Signed-off-by: Johannes Berg johannes.b...@intel.com --- drivers/net/wireless/mac80211_hwsim.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c index d5c0a1af08b9..07626cc21d6e 100644 --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/net/wireless/mac80211_hwsim.c @@ -2399,7 +2399,8 @@ static int mac80211_hwsim_new_radio(struct genl_info *info, IEEE80211_HW_WANT_MONITOR_VIF | IEEE80211_HW_QUEUE_CONTROL | IEEE80211_HW_SUPPORTS_HT_CCK_RATES | - IEEE80211_HW_CHANCTX_STA_CSA; + IEEE80211_HW_CHANCTX_STA_CSA | + IEEE80211_HW_SUPPORT_FAST_XMIT; if (rctbl) hw-flags |= IEEE80211_HW_SUPPORTS_RC_TABLE; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT 01/11] mac80211: add TX fastpath
From: Johannes Berg johannes.b...@intel.com
In order to speed up mac80211's TX path, add the fast-xmit cache
that will cache the data frame 802.11 header and other data to be
able to build the frame more quickly. This cache is rebuilt when
external triggers imply changes, but a lot of the checks done per
packet today are simplified away to the check for the cache.
There's also a more detailed description in the code.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
include/net/mac80211.h | 6 +-
net/mac80211/cfg.c | 9 +-
net/mac80211/chan.c| 6 +
net/mac80211/ieee80211_i.h | 5 +
net/mac80211/key.c | 2 +
net/mac80211/rx.c | 2 +
net/mac80211/sta_info.c| 4 +
net/mac80211/sta_info.h| 27 +++
net/mac80211/tx.c | 404 -
9 files changed, 462 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 38a5fd790366..9001bd685b1e 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1796,6 +1796,10 @@ struct ieee80211_txq {
* the driver returns 1. This also forces the driver to advertise its
* supported cipher suites.
*
+ * @IEEE80211_HW_SUPPORT_FAST_XMIT: The driver/hardware supports fast-xmit,
+ * this currently requires only the ability to calculate the duration
+ * for frames.
+ *
* @IEEE80211_HW_QUEUE_CONTROL: The driver wants to control per-interface
* queue mapping in order to use different queues (not just one per AC)
* for different virtual interfaces. See the doc section on HW queue
@@ -1844,7 +1848,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_WANT_MONITOR_VIF = 114,
IEEE80211_HW_NO_AUTO_VIF= 115,
IEEE80211_HW_SW_CRYPTO_CONTROL = 116,
- /* free slots */
+ IEEE80211_HW_SUPPORT_FAST_XMIT = 117,
IEEE80211_HW_REPORTS_TX_ACK_STATUS = 118,
IEEE80211_HW_CONNECTION_MONITOR = 119,
IEEE80211_HW_QUEUE_CONTROL = 120,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 265e42721a66..4aa5e893cbaa 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -137,6 +137,9 @@ static int ieee80211_set_noack_map(struct wiphy *wiphy,
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
sdata-noack_map = noack_map;
+
+ ieee80211_check_fast_xmit_iface(sdata);
+
return 0;
}
@@ -2099,10 +2102,14 @@ static int ieee80211_set_wiphy_params(struct wiphy
*wiphy, u32 changed)
int err;
if (changed WIPHY_PARAM_FRAG_THRESHOLD) {
+ ieee80211_check_fast_xmit_all(local);
+
err = drv_set_frag_threshold(local, wiphy-frag_threshold);
- if (err)
+ if (err) {
+ ieee80211_check_fast_xmit_all(local);
return err;
+ }
}
if ((changed WIPHY_PARAM_COVERAGE_CLASS) ||
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 5bcd4e5589d3..7e9b62475400 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -664,6 +664,8 @@ out:
ieee80211_bss_info_change_notify(sdata,
BSS_CHANGED_IDLE);
+ ieee80211_check_fast_xmit_iface(sdata);
+
return ret;
}
@@ -1030,6 +1032,8 @@ ieee80211_vif_use_reserved_reassign(struct
ieee80211_sub_if_data *sdata)
if (sdata-vif.type == NL80211_IFTYPE_AP)
__ieee80211_vif_copy_chanctx_to_vlans(sdata, false);
+ ieee80211_check_fast_xmit_iface(sdata);
+
if (ieee80211_chanctx_refcount(local, old_ctx) == 0)
ieee80211_free_chanctx(local, old_ctx);
@@ -1376,6 +1380,8 @@ static int ieee80211_vif_use_reserved_switch(struct
ieee80211_local *local)
__ieee80211_vif_copy_chanctx_to_vlans(sdata,
false);
+ ieee80211_check_fast_xmit_iface(sdata);
+
sdata-radar_required = sdata-reserved_radar_required;
if (sdata-vif.bss_conf.chandef.width !=
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index ab46ab4a7249..09a15a855c5a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1651,6 +1651,11 @@ struct sk_buff *
ieee80211_build_data_template(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb, u32 info_flags);
+void ieee80211_check_fast_xmit(struct sta_info *sta, gfp_t gfp);
+void ieee80211_check_fast_xmit_all(struct ieee80211_local *local);
+void ieee80211_check_fast_xmit_iface(struct ieee80211_sub_if_data *sdata);
+void ieee80211_clear_fast_xmit(struct sta_info *sta);
+
/* HT */
void ieee80211_apply_htcap_overrides(struct
[RFC/RFT 00/11] mac80211: enable fast-xmit and some offloads
First, add the TX fastpath (fast-xmit) that I've been kicking around for a while. I'm pretty happy with the abstraction since it allows me to not have to worry about a lot of details in the regular TX path... Secondly, I want to enable more offloads. So the first thing to do is to actually fix checksum offload - the TI driver has a bug in that if it fails to upload keys or so, checksums will be completely bogus. So the first step to fix that bug is to enable checksum offload only on the fast-xmit path, while having a software fallback on the regular TX path to make software crypto etc. do the right thing. To not cause regressions for the TI/ath10k drivers, this requires extending fast-xmit to cover more cases, but that's easy. Secondly then, we can add code to do in software what the driver might do, which is actually what the network stack does for us anyway today, but now we can do it only on the non-fast-xmit path so that the fast-xmit path can pass packets with required checksumming or segmentation to the device. So far I've only tested the software fallbacks, not the actual hardware offloads. 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
Set wireless channel busy
Hello, I am developing a module which adds the support for IEEE 1609.4 for WAVE(Wireless Access for vehicular environments) in mac80211. One of the specifications of 1609.4 is channel access in alternate fashion, i.e. I need to switch between two channels alternatively, giving 50ms to each of the channel. For the switching, the document suggests a guard band of 4ms, where in which I need to make sure that no transmissions are taking place during the guard band. Now my question is: How do I suspend the transmissions(although, the packets could be queued and the reception could remain on) of a wlan device for a certain amount of time? Thanks and Regards, Raghavendra --- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- -- 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: [RFC 2/2] ath10k: don't disable PS when not connected
On 15 April 2015 at 00:45, YanBo dreamfly...@gmail.com wrote:
On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
Don't disable PS while we are not connected.
In other case we will get higher power consumption.
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 52c5b1f..b896dd4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif
*arvif)
enable_ps = false;
}
- if (enable_ps) {
+ if (!arvif-is_started) {
+ /* enable power save mode while not connected,
+* in other case after iface up we will get
+* higher power consumption - firmware design
+*/
+ psmode = WMI_STA_PS_MODE_ENABLED;
+ } else if (enable_ps) {
psmode = WMI_STA_PS_MODE_ENABLED;
param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
--
What the expectation behavior after we enable the
WMI_STA_PS_MODE_ENABLED at Idle status?
Is there any effect for TX or RX chain after set it?
First I think that WMI_STA_PS_MODE_ENABLED is important only when we
are connected.
But, I see current consumption drop in my test environtment from 88mA
to 33mA when:
1) load driver, iface up
2) disconnect network, iface down, iface up
So, seems WMI_STA_PS_MODE_ENABLED do something more in FW (not only
standard PS enable/disable when
connected to AP). Probably someone from FW team should answer that, if
that is a feature or a bug.
BTW.
Patch don't change behavior we had before, when we are connected. We
can enable/disable PS using iw.
BR
Janusz
--
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: increase number of probes for specific SSID scans
On Tue, Apr 14, 2015 at 07:49:16AM -0700, Amitkumar Karwar wrote: It's been observed that device sometimes fails to find AP configured in hidden SSID in busy environment. We will increase number of probes for specific SSID scans for getting better results. I don't like this. It worries me. What is the underlying cause? If it is something other than collision, why? In scenario of tens to a hundred laptops scanning for specific SSID for ad-hoc in the Sugar desktop environment, this patch may decrease free air time considerably. Should the number of probes be a choice of user space? -- James Cameron http://quozl.linux.org.au/ -- 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: [RFC 2/2] ath10k: don't disable PS when not connected
On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
Don't disable PS while we are not connected.
In other case we will get higher power consumption.
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 52c5b1f..b896dd4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif
*arvif)
enable_ps = false;
}
- if (enable_ps) {
+ if (!arvif-is_started) {
+ /* enable power save mode while not connected,
+* in other case after iface up we will get
+* higher power consumption - firmware design
+*/
+ psmode = WMI_STA_PS_MODE_ENABLED;
+ } else if (enable_ps) {
psmode = WMI_STA_PS_MODE_ENABLED;
param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
--
What the expectation behavior after we enable the
WMI_STA_PS_MODE_ENABLED at Idle status?
Is there any effect for TX or RX chain after set it?
BR /Yanbo
--
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
Connecting
Connecting GNUnet with Openwrt Is this the right place to forward this email? Kind regards Demos Weitergeleitete Nachricht Betreff: Re: [GNUnet-developers] EDN Datum: Tue, 14 Apr 2015 22:33:50 +0200 Von: Christian Grothoff groth...@gnunet.org An: demos de...@posteo.de, gnunet-develop...@gnu.org On 04/14/15 21:55, demos wrote: Concerning the support of openwrt: What do you think about the idea of crosschecking certain parts of code for bugs (those parts that directly interact with one another?) together with the Openwrt-developers. (I haven't asked them yet. Maybe it's better if you ask them directly?) Well, our code largely just calls the TUN/TAP APIs of the Kernel right now, so I don't know where we'd there touch with OpenWRT-logic. In my opinion this would be a win-win situation for both, because you both have experienced C developers. They get their code reviewed, you get your code reviewed. I'm not sure this is terribly realistic: it takes quite some time to be familiar with the codebase (and you can't review code without understanding what it is supposed to do). That knowledge doesn't translate to a different project easily, you have the initial steep learning curve each time. So it doesn't quite sound like a win-win. However, if the OpenWRT folks are interested in helping Bart ( Florian) get GNUnet onto the WRT platform, that would be great and might be an actual win-win (we gain a platform, they a capability). Happy hacking! Christian 0xBF83D308.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[PATCH 05/10] brcmfmac: add support for BCM4324 rev B5 chipset
This patch adds support for the BCM4324 B5 revision. This device
is similar to BCM43241 from driver and firmware perspective. It
is known to be used in Lenovo Thinkpad Tablet devices.
Reviewed-by: Hante Meuleman meule...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index ab0c898..cbdda54 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -601,6 +601,8 @@ static const struct sdiod_drive_str sdiod_drvstr_tab2_3v3[]
= {
#define BCM43241B0_NVRAM_NAME brcm/brcmfmac43241b0-sdio.txt
#define BCM43241B4_FIRMWARE_NAME brcm/brcmfmac43241b4-sdio.bin
#define BCM43241B4_NVRAM_NAME brcm/brcmfmac43241b4-sdio.txt
+#define BCM43241B5_FIRMWARE_NAME brcm/brcmfmac43241b5-sdio.bin
+#define BCM43241B5_NVRAM_NAME brcm/brcmfmac43241b5-sdio.txt
#define BCM4329_FIRMWARE_NAME brcm/brcmfmac4329-sdio.bin
#define BCM4329_NVRAM_NAME brcm/brcmfmac4329-sdio.txt
#define BCM4330_FIRMWARE_NAME brcm/brcmfmac4330-sdio.bin
@@ -628,6 +630,8 @@ MODULE_FIRMWARE(BCM43241B0_FIRMWARE_NAME);
MODULE_FIRMWARE(BCM43241B0_NVRAM_NAME);
MODULE_FIRMWARE(BCM43241B4_FIRMWARE_NAME);
MODULE_FIRMWARE(BCM43241B4_NVRAM_NAME);
+MODULE_FIRMWARE(BCM43241B5_FIRMWARE_NAME);
+MODULE_FIRMWARE(BCM43241B5_NVRAM_NAME);
MODULE_FIRMWARE(BCM4329_FIRMWARE_NAME);
MODULE_FIRMWARE(BCM4329_NVRAM_NAME);
MODULE_FIRMWARE(BCM4330_FIRMWARE_NAME);
@@ -667,7 +671,8 @@ enum brcmf_firmware_type {
static const struct brcmf_firmware_names brcmf_fwname_data[] = {
{ BRCM_CC_43143_CHIP_ID, 0x, BRCMF_FIRMWARE_NVRAM(BCM43143) },
{ BRCM_CC_43241_CHIP_ID, 0x001F, BRCMF_FIRMWARE_NVRAM(BCM43241B0) },
- { BRCM_CC_43241_CHIP_ID, 0xFFE0, BRCMF_FIRMWARE_NVRAM(BCM43241B4) },
+ { BRCM_CC_43241_CHIP_ID, 0x0020, BRCMF_FIRMWARE_NVRAM(BCM43241B4) },
+ { BRCM_CC_43241_CHIP_ID, 0xFFC0, BRCMF_FIRMWARE_NVRAM(BCM43241B5) },
{ BRCM_CC_4329_CHIP_ID, 0x, BRCMF_FIRMWARE_NVRAM(BCM4329) },
{ BRCM_CC_4330_CHIP_ID, 0x, BRCMF_FIRMWARE_NVRAM(BCM4330) },
{ BRCM_CC_4334_CHIP_ID, 0x, BRCMF_FIRMWARE_NVRAM(BCM4334) },
--
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
