[PATCH] mwifiex: add device specific ioctl handler
From: Xinming Hu
Add net_dev ndo_do_ioctl handler, which could be used for
downloading host command by utility in manufactory test
Signed-off-by: Xinming Hu
Signed-off-by: Cathy Luo
Signed-off-by: Ganapathi Bhat
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++
drivers/net/wireless/marvell/mwifiex/main.c | 23 +++
drivers/net/wireless/marvell/mwifiex/main.h | 7 +++-
3 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 0edc5d6..86ee399 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -839,6 +839,8 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
hostcmd = adapter->curr_cmd->data_buf;
hostcmd->len = size;
memcpy(hostcmd->cmd, resp, size);
+ adapter->hostcmd_resp_data.len = size;
+ memcpy(adapter->hostcmd_resp_data.cmd, resp, size);
}
}
orig_cmdresp_no = le16_to_cpu(resp->command);
@@ -1221,6 +1223,63 @@ int mwifiex_ret_802_11_hs_cfg(struct mwifiex_private
*priv,
}
EXPORT_SYMBOL_GPL(mwifiex_process_hs_config);
+/* This function get hostcmd data from userspace and construct a cmd
+ * to be download to FW.
+ */
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+struct ifreq *req)
+{
+ struct mwifiex_ds_misc_cmd *hostcmd_buf;
+ struct host_cmd_ds_command *cmd;
+ struct mwifiex_adapter *adapter = priv->adapter;
+ int ret;
+
+ hostcmd_buf = kzalloc(sizeof(*hostcmd_buf), GFP_KERNEL);
+ if (!hostcmd_buf)
+ return -ENOMEM;
+
+ cmd = (void *)hostcmd_buf->cmd;
+
+ if (copy_from_user(cmd, req->ifr_data,
+ sizeof(cmd->command) + sizeof(cmd->size))) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ hostcmd_buf->len = le16_to_cpu(cmd->size);
+ if (hostcmd_buf->len > MWIFIEX_SIZE_OF_CMD_BUFFER) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ if (copy_from_user(cmd, req->ifr_data, hostcmd_buf->len)) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (mwifiex_send_cmd(priv, 0, 0, 0, hostcmd_buf, true)) {
+ dev_err(priv->adapter->dev, "Failed to process hostcmd\n");
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (adapter->hostcmd_resp_data.len > hostcmd_buf->len) {
+ ret = -EFBIG;
+ goto done;
+ }
+
+ if (copy_to_user(req->ifr_data, adapter->hostcmd_resp_data.cmd,
+adapter->hostcmd_resp_data.len)) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ ret = 0;
+done:
+ kfree(hostcmd_buf);
+ return ret;
+}
+
/*
* This function handles the command response of a sleep confirm command.
*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c
b/drivers/net/wireless/marvell/mwifiex/main.c
index ee40b73..3e7700f 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1265,12 +1265,35 @@ static struct net_device_stats
*mwifiex_get_stats(struct net_device *dev)
return mwifiex_1d_to_wmm_queue[skb->priority];
}
+static int mwifiex_do_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
+{
+ struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+ int ret;
+
+ if (!priv->adapter->mfg_mode)
+ return -EINVAL;
+
+ mwifiex_dbg(priv->adapter, "ioctl cmd = 0x%x\n", cmd);
+
+ switch (cmd) {
+ case MWIFIEX_HOSTCMD_IOCTL:
+ ret = mwifiex_process_host_command(priv, req);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
/* Network device handlers */
static const struct net_device_ops mwifiex_netdev_ops = {
.ndo_open = mwifiex_open,
.ndo_stop = mwifiex_close,
.ndo_start_xmit = mwifiex_hard_start_xmit,
.ndo_set_mac_address = mwifiex_ndo_set_mac_address,
+ .ndo_do_ioctl = mwifiex_do_ioctl,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = mwifiex_tx_timeout,
.ndo_get_stats = mwifiex_get_stats,
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h
b/drivers/net/wireless/marvell/mwifiex/main.h
index a76bd79..4639f49 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -160,6 +160,9 @@ enum {
/* Threshold for tx_timeout_cnt before we trigger a card reset */
#define TX_TIMEOUT_THRESHOLD 6
+/* IOCTL number used for hostcmd process*/
+#define MWIFIEX_HOSTCMD_IOCTL (SIOCDEVPRIVATE + 1)
+
#define MWIFIEX_DRV_INFO_SIZE_MAX 0x4
Re: [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps
Hi Kalle, On Wed, Sep 20, 2017 at 07:30:29AM +0300, Kalle Valo wrote: > Brian Norris writes: > > > Hi Ganapathi, > > > > On Thu, Sep 14, 2017 at 02:14:24PM +, Ganapathi Bhat wrote: > >> > On Thu, 2017-08-31 at 01:21 +0530, Ganapathi Bhat wrote: > >> > Why not use a ratelimit? > >> Since this is for receive, the packets are from AP side and we cannot > >> lower the rate from AP. On some low performance systems this change > >> will be helpful. > > > > I think Joe was referring to things like printk_ratelimited() or > > dev_err_ratelimited(). Those automatically ratelimit prints for you, > > using a static counter. You'd just need to make a small warpper for > > mwifiex_dbg() using __ratelimit(). > > > > Those sort of rate limits are significantly different than yours though. > > You were looking to avoid printing errors when there are only a few > > failures in a row, whereas the existing rate-limiting infrastructure > > looks to avoid printing errors if too many happen in a row. Those are > > different goals. > > Are you saying that this patch is good to take? Or should Ganapathi > submit v2? If you're asking me... All I was saying was that I don't think Joe's suggestion will help Ganapathi. I'd expect Ganapathi could confirm/deny that part. (Or Joe could correct me if my interpretation is wrong.) I'm also not familiar with how we expect dev_alloc_skb() failures to be handled. If that's a common expected failure mode in low-memory situations (seems reasonable?) and the driver handles these failure just fine (completely unreviewed by me, so far; I suspect it doesn't do this completely correctly), then sure, being less noisy about it as done in this patch should be fine. IOW, I don't have concrete feedback for Ganapathi to address, but I'm not exactly "ack"ing it myself. Brian
Re: [for-4.14, 1/2] brcmfmac: add length check in brcmf_cfg80211_escan_handler()
Arend Van Spriel wrote: > Upon handling the firmware notification for scans the length was > checked properly and may result in corrupting kernel heap memory > due to buffer overruns. This fix addresses CVE-2017-0786. > > Cc: sta...@vger.kernel.org # v4.0.x > Cc: Kevin Cernekee > Reviewed-by: Hante Meuleman > Reviewed-by: Pieter-Paul Giesberts > Reviewed-by: Franky Lin > Signed-off-by: Arend van Spriel 2 patches applied to wireless-drivers.git, thanks. 17df6453d4be brcmfmac: add length check in brcmf_cfg80211_escan_handler() 35f62727df0e brcmfmac: setup passive scan if requested by user-space -- https://patchwork.kernel.org/patch/9948689/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps
Brian Norris writes:
> Hi Ganapathi,
>
> On Thu, Sep 14, 2017 at 02:14:24PM +, Ganapathi Bhat wrote:
>> > On Thu, 2017-08-31 at 01:21 +0530, Ganapathi Bhat wrote:
>> > > @@ -300,9 +300,16 @@ static int mwifiex_usb_submit_rx_urb(struct
>> > urb_context *ctx, int size)
>> > > if (card->rx_cmd_ep != ctx->ep) {
>> > > ctx->skb = dev_alloc_skb(size);
>> > > if (!ctx->skb) {
>> > > -mwifiex_dbg(adapter, ERROR,
>> > > -"%s: dev_alloc_skb failed\n",
>> > > __func__);
>> > > +if (++card->rx_urb_failure_count >
>> > > +MWIFIEX_RX_URB_FAILURE_THRESHOLD) {
>> > > +mwifiex_dbg(adapter, ERROR,
>> > > +"%s: dev_alloc_skb failed,
>> > > failure
>> > count = %u\n",
>> > > +__func__,
>> > > +card->rx_urb_failure_count);
>> > > +}
>> > > return -ENOMEM;
>> >
>> > Why not use a ratelimit?
>> Since this is for receive, the packets are from AP side and we cannot
>> lower the rate from AP. On some low performance systems this change
>> will be helpful.
>
> I think Joe was referring to things like printk_ratelimited() or
> dev_err_ratelimited(). Those automatically ratelimit prints for you,
> using a static counter. You'd just need to make a small warpper for
> mwifiex_dbg() using __ratelimit().
>
> Those sort of rate limits are significantly different than yours though.
> You were looking to avoid printing errors when there are only a few
> failures in a row, whereas the existing rate-limiting infrastructure
> looks to avoid printing errors if too many happen in a row. Those are
> different goals.
Are you saying that this patch is good to take? Or should Ganapathi
submit v2?
--
Kalle Valo
[PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled
For devices where the FW supports WoWLAN but user-space has not
configured it, we don't do any PCI-specific suspend/resume operations,
because mac80211 doesn't call drv_suspend() when !wowlan. This has
particularly bad effects for some platforms, because we don't stop the
power-save timer, and if this timer goes off after the PCI controller
has suspended the link, Bad Things will happen.
Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
got some of this right, in that it understood there was a problem on
non-WoWLAN firmware. But it forgot the $subject case.
Fix this by moving all the PCI driver suspend/resume logic exclusively
into the driver PM hooks. This shouldn't affect WoWLAN support much
(this just gets executed later on).
I would just as well kill the entirety of ath10k_hif_suspend(), as it's
not even implemented on the USB or SDIO drivers. I expect that we don't
need the callback, except to return "supported" (i.e., 0) or "not
supported" (i.e., -EOPNOTSUPP).
Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
Signed-off-by: Brian Norris
Cc: Ryan Hsu
Cc: Kalle Valo
Cc: Michal Kazior
---
drivers/net/wireless/ath/ath10k/pci.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index bc1633945a56..4655c944e3fd 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2580,6 +2580,12 @@ void ath10k_pci_hif_power_down(struct ath10k *ar)
#ifdef CONFIG_PM
static int ath10k_pci_hif_suspend(struct ath10k *ar)
+{
+ /* Nothing to do; the important stuff is in the driver suspend. */
+ return 0;
+}
+
+static int ath10k_pci_suspend(struct ath10k *ar)
{
/* The grace timer can still be counting down and ar->ps_awake be true.
* It is known that the device may be asleep after resuming regardless
@@ -2592,6 +2598,12 @@ static int ath10k_pci_hif_suspend(struct ath10k *ar)
}
static int ath10k_pci_hif_resume(struct ath10k *ar)
+{
+ /* Nothing to do; the important stuff is in the driver resume. */
+ return 0;
+}
+
+static int ath10k_pci_resume(struct ath10k *ar)
{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
struct pci_dev *pdev = ar_pci->pdev;
@@ -3403,11 +3415,7 @@ static int ath10k_pci_pm_suspend(struct device *dev)
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
-ar->running_fw->fw_file.fw_features))
- return 0;
-
- ret = ath10k_hif_suspend(ar);
+ ret = ath10k_pci_suspend(ar);
if (ret)
ath10k_warn(ar, "failed to suspend hif: %d\n", ret);
@@ -3419,11 +3427,7 @@ static int ath10k_pci_pm_resume(struct device *dev)
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
-ar->running_fw->fw_file.fw_features))
- return 0;
-
- ret = ath10k_hif_resume(ar);
+ ret = ath10k_pci_resume(ar);
if (ret)
ath10k_warn(ar, "failed to resume hif: %d\n", ret);
--
2.14.1.690.gbb1197296e-goog
[PATCH] mwifiex: make const array tos_to_ac static, reduces object code size
From: Colin Ian King
Don't populate the read-only const array tos_to_ac on the stack,
instead make it static. Makes the object code smaller by 250 bytes:
Before:
textdata bss dec hex filename
261042720 128 289527118 wmm.o
After:
textdata bss dec hex filename
257582816 128 28702701e wmm.o
Signed-off-by: Colin Ian King
---
drivers/net/wireless/marvell/mwifiex/wmm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c
b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 0edd26881321..936a0a841af8 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -359,7 +359,8 @@ static enum mwifiex_wmm_ac_e
mwifiex_wmm_convert_tos_to_ac(struct mwifiex_adapter *adapter, u32 tos)
{
/* Map of TOS UP values to WMM AC */
- const enum mwifiex_wmm_ac_e tos_to_ac[] = { WMM_AC_BE,
+ static const enum mwifiex_wmm_ac_e tos_to_ac[] = {
+ WMM_AC_BE,
WMM_AC_BK,
WMM_AC_BK,
WMM_AC_BE,
--
2.14.1
[PATCH] ath9k: make const array reg_hole_list static, reduces object code size
From: Colin Ian King
Don't populate the read-only array reg_hole_list on the stack, instead make
it static. Makes the object code smaller by over 200 bytes:
Before:
textdata bss dec hex filename
57518 15248 0 72766 11c3e debug.o
After:
textdata bss dec hex filename
57218 15344 0 72562 11b72 debug.o
Signed-off-by: Colin Ian King
---
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index 01fa30117288..5a0a05abd51a 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -916,7 +916,7 @@ static int open_file_regdump(struct inode *inode, struct
file *file)
u8 *buf;
int i, j = 0;
unsigned long num_regs, regdump_len, max_reg_offset;
- const struct reg_hole {
+ static const struct reg_hole {
u32 start;
u32 end;
} reg_hole_list[] = {
--
2.14.1
Re: pull-request: mac80211 2017-11-19
From: Johannes Berg Date: Tue, 19 Sep 2017 09:20:47 +0200 > Here's a new set of two small changes to prevent null pointer > dereferences on malformed netlink messages. > > Please pull and let me know if there's any problem. Pulled, thank you.
Re: [PATCH 2/2] mwifiex: use get_random_mask_addr() helper
Hi, On Tue, Sep 19, 2017 at 05:30:06PM +0300, Kalle Valo wrote: > Ganapathi Bhat writes: > > > Hi Kalle, > >> > >> > Avoid calculating random MAC address in driver. Instead make use of > >> > 'get_random_mask_addr()' function. > >> > > >> > Signed-off-by: Ganapathi Bhat > >> > >> I don't see 1/2 anywhere. Did it get lost? > > > > Actually there is no 1/2. What I did is: 'git send-email'; CTRL + C It's dependent on this patch though, which kinda should be '1/2': [PATCH] mwifiex: avoid storing random_mac in private > > (to correct a typo); and then tried sending it again. I think that > > created some problem here. Kindly let me know how to proceed. > > Ok. I'll wait for review comments and if all goes well I'll apply it in > few days. FWIW, this looks OK to me: Reviewed-by: Brian Norris It's just a bit strange that we have to keep our own on-stack temporary buffer for this. Maybe this could use an in-place helper too? Or (if it's really legal for us to modify the cfg80211_scan_request in-place) why doesn't the upper-layer nl80211 code do the randomization for us? Many (all?) drivers I see implementing randomization have to do this anyway; they don't use request->mac_addr directly. (Or I suppose some firmware could implement the randomization on its own someday...but would we really trust it?) Brian
Re: [PATCH] mac80211_hwsim: enabling WDS
Hi, > I'm developing an wireless emulator > (https://github.com/intrig-unicamp/mininet-wifi) which relies on > mac80211_hwsim for loading virtual wireless interfaces. In order to > get access points wirelessly connected I was think to enable WDS (in > addition to the well known mesh mode). Why would you want to have WDS? IMHO if you really want to do it over wifi it makes more sense to use 4-addr AP/client. That at least gives you a reasonable configuration one might use in the real world - WDS can't negotiate HT/VHT for example, making it pretty much useless these days. > Then, I went through mac80211_hwsim and I noticed that I could make > it work with BIT(NL80211_IFTYPE_WDS) in mac80211_hwsim. That said, I > thought to submit this patch. > > ps. I'm not an expert in Linux Kernel and I don't know if something > else have to be done. It just worked applying this patch. It may work in hwsim, but I don't really want to encourage such usage. I'd even argue that we should just remove support for this from the kernel entirely, but that will probably not happen. johannes
Re: [PATCH] rsi: sdio suspend and resume support
Amitkumar Karwar writes:
> From: Karun Eagalapati
>
> SDIO suspend and resume handlers are implemented and verified
> that device works after suspend/resume cycle.
>
> Signed-off-by: Karun Eagalapati
> Signed-off-by: Amitkumar Karwar
[...]
> +static int rsi_sdio_disable_interrupts(struct sdio_func *pfunc)
> +{
> + struct rsi_hw *adapter = sdio_get_drvdata(pfunc);
> + u8 isr_status = 0, data = 0;
> + int ret;
> +
> + rsi_dbg(INFO_ZONE, "Waiting for interrupts to be cleared..");
> + do {
> + rsi_sdio_read_register(adapter, RSI_FN1_INT_REGISTER,
> +&isr_status);
> + rsi_dbg(INFO_ZONE, ".");
> + } while (isr_status);
Never ending loops in kernel are always a bad idea, better to add a
reasonable timeout if/when something goes wrong.
--
Kalle Valo
Re: [PATCH] rsi: add driver and firmware version info
Amitkumar Karwar writes:
> From: Pavani Muthyala
>
> We will dump information about driver and firmware versions,
> firmware file name and operating mode during initialization.
>
> Signed-off-by: Pavani Muthyala
> Signed-off-by: Amitkumar Karwar
[...]
> +void rsi_print_version(struct rsi_common *common)
> +{
> + memcpy(common->driver_ver, DRV_VER, ARRAY_SIZE(DRV_VER));
> + common->driver_ver[ARRAY_SIZE(DRV_VER)] = '\0';
> +
> + rsi_dbg(ERR_ZONE, "\n");
> + rsi_dbg(ERR_ZONE, " RSI Version Info ==\n");
> + rsi_dbg(ERR_ZONE, "\n");
> + rsi_dbg(ERR_ZONE, "FW Version\t: %d.%d.%d\n",
> + common->lmac_ver.major, common->lmac_ver.minor,
> + common->lmac_ver.release_num);
> + rsi_dbg(ERR_ZONE, "Driver Version\t: %s", common->driver_ver);
> + rsi_dbg(ERR_ZONE, "Operating mode\t: %d [%s]",
> + common->oper_mode, opmode_str(common->oper_mode));
> + rsi_dbg(ERR_ZONE, "Firmware file\t: %s", common->priv->fw_file_name);
> + rsi_dbg(ERR_ZONE, "\n");
> +}
> +
[...]
> +#define DRV_VER "RS911X.NB0.NL.GNU.LNX.1.0"
The concept of a driver version does not really work with upstream
drivers. The history has shown multiple times that the driver version
won't be updated for years and thus it won't have any meaning. So better
remove driver_ver from the driver entirely.
--
Kalle Valo
Re: [PATCH 2/2] mwifiex: use get_random_mask_addr() helper
Ganapathi Bhat writes: > Hi Kalle, >> >> > Avoid calculating random MAC address in driver. Instead make use of >> > 'get_random_mask_addr()' function. >> > >> > Signed-off-by: Ganapathi Bhat >> >> I don't see 1/2 anywhere. Did it get lost? > > Actually there is no 1/2. What I did is: 'git send-email'; CTRL + C > (to correct a typo); and then tried sending it again. I think that > created some problem here. Kindly let me know how to proceed. Ok. I'll wait for review comments and if all goes well I'll apply it in few days. -- Kalle Valo
[PATCH] nfc: s3fwrn5: make array match static const, reduces object code size
From: Colin Ian King
Don't populate the read-only array match on the stack, instead make
it static const. Makes the object code smaller by over 310 bytes:
Before:
textdata bss dec hex filename
83041084 1289516252c drivers/nfc/s3fwrn5/firmware.o
After:
textdata bss dec hex filename
78941180 128920223f2 drivers/nfc/s3fwrn5/firmware.o
Signed-off-by: Colin Ian King
---
drivers/nfc/s3fwrn5/firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/s3fwrn5/firmware.c b/drivers/nfc/s3fwrn5/firmware.c
index 38548bd970cd..b7828fb252f2 100644
--- a/drivers/nfc/s3fwrn5/firmware.c
+++ b/drivers/nfc/s3fwrn5/firmware.c
@@ -336,7 +336,7 @@ static int s3fwrn5_fw_get_base_addr(
struct s3fwrn5_fw_cmd_get_bootinfo_rsp *bootinfo, u32 *base_addr)
{
int i;
- struct {
+ static const struct {
u8 version[4];
u32 base_addr;
} match[] = {
--
2.14.1
Re: [PATCH 1/2] mac80211: Add rcu read side critical sections
On Mon, Sep 18, 2017 at 10:11:17PM +0200, Johannes Berg wrote: > > I got the following lockdep warning about the rcu_dereference()s in > > ieee80211_tx_h_select_key(). After tracing all callers of > > ieee80211_tx_h_select_key() I discovered that > > ieee80211_get_buffered_bc() > > and ieee80211_build_data_template() had the rcu_read_lock/unlock() > > but > > three other places did not. So I just blindly added them and made the > > read side critical section extend as far as the lifetime of 'tx' > > which > > is where we seem to be stuffing the rcu protected pointers. No real > > clue whether this is correct or not. > > Heh. > > I think we should do it in ieee80211_tx_dequeue(), Oh, I guess I didn't trace the call chains far enough. ieee80211_tx() does indeed look OK. But unless I made another mistake in my analysis ieee80211_tx_prepare_skb() is still busted. > if not even in the > driver (and document that it's required) > > johannes > > > @@ -3411,6 +3430,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct > > ieee80211_hw *hw, > > ieee80211_tx_result r; > > struct ieee80211_vif *vif; > > > > + rcu_read_lock(); > > + > > spin_lock_bh(&fq->lock); > > > > if (test_bit(IEEE80211_TXQ_STOP, &txqi->flags)) > > @@ -3513,6 +3534,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct > > ieee80211_hw *hw, > > out: > > spin_unlock_bh(&fq->lock); > > > > + rcu_read_unlock(); > > > > i.e. this in itself should be sufficient, though you should probably > reorder and acquire the spinlock first since that might spin, and you > want to keep the RCU section minimal (it's trivial here, after all) Good point. I'll respin with that change. -- Ville Syrjälä Intel OTC
[PATCH] wcn36xx: Disable 5GHz for wcn3620
wcn3620 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3620 id.
Signed-off-by: Loic Poulain
---
drivers/net/wireless/ath/wcn36xx/main.c| 12 +++-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 6 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index a9220b4..c3bc248 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1089,7 +1089,8 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
BIT(NL80211_IFTYPE_MESH_POINT);
wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = &wcn_band_2ghz;
- wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = &wcn_band_5ghz;
+ if (wcn->rf_id != RF_IRIS_WCN3620)
+ wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = &wcn_band_5ghz;
wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
wcn->hw->wiphy->max_scan_ie_len = WCN36XX_MAX_SCAN_IE_LEN;
@@ -1119,6 +1120,7 @@ static int wcn36xx_platform_get_resources(struct wcn36xx
*wcn,
struct platform_device *pdev)
{
struct device_node *mmio_node;
+ struct device_node *iris_node;
struct resource *res;
int index;
int ret;
@@ -1181,6 +1183,14 @@ static int wcn36xx_platform_get_resources(struct wcn36xx
*wcn,
goto unmap_ccu;
}
+ /* External RF module */
+ iris_node = of_find_node_by_name(mmio_node, "iris");
+ if (iris_node) {
+ if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
+ wcn->rf_id = RF_IRIS_WCN3620;
+ of_node_put(iris_node);
+ }
+
of_node_put(mmio_node);
return 0;
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index b52b4da9..0643477 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -94,6 +94,9 @@ enum wcn36xx_ampdu_state {
#define WCN36XX_FLAGS(__wcn) (__wcn->hw->flags)
#define WCN36XX_MAX_POWER(__wcn) (__wcn->hw->conf.chandef.chan->max_power)
+#define RF_UNKNOWN 0x
+#define RF_IRIS_WCN36200x3620
+
static inline void buff_to_be(u32 *buf, size_t len)
{
int i;
@@ -238,6 +241,9 @@ struct wcn36xx {
struct sk_buff *tx_ack_skb;
+ /* RF module */
+ unsignedrf_id;
+
#ifdef CONFIG_WCN36XX_DEBUGFS
/* Debug file system entry */
struct wcn36xx_dfs_entrydfs;
--
2.7.4
[PATCH] mac80211_hwsim: enabling WDS
Hi,
I'm developing an wireless emulator
(https://github.com/intrig-unicamp/mininet-wifi) which relies on
mac80211_hwsim for loading virtual wireless interfaces. In order to
get access points wirelessly connected I was think to enable WDS (in
addition to the well known mesh mode).
Then, I went through mac80211_hwsim and I noticed that I could make it
work with BIT(NL80211_IFTYPE_WDS) in mac80211_hwsim. That said, I
thought to submit this patch.
ps. I'm not an expert in Linux Kernel and I don't know if something
else have to be done. It just worked applying this patch.
---
drivers/net/wireless/mac80211_hwsim.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 6467ffac9811e..1f8229e545190 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -453,6 +453,7 @@ static const struct ieee80211_iface_limit
hwsim_if_limits[] = {
BIT(NL80211_IFTYPE_MESH_POINT) |
#endif
BIT(NL80211_IFTYPE_AP) |
+BIT(NL80211_IFTYPE_WDS) |
BIT(NL80211_IFTYPE_P2P_GO) },
/* must be last, see hwsim_if_comb */
{ .max = 1, .types = BIT(NL80211_IFTYPE_P2P_DEVICE) }
@@ -2562,6 +2563,7 @@ static int mac80211_hwsim_new_radio(struct
genl_info *info,
hw->offchannel_tx_hw_queue = 4;
hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_AP) |
+BIT(NL80211_IFTYPE_WDS) |
BIT(NL80211_IFTYPE_P2P_CLIENT) |
BIT(NL80211_IFTYPE_P2P_GO) |
BIT(NL80211_IFTYPE_ADHOC) |
Re: [TDLS PATCH V3 1/5] mac80211: Enable TDLS peer buffer STA feature
On 19-09-17 10:15, Johannes Berg wrote:
On Tue, 2017-09-19 at 09:56 +0200, Arend van Spriel wrote:
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3249,6 +3249,8 @@ struct cfg80211_ops {
* beaconing mode (AP, IBSS, Mesh, ...).
* @WIPHY_FLAG_HAS_STATIC_WEP: The device supports static WEP key
installation
* before connection.
+ * @WIPHY_FLAG_SUPPORT_TDLS_BUFFER_STA: Device support buffer STA
when TDLS is
+ * established.
If I am not mistaken no new wiphy flags are supposed to be added.
Although this might be something not reported to user-space, right?
Have a look at struct wiphy::ext_features.
I guess it should just be a HW flag in mac80211? Not sure why userspace
even needs to know.
Indeed seems specific to stack functionality in mac80211.
Regards,
Arend
[PATCH] cfg80211: remove unused function ieee80211_data_from_8023()
From: Johannes Berg
This function hasn't been used since the removal of iwmc3200wifi
in 2012. It also appears to have a bug when qos=True, since then
it'll copy uninitialized stack memory to the SKB.
Just remove the function entirely.
Reported-by: Jouni Malinen
Signed-off-by: Johannes Berg
---
Documentation/driver-api/80211/cfg80211.rst | 3 -
include/net/cfg80211.h | 13
net/wireless/util.c | 115
3 files changed, 131 deletions(-)
diff --git a/Documentation/driver-api/80211/cfg80211.rst
b/Documentation/driver-api/80211/cfg80211.rst
index 8ffac57e1f5b..eeab91b59457 100644
--- a/Documentation/driver-api/80211/cfg80211.rst
+++ b/Documentation/driver-api/80211/cfg80211.rst
@@ -299,9 +299,6 @@ Data path helpers
.. kernel-doc:: include/net/cfg80211.h
:functions: ieee80211_data_to_8023
-.. kernel-doc:: include/net/cfg80211.h
- :functions: ieee80211_data_from_8023
-
.. kernel-doc:: include/net/cfg80211.h
:functions: ieee80211_amsdu_to_8023s
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index aa9d993e519a..cc1996081463 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4346,19 +4346,6 @@ static inline int ieee80211_data_to_8023(struct sk_buff
*skb, const u8 *addr,
return ieee80211_data_to_8023_exthdr(skb, NULL, addr, iftype);
}
-/**
- * ieee80211_data_from_8023 - convert an 802.3 frame to 802.11
- * @skb: the 802.3 frame
- * @addr: the device MAC address
- * @iftype: the virtual interface type
- * @bssid: the network bssid (used only for iftype STATION and ADHOC)
- * @qos: build 802.11 QoS data frame
- * Return: 0 on success, or a negative error code.
- */
-int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
-enum nl80211_iftype iftype, const u8 *bssid,
-bool qos);
-
/**
* ieee80211_amsdu_to_8023s - decode an IEEE 802.11n A-MSDU frame
*
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4aab793c2f00..7dcdf67cba29 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -529,121 +529,6 @@ int ieee80211_data_to_8023_exthdr(struct sk_buff *skb,
struct ethhdr *ehdr,
}
EXPORT_SYMBOL(ieee80211_data_to_8023_exthdr);
-int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
-enum nl80211_iftype iftype,
-const u8 *bssid, bool qos)
-{
- struct ieee80211_hdr hdr;
- u16 hdrlen, ethertype;
- __le16 fc;
- const u8 *encaps_data;
- int encaps_len, skip_header_bytes;
- int nh_pos, h_pos;
- int head_need;
-
- if (unlikely(skb->len < ETH_HLEN))
- return -EINVAL;
-
- nh_pos = skb_network_header(skb) - skb->data;
- h_pos = skb_transport_header(skb) - skb->data;
-
- /* convert Ethernet header to proper 802.11 header (based on
-* operation mode) */
- ethertype = (skb->data[12] << 8) | skb->data[13];
- fc = cpu_to_le16(IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA);
-
- switch (iftype) {
- case NL80211_IFTYPE_AP:
- case NL80211_IFTYPE_AP_VLAN:
- case NL80211_IFTYPE_P2P_GO:
- fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS);
- /* DA BSSID SA */
- memcpy(hdr.addr1, skb->data, ETH_ALEN);
- memcpy(hdr.addr2, addr, ETH_ALEN);
- memcpy(hdr.addr3, skb->data + ETH_ALEN, ETH_ALEN);
- hdrlen = 24;
- break;
- case NL80211_IFTYPE_STATION:
- case NL80211_IFTYPE_P2P_CLIENT:
- fc |= cpu_to_le16(IEEE80211_FCTL_TODS);
- /* BSSID SA DA */
- memcpy(hdr.addr1, bssid, ETH_ALEN);
- memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
- memcpy(hdr.addr3, skb->data, ETH_ALEN);
- hdrlen = 24;
- break;
- case NL80211_IFTYPE_OCB:
- case NL80211_IFTYPE_ADHOC:
- /* DA SA BSSID */
- memcpy(hdr.addr1, skb->data, ETH_ALEN);
- memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
- memcpy(hdr.addr3, bssid, ETH_ALEN);
- hdrlen = 24;
- break;
- default:
- return -EOPNOTSUPP;
- }
-
- if (qos) {
- fc |= cpu_to_le16(IEEE80211_STYPE_QOS_DATA);
- hdrlen += 2;
- }
-
- hdr.frame_control = fc;
- hdr.duration_id = 0;
- hdr.seq_ctrl = 0;
-
- skip_header_bytes = ETH_HLEN;
- if (ethertype == ETH_P_AARP || ethertype == ETH_P_IPX) {
- encaps_data = bridge_tunnel_header;
- encaps_len = sizeof(bridge_tunnel_header);
- skip_header_bytes -= 2;
- } else if (ethertype >= ETH_P_802_3_MIN) {
- encaps_data = rfc1042_header;
- encaps_len = sizeof(rfc1042_header);
- skip_header_bytes -= 2;
- } els
Re: rtl8821ae keep alive not set, connection lost
On Thu, Sep 14, 2017 at 07:27:39PM +1000, James Cameron wrote:
> On Wed, Sep 13, 2017 at 07:39:35PM -0500, Larry Finger wrote:
> > On 09/13/2017 04:46 PM, James Cameron wrote:
> > >
> > >I'll give it some more testing and let you know, but it seems as
> > >capable of keeping a connection as 4.13 plus my earlier revert.
> > >
>
> Testing went well; removing the call to enable ASPM was as good as
> changing the DBI read back to 16-bit width.
>
> > The change I sent earlier should be as good as reverting the change
> > to write_byte in your reversion.
>
> Yes, that would be the hope.
>
> But with the 16-bit DBI read, the register REG_DBI_CTRL+0 is being
> read as well, in the first read in _rtl8821ae_enable_aspm_back_door,
> so perhaps reading that register has an unexpected side-effect.
>
I've ruled that out after testing for several days different kernels
based on v4.13;
- add an rtl_read_byte of REG_DBI_CTRL+0 in rtl8821ae_hw_init just
after the call to enable_aspm; does not solve problem,
- add an rtl_read_byte of REG_DBI_CTRL+0 at the start of
_rtl8821ae_check_pcie_dma_hang; does not solve problem,
Only way to solve the problem at the moment is either;
- reverting 40b368af4b75 ("rtlwifi: Fix alignment issues"), which
means using rtl_read_word in _rtl8821ae_dbi_read,
or
- removing the two lines that enable ASPM, as you asked me to try.
> Is there any documentation for that register? I see other code writes
> to REG_DBI_CTRL+3, in _rtl8821ae_check_pcie_dma_hang
I'll repeat and expand on this. Is there any documentation for this
register, or the other REG_DBI_* registers?
I see that DBI windowed access in rtl8192de is different and yet very
similar.
In rtl8821ae, rtl8723be, and rtl8192de the method seems straightforward;
there are bits for address, bits for write enable by byte, and flag
bits for starting the transfer and completing.
> Evidence of read from REG_DBI_CTRL was captured with an instrumented
> kernel; git diff http://dev.laptop.org/~quozl/y/1dsQ6B.txt yielding
> these dmesg lines;
>
> [6.010255] rtl_pci: _rtl_pci_update_default_setting const_amdpci_aspm=03
> [6.010338] rtl_pci: rtl_pci_enable_aspm
> [6.034295] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [6.034806] rtlwifi: rtlwifi: wireless switch is on
> [6.196958] rtl8821ae :02:00.0 wlp2s0: renamed from wlan0
> [7.979186] rtl_pci: rtl_pci_disable_aspm
> [7.979306] rtl8821ae: _rtl8821ae_check_pcie_dma_hang
> [8.295360] rtl8821ae: _rtl8821ae_enable_aspm_back_door
> [8.295437] rtl8821ae: _rtl8821ae_dbi_read 070f -> (@034f)
> [8.295449] rtl8821ae: _rtl8821ae_dbi_write 070f <- ff (@870c)
> [8.295462] rtl8821ae: _rtl8821ae_dbi_read 0719 -> 0200 (@034d)
> [8.295474] rtl8821ae: _rtl8821ae_dbi_write 0719 <- 18 (@2718)
> [8.295477] rtl_pci: rtl_pci_enable_aspm
> [8.469734] rtl_pci: rtl_pci_disable_aspm
> [8.469857] rtl8821ae: _rtl8821ae_check_pcie_dma_hang
> [8.686955] rtl8821ae: _rtl8821ae_enable_aspm_back_door
> [8.687013] rtl8821ae: _rtl8821ae_dbi_read 070f -> (@034f)
> [8.687025] rtl8821ae: _rtl8821ae_dbi_write 070f <- ff (@870c)
> [8.687038] rtl8821ae: _rtl8821ae_dbi_read 0719 -> 0218 (@034d)
> [8.687050] rtl8821ae: _rtl8821ae_dbi_write 0719 <- 18 (@2718)
> [8.687053] rtl_pci: rtl_pci_enable_aspm
>
> Observe how the windowed read of DBI register 0x70f causes a read of
> 16-bits at 0x34f, which includes first 8-bits of 0x350 REG_DBI_CTRL.
>
> By the way, the cold boot value of DBI register 0x719 is 0x00, and
> the warm boot value is 0x18, so I'm confident there isn't a
> comprehensive register reset. It means that BIOS has relevance; and
> this BIOS is outside my control. BIOS variation may explain
> difficulty reproducing.
Is there a register for device reset that I can try? It would help
to exclude BIOS.
>
> > There has been a report (in Russian unfortunately) at
> > https://www.linux.org.ru/forum/desktop/12620193 of delays in ARP
> > handling.
>
> Thanks. I've considered and excluded ARP handling delay. Though ARP
> renewal is typical reason for device sleep to end.
>
> With the call to enable ASPM disabled, instead of changing the DBI
> read to 16-bit width, what happens is that the device stops accepting
> data from the access point, packets are buffered there, and are
> transmitted as soon as the device makes the next transmission.
>
> http://dev.laptop.org/~quozl/z/1dsQBf.txt has the ping and IP tcpdump
> to confirm this.
>
> I've a monitor mode tcpdump I can send by private mail if required.
> In that the burst of packets shows ICMP echo requests were buffered by
> the access point.
>
> > According to Google translate is as follows:
> >
> >
> > Periodically, Wi-Fi networker rtl8821ae ceases to respond to ARP,
> > which causes the Internet to end. Wireshark looks quite interesting:
> > ARP replays can be sent by one large pack
Re: [TDLS PATCH V3 1/5] mac80211: Enable TDLS peer buffer STA feature
On Tue, 2017-09-19 at 09:56 +0200, Arend van Spriel wrote:
>
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -3249,6 +3249,8 @@ struct cfg80211_ops {
> > *beaconing mode (AP, IBSS, Mesh, ...).
> > * @WIPHY_FLAG_HAS_STATIC_WEP: The device supports static WEP key
> > installation
> > *before connection.
> > + * @WIPHY_FLAG_SUPPORT_TDLS_BUFFER_STA: Device support buffer STA
> > when TDLS is
> > + * established.
>
> If I am not mistaken no new wiphy flags are supposed to be added.
> Although this might be something not reported to user-space, right?
> Have a look at struct wiphy::ext_features.
I guess it should just be a HW flag in mac80211? Not sure why userspace
even needs to know.
johannes
Re: [TDLS PATCH V3 1/5] mac80211: Enable TDLS peer buffer STA feature
On 19-09-17 05:15, yint...@qti.qualcomm.com wrote:
From: Yingying Tang
Enable TDLS peer buffer STA feature.
Set extended capability bit to enable buffer STA when driver
support it.
Signed-off-by: Yingying Tang
---
include/net/cfg80211.h |3 +++
net/mac80211/tdls.c|5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f12fa52..edefc25 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3249,6 +3249,8 @@ struct cfg80211_ops {
*beaconing mode (AP, IBSS, Mesh, ...).
* @WIPHY_FLAG_HAS_STATIC_WEP: The device supports static WEP key installation
*before connection.
+ * @WIPHY_FLAG_SUPPORT_TDLS_BUFFER_STA: Device support buffer STA when TDLS is
+ * established.
If I am not mistaken no new wiphy flags are supposed to be added.
Although this might be something not reported to user-space, right? Have
a look at struct wiphy::ext_features.
Regards,
Arend
pull-request: mac80211 2017-11-19
Hi Dave, Here's a new set of two small changes to prevent null pointer dereferences on malformed netlink messages. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit 126f760ca94dae77425695f9f9238b731de86e32: rds: Fix incorrect statistics counting (2017-09-07 20:07:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-11-19 for you to fetch changes up to 265698d7e6132a2d41471135534f4f36ad15b09c: nl80211: fix null-ptr dereference on invalid mesh configuration (2017-09-18 22:51:07 +0200) Just two netlink fixes, both allowing privileged users to crash the kernel with malformed netlink messages. Johannes Berg (1): nl80211: fix null-ptr dereference on invalid mesh configuration Vladis Dronov (1): nl80211: check for the required netlink attributes presence net/wireless/nl80211.c | 6 ++ 1 file changed, 6 insertions(+)
