* [PATCH -next] mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()
From: Wei Yongjun @ 2016-09-29 14:57 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo
Cc: Wei Yongjun, linux-wireless
From: Wei Yongjun <weiyongjun1@huawei.com>
Add the missing destroy_workqueue() before return from
mwifiex_add_virtual_intf() in the error handling case.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 39ce76a..5fd5876 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3016,6 +3016,8 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
priv->netdev = NULL;
memset(&priv->wdev, 0, sizeof(priv->wdev));
priv->wdev.iftype = NL80211_IFTYPE_UNSPECIFIED;
+ destroy_workqueue(priv->dfs_cac_workqueue);
+ priv->dfs_cac_workqueue = NULL;
return ERR_PTR(-ENOMEM);
}
^ permalink raw reply related
* Re: ath10k mesh mode issue
From: Yeoh Chun-Yeow @ 2016-09-29 15:10 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Try refer the following for latest mesh setup using ath10k:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
---
Chun-Yeow
^ permalink raw reply
* [PATCH RESEND v3] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 16:39 UTC (permalink / raw)
To: linux-wireless, devicetree; +Cc: rajatja, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework.
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accomodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
v3: Patch is created using -M option so that it will only include diff of
original and renamed files(Rob Herring)
Resend v3: Resending the patch because I missed to include device tree mailing
while sending v3.
---
.../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
3 files changed, 27 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
similarity index 91%
rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index c421aba..dfe5f8e 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,8 +1,8 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
connects the device to the system.
Required properties:
@@ -10,6 +10,8 @@ Required properties:
- compatible : should be one of the following:
* "marvell,sd8897"
* "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
Optional properties:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..f1eeb73 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!dev->of_node ||
+ !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ pr_err("pcie device node not available");
+ return -1;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
+ /* device tree node parsing and platform specific configuration*/
+ mwifiex_pcie_probe_of(&pdev->dev);
+
if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
MWIFIEX_PCIE)) {
pr_err("%s failed\n", __func__);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 638d30a..f2a7a13 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if (priv->adapter->iface_type == MWIFIEX_SDIO &&
+ if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
+ priv->adapter->iface_type == MWIFIEX_PCIE) &&
adapter->dev->of_node) {
adapter->dt_node = adapter->dev->of_node;
if (of_property_read_u32(adapter->dt_node,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH RESEND v3] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-09-29 16:54 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, devicetree, Xinming Hu, Brian Norris
In-Reply-To: <1475167183-18376-1-git-send-email-akarwar@marvell.com>
[+brian]
On Thu, Sep 29, 2016 at 9:39 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accomodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> ---
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
> 3 files changed, 27 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index c421aba..dfe5f8e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,8 +1,8 @@
> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> ------
>
> -This node provides properties for controlling the marvell sdio wireless device.
> -The node is expected to be specified as a child node to the SDIO controller that
> +This node provides properties for controlling the marvell sdio/pcie wireless device.
> +The node is expected to be specified as a child node to the SDIO/PCIE controller that
> connects the device to the system.
>
> Required properties:
> @@ -10,6 +10,8 @@ Required properties:
> - compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
>
> Optional properties:
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 063c707..f1eeb73 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
>
> static struct semaphore add_remove_card_sem;
>
> +static const struct of_device_id mwifiex_pcie_of_match_table[] = {
> + { .compatible = "pci11ab,2b42" },
> + { .compatible = "pci1b4b,2b42" },
> + { }
> +};
> +
> +static int mwifiex_pcie_probe_of(struct device *dev)
> +{
> + if (!dev->of_node ||
> + !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
> + pr_err("pcie device node not available");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> static int
> mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
> size_t size, int flags)
> @@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
> card->pcie.can_ext_scan = data->can_ext_scan;
> }
>
> + /* device tree node parsing and platform specific configuration*/
> + mwifiex_pcie_probe_of(&pdev->dev);
> +
> if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
> MWIFIEX_PCIE)) {
> pr_err("%s failed\n", __func__);
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 638d30a..f2a7a13 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
> * The cal-data can be read from device tree and/or
> * a configuration file and downloaded to firmware.
> */
> - if (priv->adapter->iface_type == MWIFIEX_SDIO &&
> + if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
> + priv->adapter->iface_type == MWIFIEX_PCIE) &&
> adapter->dev->of_node) {
> adapter->dt_node = adapter->dev->of_node;
> if (of_property_read_u32(adapter->dt_node,
> --
> 1.9.1
>
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-09-29
From: Kalle Valo @ 2016-09-29 16:57 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this should be the last wireless-drivers-next pull request for 4.9, from
now on only important bugfixes. Nothing really special stands out,
iwlwifi being most active but other drivers also getting attention. More
details in the signed tag. Please let me know if there are any problems.
Or actually I had one problem. While doing a test merge I noticed that
net-next fails to compile for me, but I don't think this is anything
wireless related:
CC net/netfilter/core.o
net/netfilter/core.c: In function 'nf_set_hooks_head':
net/netfilter/core.c:96:149: error: 'struct net_device' has no member named=
'nf_hooks_ingress'
Kalle
The following changes since commit fd9527f404d51e50f40dac0d9a69f2eff3dac33e:
Merge branch 'ip_tunnel-collect_md' (2016-09-17 10:13:16 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2016-09-29
for you to fetch changes up to 15b95a15950238eff4d7f24be1716086eea67835:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/a=
th.git (2016-09-28 16:37:33 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.9
Major changes:
iwlwifi
* work for new hardware support continues
* dynamic queue allocation stabilization
* improvements in the MSIx code
* multiqueue support work continues
* new firmware version support (API 26)
* add 8275 series support
* add 9560 series support
* add support for MU-MIMO sniffer
* add support for RRM by scan
* add support for "reverse" rx packet injection faking hw descriptors
* migrate to devm memory allocation handling
* Remove support for older firmwares (API older than -17 and -22)
wl12xx
* support booting the same rootfs with both wl12xx and wl18xx
hostap
* mark the driver as obsolete
ath9k
* disable RNG by default
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: code rearrangement in mwifiex_usb_host_to_card()
Arend Van Spriel (4):
brcmfmac: rework pointer trickery in brcmf_proto_bcdc_query_dcmd()
brcmfmac: fix memory leak in brcmf_flowring_add_tdls_peer()
brcmfmac: initialize variable in brcmf_sdiod_regrl()
brcmfmac: remove worker from .ndo_set_mac_address() callback
Arik Nemtsov (1):
iwlwifi: move BIOS MCC retrieval to common code
Aviya Erenfeld (1):
iwlwifi: mvm: add support for MU-MIMO air sniffer
Avrahams Stern (1):
iwlwifi: mvm: Add support for RRM by scan
Ben Greear (3):
ath10k: fix typo in logging message
ath10k: document cycle count related counters
ath10k: support up to 64 vdevs
Bob Copeland (1):
mwifiex: fix error handling in mwifiex_create_custom_regdomain
Cathy Luo (2):
mwifiex: fix kernel crash for USB chipsets
mwifiex: fix race condition causing tx timeout
Chaehyun Lim (1):
ath6kl: fix return value in ath6kl_wmi_set_pvb_cmd
Colin Ian King (1):
mwifiex: fix null pointer deference when adapter is null
Emmanuel Grumbach (4):
iwlwifi: mvm: bump max API to 26
iwlwifi: don't export trace points that are used in iwlwifi only
iwlwifi: mvm: fix typo in TC_CMD_SEC_KEY_FROM_TABLE
iwlwifi: mvm: initialise ADD_STA before sending it to the firmware
Ganapathi Bhat (1):
mwifiex: cfg80211 set_default_mgmt_key handler
Haim Dreyfuss (4):
iwlwifi: pcie: Configure shared interrupt vector in MSIX mode
iwlwifi: pcie: Set affinity mask for rx interrupt vectors per cpu
iwlwifi: pcie: replace possible_cpus() with online_cpus() in MSIX mode
iwlwifi: check for valid ethernet address provided by OEM
Hante Meuleman (5):
brcmfmac: ignore 11d configuration errors
brcmfmac: remove unnecessary null pointer check
brcmfmac: fix clearing entry IPv6 address
brcmfmac: fix out of bound access on clearing wowl wake indicator
brcmfmac: simplify mapping of auth type
Ido Yariv (1):
iwlwifi: mvm: Add mem debugfs entry
Jes Sorensen (4):
rtl8xxxu: Implement 8192e specific power down sequence
rtl8xxxu: Fix off by one error calculating pubq
rtl8xxxu: Clean up llt_init() API
rtl8xxxu: Use a struct rtl8xxxu_fileops * in rtl8xxxu_init_device()
Joe Perches (2):
ath10k: spelling and miscellaneous neatening
rtlwifi: Add switch variable to 'switch case not processed' messages
Johannes Berg (11):
iwlwifi: mvm: make RSS RX more robust
iwlwifi: mvm: remove pointless _bh from spinlock in timer
iwlwifi: mvm: tighten BAID range check
iwlwifi: mvm: compare full command ID
iwlwifi: mvm: make iwl_mvm_update_sta() an inline
iwlwifi: mvm: document passing unexpected Block Ack Request frames
iwlwifi: mvm: move AP-specific code to right function
iwlwifi: mvm: use LIST_HEAD() macro
iwlwifi: pcie: use LIST_HEAD() macro
iwlwifi: pcie: avoid variable shadowing in TFD helpers
iwlwifi: mvm: correct rate_idx bounds-check
Jouni Malinen (1):
MAINTAINERS: hostap: Mark the Host AP driver obsolete
Kalle Valo (4):
Merge tag 'iwlwifi-next-for-kalle-2016-09-15-2' of git://git.kernel.o=
rg/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2016-09-19-2' of git://git.kernel.o=
rg/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2015-09-26' of git://git.kernel.org=
/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Larry Finger (3):
rtl8xxxu: Stop log spam from each successful interrupt
rtlwifi: Add HAL_DEF_WOWLAN case to *_get_hw() routines
rtlwifi: Add explicit values to hw_variables enum
Liad Kaufman (4):
iwlwifi: mvm: don't free queue after delba in dqa
iwlwifi: mvm: fix pending frames tracking on tx resp
iwlwifi: mvm: free reserved queue on STA removal
iwlwifi: mvm: remove variable shadowing
Luca Coelho (2):
iwlwifi: mvm: bail out if CTDP start operation fails
iwlwifi: remove support for fw older than -17 and -22
Masahiro Yamada (3):
ath10k: use devm_clk_get() instead of clk_get()
ath10k: use devm_reset_control_get() instead of reset_control_get()
ath10k: do not check if reset is NULL
Miaoqing Pan (1):
ath9k: disable RNG by default
Mohammed Shafi Shajakhan (1):
ath10k: Ignore SWBA event for a vif if its marked for no beacon
Oren Givon (4):
iwlwifi: add the new 9560 series
iwlwifi: add the new 8275 series
iwlwifi: add new 8265 series PCI ID
iwlwifi: add two new 9560 series PCI IDs
Rafa=C5=82 Mi=C5=82ecki (4):
brcmfmac: fix memory leak in brcmf_fill_bss_param
brcmfmac: drop unused fields from struct brcmf_pub
brcmfmac: replace WARNING on timeout with a simple error message
brcmfmac: use correct skb freeing helper when deleting flowring
Rajkumar Manoharan (1):
ath10k: fix copy engine 5 destination ring stuck
Roee Zamir (1):
iwlwifi: mvm: Add debugfs function for clocks diff
Sara Sharon (22):
iwlwifi: mvm: call a different txq_enable function
iwlwifi: pcie: introduce new tfd and tb formats
iwlwifi: mvm: remove dump of locked registers
iwlwifi: mvm: support new shared memory config API
iwlwifi: introduce trans API to get byte count table
iwlwifi: pcie: assign and access a000 TFD & TBs
iwlwifi: change byte count table for a000 devices
iwlwifi: pcie: merge iwl_queue and iwl_txq
iwlwifi: mvm: support new BA notification response
iwlwifi: pcie: change indentation of iwl_pcie_set_interrupt_capa()
iwlwifi: pcie: fix typo in struct name for a000 devices
iwlwifi: mvm: cleanup skb queue functions use
iwlwifi: mvm: fix DQA AP mode station assumption
iwlwifi: mvm: support BAR in reorder buffer
iwlwifi: mvm: support packet injection
iwlwifi: pcie: log full command sequence
iwlwifi: move to wide ID for all commands
iwlwifi: mvm: disable P2P queue on mac context release
iwlwifi: mvm: set HCMD_NAME for PHY_DB as well
iwlwifi: mvm: cleanup redundant no_power_up_nic_in_init config
iwlwifi: mvm: cleanup usage of init_dbg parameter
iwlwifi: allow error table address new range
Sharon Dvir (2):
iwlwifi: unify iwl_get_ucode_image() implementations
iwlwifi: migrate to devm_* API
Tony Lindgren (5):
wlcore: Prepare family to fix nvs file handling
wlcore: sdio: Populate config firmware data
wlcore: spi: Populate config firmware data
wlcore: Fix config firmware loading issues
wlcore: wl18xx: Use chip specific configuration firmware
Vasanthakumar Thiagarajan (1):
ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode
Wei Yongjun (2):
iwlwifi: mvm: use setup_timer instead of init_timer and data fields
ath10k: fix error return code in ahb
kbuild test robot (1):
iwlwifi: fix semicolon.cocci warnings
MAINTAINERS | 5 +-
drivers/net/wireless/ath/ath10k/ahb.c | 107 ++----
drivers/net/wireless/ath/ath10k/ce.c | 9 +-
drivers/net/wireless/ath/ath10k/core.c | 17 +-
drivers/net/wireless/ath/ath10k/core.h | 8 +-
drivers/net/wireless/ath/ath10k/htt.h | 8 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +-
drivers/net/wireless/ath/ath10k/hw.c | 2 +-
drivers/net/wireless/ath/ath10k/hw.h | 5 +-
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
drivers/net/wireless/ath/ath10k/targaddrs.h | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 6 +
drivers/net/wireless/ath/ath10k/wmi.h | 32 +-
drivers/net/wireless/ath/ath6kl/wmi.c | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 46 +--
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 55 ++-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 6 -
.../broadcom/brcm80211/brcmfmac/flowring.c | 17 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 2 -
drivers/net/wireless/intel/iwlwifi/dvm/ucode.c | 11 +-
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 10 +-
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 17 +-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 15 +-
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 3 +-
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c | 3 -
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 57 ++-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 29 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw.h | 9 +
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 2 +-
.../net/wireless/intel/iwlwifi/iwl-notif-wait.c | 8 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 104 ++++-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 20 +-
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 12 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 20 +-
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 29 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 184 +++++++++
.../net/wireless/intel/iwlwifi/mvm/fw-api-power.h | 21 +-
.../net/wireless/intel/iwlwifi/mvm/fw-api-scan.h | 20 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 85 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 74 +++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 152 ++++----
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 47 +--
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 42 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 18 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 93 +----
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 80 ++--
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 38 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 88 +++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 51 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 10 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 214 +++++++----
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 24 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 8 +
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 128 ++++---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 25 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 325 +++++++++-------
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 397 ++++++++++++----=
----
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 24 ++
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 +
drivers/net/wireless/marvell/mwifiex/main.c | 8 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 5 +
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 13 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 37 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 7 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 144 ++++++-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 49 +--
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 1 +
drivers/net/wireless/realtek/rtlwifi/core.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/ps.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 10 +-
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 4 +-
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 9 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 9 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/led.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 20 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 208 +++++-----
drivers/net/wireless/ti/wl18xx/main.c | 19 +-
drivers/net/wireless/ti/wlcore/boot.c | 15 +-
drivers/net/wireless/ti/wlcore/main.c | 36 +-
drivers/net/wireless/ti/wlcore/sdio.c | 76 ++--
drivers/net/wireless/ti/wlcore/spi.c | 48 +--
drivers/net/wireless/ti/wlcore/wlcore_i.h | 12 +-
122 files changed, 2383 insertions(+), 1437 deletions(-)
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-09-29
From: Pablo Neira Ayuso @ 2016-09-29 18:21 UTC (permalink / raw)
To: Kalle Valo; +Cc: David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <87ponmve2v.fsf@kamboji.qca.qualcomm.com>
On Thu, Sep 29, 2016 at 07:57:28PM +0300, Kalle Valo wrote:
> Hi Dave,
>
> this should be the last wireless-drivers-next pull request for 4.9, from
> now on only important bugfixes. Nothing really special stands out,
> iwlwifi being most active but other drivers also getting attention. More
> details in the signed tag. Please let me know if there are any problems.
>
> Or actually I had one problem. While doing a test merge I noticed that
> net-next fails to compile for me, but I don't think this is anything
> wireless related:
>
> CC net/netfilter/core.o
> net/netfilter/core.c: In function 'nf_set_hooks_head':
> net/netfilter/core.c:96:149: error: 'struct net_device' has no member named 'nf_hooks_ingress'
That's my problem, will be sending a pull request to fix this asap,
thanks.
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Felix Fietkau @ 2016-09-29 18:31 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, devicetree
In-Reply-To: <87eg4uu0f3.fsf@kamboji.qca.qualcomm.com>
On 2016-09-08 12:54, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> ---
>> .../bindings/net/wireless/mediatek,mt76.txt | 26 ++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> new file mode 100644
>> index 0000000..d51c35f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> @@ -0,0 +1,26 @@
>> +* MediaTek mt76xx devices
>> +
>> +This node provides properties for configuring the MediaTek mt76xx wireless
>> +device. The node is expected to be specified as a child node of the PCI
>> +controller to which the wireless chip is connected.
>> +
>> +Optional properties:
>> +
>> +- mac-address: See ethernet.txt in the parent directory
>> +- local-mac-address: See ethernet.txt in the parent directory
>> +- mediatek,2ghz: Override the 2.4 GHz band capability from EEPROM
>> +- mediatek,5ghz: Override the 5 GHz band capability from EEPROM
>> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
>> +
>> +&pcie {
>> + status = "okay";
>> +
>> + pcie0 {
>> + mt76@0,0 {
>> + reg = <0x0000 0 0 0 0>;
>> + device_type = "pci";
>> + mediatek,mtd-eeprom = <&factory 0x8000>;
>> + mediatek,2ghz = <0>;
>> + };
>> + };
>> +};
>
> I need an ack from device tree maintainers, CCing the devicetree list.
> Do we need to resend or this ok?
>
> Patchwork link:
>
> https://patchwork.kernel.org/patch/9313309/
Ping?
- Felix
^ permalink raw reply
* [PATCH 0/2] rtl8xxxu: Fix memory leak and big endian bug
From: Jes.Sorensen @ 2016-09-29 19:40 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
These two patches for 4.9 fix a potential memory leak for gen1 parts
and a big endian problem reporting mactime.
While I have only seen it trigger for 8188eu devices, in code which
has not yet been submitted, it could potentially hit other parts such
as 8723au, 8188cu, 8192cu. I prefer to get it fixed asap.
The second bug is a double byte-swap of the mactime read from the RX
packet descriptor.
Both fixes should be applicable to stable-4.8.
Cheers,
Jes
Jes Sorensen (2):
rtl8xxxu: Fix memory leak in handling rxdesc16 packets
rtl8xxxu: Fix big-endian problem reporting mactime
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 4 ++--
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 11 ++++++++---
2 files changed, 10 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/2] rtl8xxxu: Fix big-endian problem reporting mactime
From: Jes.Sorensen @ 2016-09-29 19:40 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475178055-16924-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
The full RX descriptor is converted so converting tsfl again would
return it to it's original endian value.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 4 ++--
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 10166289..08d587a 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -238,7 +238,7 @@ struct rtl8xxxu_rxdesc16 {
u32 pattern1match:1;
u32 pattern0match:1;
#endif
- __le32 tsfl;
+ u32 tsfl;
#if 0
u32 bassn:12;
u32 bavld:1;
@@ -368,7 +368,7 @@ struct rtl8xxxu_rxdesc24 {
u32 ldcp:1;
u32 splcp:1;
#endif
- __le32 tsfl;
+ u32 tsfl;
};
struct rtl8xxxu_txdesc32 {
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a96ff17..a5e6ec2 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5220,7 +5220,7 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
rx_desc->rxmcs);
- rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+ rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
if (!rx_desc->swdec)
@@ -5290,7 +5290,7 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
rx_desc->rxmcs);
- rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+ rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
if (!rx_desc->swdec)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Jes.Sorensen @ 2016-09-29 19:40 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475178055-16924-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
A device running without RX package aggregation could return more data
in the USB packet than the actual network packet. In this case the
could would clone the skb but then determine that that there was no
packet to handle and exit without freeing the cloned skb first.
This has so far only been observed with 8188eu devices, but could
affect others.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index b2d7f6e..a96ff17 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5197,7 +5197,12 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
pkt_offset = roundup(pkt_len + drvinfo_sz + desc_shift +
sizeof(struct rtl8xxxu_rxdesc16), 128);
- if (pkt_cnt > 1)
+ /*
+ * Only clone the skb if there's enough data at the end to
+ * at least cover the rx descriptor
+ */
+ if (pkt_cnt > 1 &&
+ urb_len > (pkt_offset + sizeof(struct rtl8xxxu_rxdesc16)))
next_skb = skb_clone(skb, GFP_ATOMIC);
rx_status = IEEE80211_SKB_RXCB(skb);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] brcmfmac: implement more accurate skb tracking
From: Rafał Miłecki @ 2016-09-29 21:57 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List,
Rafał Miłecki
In-Reply-To: <0a070079-e3af-ab5c-0485-744bec8b3d86@broadcom.com>
On 27 September 2016 at 11:24, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 26-9-2016 14:38, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 26 September 2016 at 14:13, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com=
> wrote:
>>> On 26 September 2016 at 13:46, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 26-9-2016 12:23, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>
>>>>> We need to track 802.1x packets to know if there are any pending ones
>>>>> for transmission. This is required for performing key update in the
>>>>> firmware.
>>>>
>>>> The problem we are trying to solve is a pretty old one. The problem is
>>>> that wpa_supplicant uses two separate code paths: EAPOL messaging
>>>> through data path and key configuration though nl80211.
>>>
>>> Can I find it described/reported somewhere?
>>>
>>>
>>>>> Unfortunately our old tracking code wasn't very accurate. It was
>>>>> treating skb as pending as soon as it was passed by the netif. Actual
>>>>> handling packet to the firmware was happening later as brcmfmac
>>>>> internally queues them and uses its own worker(s).
>>>>
>>>> That does not seem right. As soon as we get a 1x packet we need to wai=
t
>>>> with key configuration regardless whether it is still in the driver or
>>>> handed over to firmware already.
>>>
>>> OK, thanks.
>>
>> Actually, it's not OK. I was trying to report/describe/discuss this
>> problem for over a week. I couldn't get much of answer from you.
>>
>> I had to come with a patch I worked on for quite some time. Only then
>> you decided to react and reply with a reason for a nack. I see this
>> patch may be wrong (but it's still hard to know what's going wrong
>> without a proper hostapd bug report). I'd expect you to somehow work &
>> communicate with open source community.
>
> We do or at least make an honest attempt, but there is more on our plate
> so responses may be delayed. It also does not help when you get anal and
> preachy when we do respond. Also not OK. In this case the delay is
> caused because I had to pick up the thread(s) as Hante is on vacation
> (he needed a break :-p ). However, you started sending patches so I
> decided to look at and respond to those. Sorry if you felt like we left
> you hanging to dry.
I believe I get easily irritated due to my communication experience I
got so far :(
Over a year ago I reported brcmfmac can't recover from failed
register_netdev(ice). This bug remains unfixed.
In 2014 I reported problem with 80 MHz support. I didn't have hardware
to fix & test it on my own (you weren't able/allowed to send me one of
your PCIe cards). In remained broken until I fixed it year later.
You missed my crash bug report about caused by missing eth_type_trans
and came with patch on your own a month later.
Earlier this year I reported you problem with BCM4366 and multiple
interfaces. I didn't get much help. 3 months later I came with patch
to workaround the problem but you said there's a better way to do
this. It took me 2 weeks to figure out a new wlioctl API for that
while all I needed was a simple hint on "interface_remove".
Right now I'm waiting to get any answer from you about 4366c0
firmware. It's still less than 2 weeks since I asked for it, but a
simple ETA would be nice. I'm actually not sure if I should report
more problems to you to don't distract you from pending things.
Problems with brcmf_netdev_wait_pend8021x were reported multiples
times for last few months. When I finally got time for that it took me
a week to debug them.
As you can see, it takes me months to get help on some things. And in
few cases I never got much help at all. Yes, I was hoping to have you
more involved into brcmfmac development and problems solving. I guess
things didn't meet my expectations and I got grumpy & preachy.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Arnd Bergmann @ 2016-09-29 22:41 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <e7d435b2-6b59-45af-07eb-b10789d61a9c@nbd.name>
On Thursday 29 September 2016, Felix Fietkau wrote:
> On 2016-09-08 12:54, Kalle Valo wrote:
> > Felix Fietkau <nbd@nbd.name> writes:
> >
> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> >> ---
> >> .../bindings/net/wireless/mediatek,mt76.txt | 26 ++++++++++++++++++++++
> >> 1 file changed, 26 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >> new file mode 100644
> >> index 0000000..d51c35f
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> >> @@ -0,0 +1,26 @@
> >> +* MediaTek mt76xx devices
> >> +
> >> +This node provides properties for configuring the MediaTek mt76xx wireless
> >> +device. The node is expected to be specified as a child node of the PCI
> >> +controller to which the wireless chip is connected.
> >> +
> >> +Optional properties:
> >> +
> >> +- mac-address: See ethernet.txt in the parent directory
> >> +- local-mac-address: See ethernet.txt in the parent directory
> >> +- mediatek,2ghz: Override the 2.4 GHz band capability from EEPROM
> >> +- mediatek,5ghz: Override the 5 GHz band capability from EEPROM
> >> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
> >> +
> >> +&pcie {
> >> + status = "okay";
> >> +
> >> + pcie0 {
> >> + mt76@0,0 {
> >> + reg = <0x0000 0 0 0 0>;
Maybe have an examplep of a real register address other than zero?
> >> + device_type = "pci";
> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
> >> + mediatek,2ghz = <0>;
It's not clear what the possible values for the 2ghz property are,
can you be more verbose in the description? How is <0> different
from no property?
Arnd
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-09-29
From: David Miller @ 2016-09-30 5:32 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87ponmve2v.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 29 Sep 2016 19:57:28 +0300
> this should be the last wireless-drivers-next pull request for 4.9, from
> now on only important bugfixes. Nothing really special stands out,
> iwlwifi being most active but other drivers also getting attention. More
> details in the signed tag. Please let me know if there are any problems.
Pulled, thanks Kalle.
> Or actually I had one problem. While doing a test merge I noticed that
> net-next fails to compile for me, but I don't think this is anything
> wireless related:
>
> CC net/netfilter/core.o
> net/netfilter/core.c: In function 'nf_set_hooks_head':
> net/netfilter/core.c:96:149: error: 'struct net_device' has no member named 'nf_hooks_ingress'
Yes, I am aware of this build issue and will tackle it myself if someone
doesn't beat me to it.
Thanks again.
^ permalink raw reply
* Re: ath10k mesh mode issue
From: Matteo Grandi @ 2016-09-30 6:55 UTC (permalink / raw)
To: Yeoh Chun-Yeow; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAEFj984FqjgqJJCB=b8tZkaAudGRNjwJAw=RtmqP56x89iOZtg@mail.gmail.com>
Hi Chun-Yeoh,
These https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
are the staeps that i followed to set-up the mesh.
Thanks!
Matteo
2016-09-29 17:10 GMT+02:00 Yeoh Chun-Yeow <yeohchunyeow@gmail.com>:
> Try refer the following for latest mesh setup using ath10k:
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
>
> ---
> Chun-Yeow
^ permalink raw reply
* Re: [PATCH 1/3] mac80211: filter multicast data packets on AP / AP_VLAN
From: Johannes Berg @ 2016-09-30 7:20 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless
In-Reply-To: <1474821596-12155-2-git-send-email-michael-dev@fami-braun.de>
[snip]
I think this makes sense, but it's not clear to me why you add two
counters and keep the old one? It seems to me that it would be
sufficient to have a single counter per AP/VLAN interface?
The usage in __ieee80211_request_smps_ap() can just be removed since it
goes to iterate the stations next. That should be a separate, first,
patch in the series, but after that I don't see a need to keep
num_mcast_sta, or rather, I see no reason not to remove the VLAN
stations from the AP's num_mcast_sta, and add a new per-VLAN
num_mcast_sta.
> +/**
> + * @returns number of multicast stations connected
> + * -1 if unsupported (no-AP, 4addr mode)
> + */
> +static inline int
> +ieee80211_vif_get_num_mcast_if(struct ieee80211_sub_if_data *sdata)
That's not a valid kernel-doc comment, but you've tagged it as one with
the /** - please fix by removing the /** and the @, and writing a real
sentence out of that, or by making it a real kernel-doc comment.
johannes
^ permalink raw reply
* Re: ath10k stuck on 6Mbps and spam syslog
From: Matteo Grandi @ 2016-09-30 7:23 UTC (permalink / raw)
To: Ben Greear; +Cc: LinuxWireless Mailing List
In-Reply-To: <57ED2982.4020002@candelatech.com>
Dear Ben,
Thank you for your reply.
The fact that stock ath10k firmware does not report tx-rate explains
why the station dump shows 6Mbps but the iperf test reach 14.6 (even
if it is really under the expected data rate...).
About the syslog spam, this is the code of the function that seems to
cause the error (I put a comment at line 2621 side). (The warning
start to spam as soon as I assign the channel "iw dev <if_name> set
channel <ch_number>)
/**
* ieee80211_calculate_rx_timestamp - calculate timestamp in frame
* @local: mac80211 hw info struct
* @status: RX status
* @mpdu_len: total MPDU length (including FCS)
* @mpdu_offset: offset into MPDU to calculate timestamp at
*
* This function calculates the RX timestamp at the given MPDU offset, taking
* into account what the RX timestamp was. An offset of 0 will just normalize
* the timestamp to TSF at beginning of MPDU reception.
*/
u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
struct ieee80211_rx_status *status,
unsigned int mpdu_len,
unsigned int mpdu_offset)
{
u64 ts = status->mactime;
struct rate_info ri;
u16 rate;
if (WARN_ON(!ieee80211_have_rx_timestamp(status))) //this is the
line 2621 reported in the warning
return 0;
memset(&ri, 0, sizeof(ri));
/* Fill cfg80211 rate info */
if (status->flag & RX_FLAG_HT) {
ri.mcs = status->rate_idx;
ri.flags |= RATE_INFO_FLAGS_MCS;
if (status->flag & RX_FLAG_40MHZ)
ri.bw = RATE_INFO_BW_40;
else
ri.bw = RATE_INFO_BW_20;
if (status->flag & RX_FLAG_SHORT_GI)
ri.flags |= RATE_INFO_FLAGS_SHORT_GI;
} else if (status->flag & RX_FLAG_VHT) {
ri.flags |= RATE_INFO_FLAGS_VHT_MCS;
ri.mcs = status->rate_idx;
ri.nss = status->vht_nss;
if (status->flag & RX_FLAG_40MHZ)
ri.bw = RATE_INFO_BW_40;
else if (status->vht_flag & RX_VHT_FLAG_80MHZ)
ri.bw = RATE_INFO_BW_80;
else if (status->vht_flag & RX_VHT_FLAG_160MHZ)
ri.bw = RATE_INFO_BW_160;
else
ri.bw = RATE_INFO_BW_20;
if (status->flag & RX_FLAG_SHORT_GI)
ri.flags |= RATE_INFO_FLAGS_SHORT_GI;
} else {
struct ieee80211_supported_band *sband;
int shift = 0;
int bitrate;
if (status->flag & RX_FLAG_10MHZ) {
shift = 1;
ri.bw = RATE_INFO_BW_10;
} else if (status->flag & RX_FLAG_5MHZ) {
shift = 2;
ri.bw = RATE_INFO_BW_5;
} else {
ri.bw = RATE_INFO_BW_20;
}
sband = local->hw.wiphy->bands[status->band];
bitrate = sband->bitrates[status->rate_idx].bitrate;
ri.legacy = DIV_ROUND_UP(bitrate, (1 << shift));
}
rate = cfg80211_calculate_bitrate(&ri);
if (WARN_ONCE(!rate,
"Invalid bitrate: flags=0x%x, idx=%d, vht_nss=%d\n",
status->flag, status->rate_idx, status->vht_nss))
return 0;
/* rewind from end of MPDU */
if (status->flag & RX_FLAG_MACTIME_END)
ts -= mpdu_len * 8 * 10 / rate;
ts += mpdu_offset * 8 * 10 / rate;
/* [SESAME] I2CAT. dbg*/
//printk(KERN_DEBUG "calculate_rx_timestamp: ts = %lu;\t rate =
%lu;\tmpdu_offset = %lu;\tmpdu_len = %lu\n",
// (long unsigned int) ts, (long unsigned int) rate, (long unsigned
int) mpdu_offset, (long unsigned int) mpdu_len );
return ts;
}
Thank you so much!
All the best
Matteo
2016-09-29 16:47 GMT+02:00 Ben Greear <greearb@candelatech.com>:
> stock ath10k firmware does not report tx-rate so the kernel always sees
> 6Mbps.
>
> I don't know about the splat..maybe post the function
> that is causing that?
>
> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
>
> Thanks,
> Ben
>
>
> On 09/29/2016 06:39 AM, Matteo Grandi wrote:
>>
>> Hello all,
>>
>> I'm struggling with a problem related on ath10k drivers:
>> I'm using a Compex WLE600V5-27 (802.11ac) miniPCIe card for some HT
>> tests needed for my thesis.
>> I'm using ath10k drivers for this card, and backports-4.4.2, in
>> particular the firmware-5.bin_10.2.4.70.54 because it seem to be the
>> more recent.
>> I've connected in mesh mode the WLE600V5 card with an 802.11n card
>> (using ath9k drivers) but looking at the station dump, the tx bitrate
>> is stuck on 6.0 Mbit/s for the ath10k. The ath9k one works well and
>> watch -n1 iw <interfacename> station dump
>> let me see changes of the tx rate and MCS on the ath9k during iperf
>> tests, but the ath10k stucks on 6.0 Mbit/s.
>>
>> Then something misterious (for me) happen while the channel
>> assignment: the syslog is spammed by this message:
>>
>> [17554.919459] ------------[ cut here ]------------
>> [17554.919839] WARNING: CPU: 0 PID: 0 at
>> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
>> ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
>> [17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O)
>> ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
>> [17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O
>> 3.14.48-g408ccb9 #4
>> [17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>]
>> (show_stack+0x10/0x14)
>> [17554.920038] [<80011330>] (show_stack) from [<806537dc>]
>> (dump_stack+0x80/0x90)
>> [17554.920074] [<806537dc>] (dump_stack) from [<8002c578>]
>> (warn_slowpath_common+0x6c/0x88)
>> [17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>]
>> (warn_slowpath_null+0x1c/0x24)
>> [17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>]
>> (ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
>> [17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp
>> [mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4
>> [mac80211])
>> [17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from
>> [<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
>> [17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core])
>> from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464
>> [ath10k_core])
>> [17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler
>> [ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc
>> [ath10k_pci])
>> [17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci])
>> from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94
>> [ath10k_pci])
>> [17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service
>> [ath10k_pci]) from [<7f15b464>]
>> (ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
>> [17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any
>> [ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c
>> [ath10k_pci])
>> [17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from
>> [<800304c8>] (tasklet_action+0x80/0x110)
>> [17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>]
>> (__do_softirq+0x10c/0x248)
>> [17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>]
>> (irq_exit+0xac/0xf4)
>> [17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>]
>> (handle_IRQ+0x44/0x90)
>> [17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>]
>> (gic_handle_irq+0x2c/0x5c)
>> [17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>]
>> (__irq_svc+0x40/0x50)
>> [17554.922122] Exception stack(0x80917f18 to 0x80917f60)
>> [17554.922141] 7f00:
>> 80917f60 000d3334
>> [17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010
>> 80924060 00000001 a7705014
>> [17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab
>> 80492940 60000013 ffffffff
>> [17554.922224] [<80011e00>] (__irq_svc) from [<80492940>]
>> (cpuidle_enter_state+0x50/0xe0)
>> [17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>]
>> (cpuidle_idle_call+0xf8/0x148)
>> [17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>]
>> (arch_cpu_idle+0x8/0x44)
>> [17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>]
>> (cpu_startup_entry+0xfc/0x140)
>> [17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>]
>> (start_kernel+0x360/0x36c)
>> [17554.922379] ---[ end trace 87d4775146813aed ]---
>> [17555.943454] ------------[ cut here ]------------
>>
>> that repeat continuously...
>> Forcing legacy bitrates doesn't change the situation.
>>
>> I made some measurements using iperf, please find it in attachment.
>>
>> Other info:
>>
>> root@Yazi:~# modinfo ath10k_pci
>> filename:
>>
>> /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
>> firmware: ath10k/QCA9377/hw1.0/board.bin
>> firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
>> firmware: ath10k/QCA6174/hw3.0/board-2.bin
>> firmware: ath10k/QCA6174/hw3.0/board.bin
>> firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
>> firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
>> firmware: ath10k/QCA6174/hw2.1/board-2.bin
>> firmware: ath10k/QCA6174/hw2.1/board.bin
>> firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
>> firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
>> firmware: ath10k/QCA988X/hw2.0/board-2.bin
>> firmware: ath10k/QCA988X/hw2.0/board.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
>> firmware: ath10k/QCA988X/hw2.0/firmware.bin
>> license: Dual BSD/GPL
>> description: Driver support for Atheros QCA988X PCIe devices
>> author: Qualcomm Atheros
>> version: backported from Linux (v4.4.2-0-g1cb8570) using
>> backports v4.4.2-1-0-gbec4037
>> srcversion: EBB3D4E36DE49B7EC8057D0
>> alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
>> alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
>> alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
>> alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
>> alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
>> depends: ath10k_core,compat
>> vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
>> parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
>> parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
>>
>> I don't know if it's only a problem of iw station dump that can't show
>> the tx rate, but the spammed syslog honestly warn me...
>>
>> How shall I check what's wrong and see the HT work?
>>
>> Thanks a lot!
>>
>> Matteo
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/3] mac80211: multicast to unicast conversion
From: Johannes Berg @ 2016-09-30 7:29 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless
In-Reply-To: <1474821596-12155-3-git-send-email-michael-dev@fami-braun.de>
> +static ssize_t ieee80211_if_fmt_unicast(
> + const struct ieee80211_sub_if_data *sdata, char *buf, int
> buflen)
That's a very ... unusual way to break the lines here - please either
break after the first argument, or before the function name. You should
see lots of examples for both.
However, regardless of that, I don't think that debugfs is an
appropriate way to configure a production option like this.
> + int unicast;
bool, quite obviously.
> +/* rewrite destination mac address */
> +static int ieee80211_tx_dnat(struct sk_buff *skb, struct sta_info
> *sta)
How is this DNAT?
johannes
^ permalink raw reply
* Re: [PATCH] brcmfmac: implement more accurate skb tracking
From: Arend Van Spriel @ 2016-09-30 8:29 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List,
Rafał Miłecki
In-Reply-To: <CACna6rxg5r=YWh7m1TYAhD5OrG3+KXAWMihs9mgh-EBVfKvt+g@mail.gmail.com>
On 29-9-2016 23:57, Rafał Miłecki wrote:
> On 27 September 2016 at 11:24, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 26-9-2016 14:38, Rafał Miłecki wrote:
>>> On 26 September 2016 at 14:13, Rafał Miłecki <zajec5@gmail.com> wrote:
>>>> On 26 September 2016 at 13:46, Arend Van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>> On 26-9-2016 12:23, Rafał Miłecki wrote:
>>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>>
>>>>>> We need to track 802.1x packets to know if there are any pending ones
>>>>>> for transmission. This is required for performing key update in the
>>>>>> firmware.
>>>>>
>>>>> The problem we are trying to solve is a pretty old one. The problem is
>>>>> that wpa_supplicant uses two separate code paths: EAPOL messaging
>>>>> through data path and key configuration though nl80211.
>>>>
>>>> Can I find it described/reported somewhere?
>>>>
>>>>
>>>>>> Unfortunately our old tracking code wasn't very accurate. It was
>>>>>> treating skb as pending as soon as it was passed by the netif. Actual
>>>>>> handling packet to the firmware was happening later as brcmfmac
>>>>>> internally queues them and uses its own worker(s).
>>>>>
>>>>> That does not seem right. As soon as we get a 1x packet we need to wait
>>>>> with key configuration regardless whether it is still in the driver or
>>>>> handed over to firmware already.
>>>>
>>>> OK, thanks.
>>>
>>> Actually, it's not OK. I was trying to report/describe/discuss this
>>> problem for over a week. I couldn't get much of answer from you.
>>>
>>> I had to come with a patch I worked on for quite some time. Only then
>>> you decided to react and reply with a reason for a nack. I see this
>>> patch may be wrong (but it's still hard to know what's going wrong
>>> without a proper hostapd bug report). I'd expect you to somehow work &
>>> communicate with open source community.
>>
>> We do or at least make an honest attempt, but there is more on our plate
>> so responses may be delayed. It also does not help when you get anal and
>> preachy when we do respond. Also not OK. In this case the delay is
>> caused because I had to pick up the thread(s) as Hante is on vacation
>> (he needed a break :-p ). However, you started sending patches so I
>> decided to look at and respond to those. Sorry if you felt like we left
>> you hanging to dry.
>
> I believe I get easily irritated due to my communication experience I
> got so far :(
>
>
> Over a year ago I reported brcmfmac can't recover from failed
> register_netdev(ice). This bug remains unfixed.
>
> In 2014 I reported problem with 80 MHz support. I didn't have hardware
> to fix & test it on my own (you weren't able/allowed to send me one of
> your PCIe cards). In remained broken until I fixed it year later.
>
> You missed my crash bug report about caused by missing eth_type_trans
> and came with patch on your own a month later.
>
> Earlier this year I reported you problem with BCM4366 and multiple
> interfaces. I didn't get much help. 3 months later I came with patch
> to workaround the problem but you said there's a better way to do
> this. It took me 2 weeks to figure out a new wlioctl API for that
> while all I needed was a simple hint on "interface_remove".
>
> Right now I'm waiting to get any answer from you about 4366c0
> firmware. It's still less than 2 weeks since I asked for it, but a
> simple ETA would be nice. I'm actually not sure if I should report
> more problems to you to don't distract you from pending things.
This is a difficult question. All upstream firmware releases for router
chips are put on hold until further notice. Some decisions have been
made, but I have not seen a detailed plan to give an ETA.
> Problems with brcmf_netdev_wait_pend8021x were reported multiples
> times for last few months. When I finally got time for that it took me
> a week to debug them.
For the pend8021x you were sending a number of messages showing debug
progress so not sure whether you wanted our feedback on that. If so a
ping might have done it.
> As you can see, it takes me months to get help on some things. And in
> few cases I never got much help at all. Yes, I was hoping to have you
> more involved into brcmfmac development and problems solving. I guess
> things didn't meet my expectations and I got grumpy & preachy.
Thanks for listing all our failures. Somehow we are very good at getting
each other grumpy. When we provide a patch and you break it up and
submit that to Kalle, we get grumpy and it all piles up to the point
where we have this kind of conversation. As long as it helps to get
things of our chest I can live with that. Hope you can too. We strive to
give support to the community, but the priority is low as it is not
full-time activity.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Felix Fietkau @ 2016-09-30 8:48 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <201609300041.41876.arnd@arndb.de>
On 2016-09-30 00:41, Arnd Bergmann wrote:
> On Thursday 29 September 2016, Felix Fietkau wrote:
>> On 2016-09-08 12:54, Kalle Valo wrote:
>> > Felix Fietkau <nbd@nbd.name> writes:
>> >
>> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> >> ---
>> >> .../bindings/net/wireless/mediatek,mt76.txt | 26 ++++++++++++++++++++++
>> >> 1 file changed, 26 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> >> new file mode 100644
>> >> index 0000000..d51c35f
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>> >> @@ -0,0 +1,26 @@
>> >> +* MediaTek mt76xx devices
>> >> +
>> >> +This node provides properties for configuring the MediaTek mt76xx wireless
>> >> +device. The node is expected to be specified as a child node of the PCI
>> >> +controller to which the wireless chip is connected.
>> >> +
>> >> +Optional properties:
>> >> +
>> >> +- mac-address: See ethernet.txt in the parent directory
>> >> +- local-mac-address: See ethernet.txt in the parent directory
>> >> +- mediatek,2ghz: Override the 2.4 GHz band capability from EEPROM
>> >> +- mediatek,5ghz: Override the 5 GHz band capability from EEPROM
>> >> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
>> >> +
>> >> +&pcie {
>> >> + status = "okay";
>> >> +
>> >> + pcie0 {
>> >> + mt76@0,0 {
>> >> + reg = <0x0000 0 0 0 0>;
>
> Maybe have an examplep of a real register address other than zero?
This is a real example referring to the first device on a PCI bus.
I copy&pasted this from a .dts file that we use in LEDE.
>> >> + device_type = "pci";
>> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
>> >> + mediatek,2ghz = <0>;
>
> It's not clear what the possible values for the 2ghz property are,
> can you be more verbose in the description? How is <0> different
> from no property?
0 means disabled, no property means unchanged (compared to EEPROM).
- Felix
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: cache the only AP_VLAN station
From: Johannes Berg @ 2016-09-30 9:47 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless
In-Reply-To: <1474821596-12155-4-git-send-email-michael-dev@fami-braun.de>
On Sun, 2016-09-25 at 18:39 +0200, Michael Braun wrote:
> If an AP_VLAN is only used with one station, cache a pointer to this
> station to avoid lookup. This should speed up station lookup when
"should speed up"? Do you have numbers to back that up?
Read this as - you need to do more to convince me that the double
accounting and software complexity is worth it.
And then, if we really want/need to have the double accounting and all
the associated complexity and potential problems, perhaps making per-
interface lists, perhaps even replacing the global list (since we still
have a global hash table), or something similar would make more sense?
johannes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-30 10:01 UTC (permalink / raw)
To: Michael Braun
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
linux-wireless, projekt-wlan
In-Reply-To: <1475075672-30549-1-git-send-email-michael-dev@fami-braun.de>
A few more things:
First of all - there's nothing specific to "AP interfaces", which you
say in the subject, as far as I can tell? That should be removed?
On Wed, 2016-09-28 at 17:14 +0200, Michael Braun wrote:
> When using WPA security, the station and thus the required key is
> identified by its mac address when packets are received. So a
> station usually cannot spoof its source mac address.
>
> But when a station sends an A-MSDU frame, port control and crypto
> is done using the outer mac address, while the packets delivered
> and forwarded use the inner mac address.
>
> IEEE 802.11-2012 mandates that the outer source mac address should
> match the inner source address (section 8.3.2.2). For the
> destination mac address, matching is not required (section 10.23.15).
I think this is wrong. As we do not support DMS (yet), we should adhere
to 8.3.2.2 and only accept matching TA/SA and DA/RA.
And even when we add DMS, we should also restrict it to multicast
addresses, but that's future work anyway.
> > - if (ieee80211_data_to_8023(pkt, vif->addr, vif->type))
> > + if (ieee80211_data_to_8023(pkt, NULL, vif->addr,
> > + vif->type))
indentation is bad here - consider running checkpatch
> static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
> > - struct sk_buff *skb)
> > + struct sk_buff *skb,
> > + const u8 *ta)
[... more mwifiex changes ...]
It's great that you're doing this, but I think this patch should only
carry the bare minimum change for mwifiex to keep it compiling, with a
follow-up patch that actually implements the correct checks. That way,
should any issues arise, it's easier to determine where the problem is
and to fix/revert it.
> diff --git a/drivers/staging/rtl8723au/core/rtw_recv.c b/drivers/staging/rtl8723au/core/rtw_recv.c
> index 150dabc..38ba7dd 100644
> --- a/drivers/staging/rtl8723au/core/rtw_recv.c
> +++ b/drivers/staging/rtl8723au/core/rtw_recv.c
> @@ -1687,7 +1687,7 @@ int amsdu_to_msdu(struct rtw_adapter *padapter, struct recv_frame *prframe)
> > skb_pull(skb, prframe->attrib.hdrlen);
> > __skb_queue_head_init(&skb_list);
>
> > - ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, false);
> > + ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, pattrib->ta);
A bit debatable here, but I'd actually also prefer you add NULL here
first and then submit a separate patch that puts the right thing.
Not that it actually matters, since this driver has been removed
already... since you have to resubmit anyway though, I'd prefer you
just put NULL, and then not worry about it from there on.
> > - if (has_80211_header) {
> > - err = __ieee80211_data_to_8023(skb, ð, addr, iftype);
> > - if (err)
> > - goto out;
> > - }
Good approach to split that :)
> > + if (unlikely(ta &&
> > + (iftype == NL80211_IFTYPE_AP ||
> > + iftype == NL80211_IFTYPE_AP_VLAN) &&
> > + !ether_addr_equal(ta, eth.h_source)
> > + ))
> > + goto purge;
Coding style here is very odd. All those closing parens should be on
the line before.
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
From: Johannes Berg @ 2016-09-30 10:27 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <20160922170420.5193-3-toke@toke.dk>
Hi Toke,
Sorry for the delay reviewing this.
I think I still have a few comments/questions.
> +static inline bool txq_has_queue(struct ieee80211_txq *txq)
> +{
> + struct txq_info *txqi = to_txq_info(txq);
> + return !(skb_queue_empty(&txqi->frags) && !txqi->tin.backlog_packets);
> +}
Tiny nit - there should probably be a blank line between the two lines
here, but I could just fix that when I apply if you don't resend anyway
for some other reason.
[snip helper stuff that looks fine]
> - if (!tx->sta->sta.txq[0])
> - hdr->seq_ctrl = ieee80211_tx_next_seq(tx->sta, tid);
> + hdr->seq_ctrl = ieee80211_tx_next_seq(tx->sta, tid);
Just to make sure I get this right - this is because the handler is now
run on dequeue, so the special case is no longer needed?
> #define CALL_TXH(txh) \
> @@ -1656,6 +1684,31 @@ static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
> if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
> CALL_TXH(ieee80211_tx_h_rate_ctrl);
Just for reference - the code block here that's unchanged contains
this:
CALL_TXH(ieee80211_tx_h_dynamic_ps);
CALL_TXH(ieee80211_tx_h_check_assoc);
CALL_TXH(ieee80211_tx_h_ps_buf);
CALL_TXH(ieee80211_tx_h_check_control_port_protocol);
CALL_TXH(ieee80211_tx_h_select_key);
if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
CALL_TXH(ieee80211_tx_h_rate_ctrl);
> +static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)
> +{
> + struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
> + ieee80211_tx_result res = TX_CONTINUE;
> +
> if (unlikely(info->flags &
> IEEE80211_TX_INTFL_RETRANSMISSION)) {
> __skb_queue_tail(&tx->skbs, tx->skb);
> tx->skb = NULL;
And this code here is also unchanged from the original TX handler
invocation, so contains this:
if (unlikely(info->flags & IEEE80211_TX_INTFL_RETRANSMISSION)) {
__skb_queue_tail(&tx->skbs, tx->skb);
tx->skb = NULL;
goto txh_done;
}
CALL_TXH(ieee80211_tx_h_michael_mic_add);
CALL_TXH(ieee80211_tx_h_sequence);
CALL_TXH(ieee80211_tx_h_fragment);
/* handlers after fragment must be aware of tx info fragmentation! */
CALL_TXH(ieee80211_tx_h_stats);
CALL_TXH(ieee80211_tx_h_encrypt);
if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
CALL_TXH(ieee80211_tx_h_calculate_duration);
But now you have a problem (that you solved) that the key pointer can
be invalidated while you have the packet queued between the two points,
and then the tx_h_michael_mic_add and/or tx_h_encrypt would crash.
You solve this by re-running tx_h_select_key() on dequeue, but it's not
clear to me why you didn't move that to the late handlers instead?
I *think* it should commute with the rate control handler, but even so,
wouldn't it make more sense to have rate control late? Assuming the
packets are queued for some amount of time, having rate control
information queued with them would get stale.
Similarly, it seems to me that checking the control port protocol later
(or perhaps duplicating that?) would be a good idea?
> +/*
> + * Can be called while the sta lock is held. Anything that can cause
> packets to
> + * be generated will cause deadlock!
> + */
> +static bool ieee80211_xmit_fast_finish(struct ieee80211_sub_if_data
> *sdata,
> + struct sta_info *sta, u8
> pn_offs,
> + struct ieee80211_key *key,
> + struct sk_buff *skb)
That should be a void function now, you never check the return value
and only return true anyway.
> + struct ieee80211_tx_info *info;
> + struct ieee80211_tx_data tx;
> + ieee80211_tx_result r;
> +
nit: extra blank line
> spin_lock_bh(&fq->lock);
>
> if (test_bit(IEEE80211_TXQ_STOP, &txqi->flags))
> goto out;
>
> + /* Make sure fragments stay together. */
> + skb = __skb_dequeue(&txqi->frags);
> + if (skb)
> + goto out;
> +
> +begin:
I guess now that you introduced that anyway, we should consider making
the skb_linearize() failure go there. Should be a follow-up patch
though.
> + /*
> + * The key can be removed while the packet was queued, so
> need to call
> + * this here to get the current key.
> + */
> + r = ieee80211_tx_h_select_key(&tx);
> + if (r != TX_CONTINUE) {
> + ieee80211_free_txskb(&local->hw, skb);
> + goto begin;
> + }
> +
> + if (txq->sta && info->control.flags & IEEE80211_TX_CTRL_FAST_XMIT) {
It's a bit unfortunate that you lose fast-xmit here completely for the
key stuff, but I don't see a good way to avoid that, other than
completely rejiggering all the (possibly affected) queues when keys
change... might be very complex to do that, certainly a follow-up patch
if it's desired.
This check seems a bit weird though - how could fast-xmit be set
without a TXQ station?
> +++ b/net/mac80211/util.c
> @@ -3393,11 +3393,18 @@ void ieee80211_txq_get_depth(struct
> ieee80211_txq *txq,
> unsigned long *byte_cnt)
> {
> struct txq_info *txqi = to_txq_info(txq);
> + u32 frag_cnt = 0, frag_bytes = 0;
> + struct sk_buff *skb;
> +
> + skb_queue_walk(&txqi->frags, skb) {
> + frag_cnt++;
> + frag_bytes += skb->len;
> + }
I hope this is called infrequently :)
johannes
^ permalink raw reply
* Re: [PATCH v9 1/2] mac80211: Move ieee802111_tx_dequeue() to later in tx.c
From: Johannes Berg @ 2016-09-30 11:13 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <20160922170420.5193-2-toke@toke.dk>
On Thu, 2016-09-22 at 19:04 +0200, Toke Høiland-Jørgensen wrote:
> The TXQ path restructure requires ieee80211_tx_dequeue() to call TX
> handlers and parts of the xmit_fast path. Move the function to later
> in tx.c in preparation for this.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Add support for static WEP in the driver
From: Johannes Berg @ 2016-09-30 11:19 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, David Spinadel, Luca Coelho
In-Reply-To: <20160922201650.16722-1-luca@coelho.fi>
On Thu, 2016-09-22 at 23:16 +0300, Luca Coelho wrote:
> From: David Spinadel <david.spinadel@intel.com>
>
> Add support for drivers that implement static WEP internally, i.e.
> expose connection keys to the driver in connect flow and don't
> upload the keys after the connection.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH v3 1/9] cfg80211: add start / stop NAN commands
From: Johannes Berg @ 2016-09-30 11:25 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, ayala.beker, andrei.otcheretianski,
arend.vanspriel, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160920143121.28247-2-luca@coelho.fi>
All applied.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox