pull request: iwlwifi 2015-12-16

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request with small fixes for 4.4.
Note that due to the large number of files being renamed, you need to
set merge.renameLimit to a big number to merge wl-drv into wl-drv-next
but you probably noticed that already :)

The following changes since commit 9513c5e18a0dc55a1fc9c890715098ba2315830b:

  iwlwifi: mvm: Avoid dereferencing sta if it was already flushed
(2015-11-15 21:18:01 +0200)

are available in the git repository at:

 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2015-12-16

for you to fetch changes up to 4585436091cd812b1165aab71bd4847ea1cb08ec:

  iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id
(2015-12-13 13:38:26 +0200)


* don't load firmware that won't exist for 7260
* fix RCU splat


Johannes Berg (2):
  iwlwifi: separate firmware version for 7260 devices
  iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

 drivers/net/wireless/iwlwifi/iwl-7000.c | 49
+++--
 drivers/net/wireless/iwlwifi/mvm/sta.c  | 15 +--
 2 files changed, 44 insertions(+), 20 deletions(-)

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

Re: [PATCH] nl80211: Potential memory leaks in reg.c

[Ola Olsson]

> I'm just surprised that none of the tools we (and others) typically run
> found these, and thought perhaps you had a better tool than we do...
> I guess it's called "brain" and we just don't use it right ;-)

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Johannes Berg]

On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:
> This patch below was added to the kernel around 2/24/2015
> 
> I am curious mostly about the first change:  I thought the
> transmitter-addr relates to the radio device, not the vdev (sta, ap,
> etc).

It doesn't, even on real hardware.

> But, wouldn't using data from the header break that assumption?
> 
> 
> Is there any actual advantage to having more than one address per
> hwsim radio?  It seems it complicates things for no particular
> reason as far as I can tell?
> 

??
You can do this with any regular hardware that supports multiple
virtual interfaces - each one of them gets its own address.

I think you might be confused by how ath*k implements the address
matching - as I understand it there it's a common address (which may or
may not match the programmed hardware address) along with a mask.
That's not true in general though.

The hwsim commit here just makes wmediumd able to behave properly when
the user changed the vif interface address.

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

re: mwifiex: add support for Marvell USB8797 chipset

[Dan Carpenter]

Hello Amitkumar Karwar,

The patch 4daffe354366: "mwifiex: add support for Marvell USB8797
chipset" from Apr 18, 2012, leads to the following static checker
warning:

drivers/net/wireless/marvell/mwifiex/usb.c:1108 
mwifiex_prog_fw_w_helper()
warn: should this be 'retries == -1'

drivers/net/wireless/marvell/mwifiex/usb.c
   993  static int mwifiex_prog_fw_w_helper(struct mwifiex_adapter *adapter,
   994  struct mwifiex_fw_image *fw)
   995  {
   996  int ret = 0;
   997  u8 *firmware = fw->fw_buf, *recv_buff;
   998  u32 retries = USB8XXX_FW_MAX_RETRY, dlen;
^^
retries starts set to 3.

   999  u32 fw_seqnum = 0, tlen = 0, dnld_cmd = 0;
  1000  struct fw_data *fwdata;
  1001  struct fw_sync_header sync_fw;
  1002  u8 check_winner = 1;
  1003  
  1004  if (!firmware) {
  1005  mwifiex_dbg(adapter, ERROR,
  1006  "No firmware image found! Terminating 
download\n");
  1007  ret = -1;
  1008  goto fw_exit;
  1009  }
  1010  
  1011  /* Allocate memory for transmit */
  1012  fwdata = kzalloc(FW_DNLD_TX_BUF_SIZE, GFP_KERNEL);
  1013  if (!fwdata) {
  1014  ret = -ENOMEM;
  1015  goto fw_exit;
  1016  }
  1017  
  1018  /* Allocate memory for receive */
  1019  recv_buff = kzalloc(FW_DNLD_RX_BUF_SIZE, GFP_KERNEL);
  1020  if (!recv_buff)
  1021  goto cleanup;
  1022  
  1023  do {
  1024  /* Send pseudo data to check winner status first */
  1025  if (check_winner) {
  1026  memset(&fwdata->fw_hdr, 0, sizeof(struct 
fw_header));
  1027  dlen = 0;
  1028  } else {
  1029  /* copy the header of the fw_data to get the 
length */
  1030  memcpy(&fwdata->fw_hdr, &firmware[tlen],
  1031 sizeof(struct fw_header));
  1032  
  1033  dlen = le32_to_cpu(fwdata->fw_hdr.data_len);
  1034  dnld_cmd = le32_to_cpu(fwdata->fw_hdr.dnld_cmd);
  1035  tlen += sizeof(struct fw_header);
  1036  
  1037  memcpy(fwdata->data, &firmware[tlen], dlen);
  1038  
  1039  fwdata->seq_num = cpu_to_le32(fw_seqnum);
  1040  tlen += dlen;
  1041  }
  1042  
  1043  /* If the send/receive fails or CRC occurs then retry */
  1044  while (retries--) {

Because this is a postop the loop ends when retries is UINT_MAX.

  1045  u8 *buf = (u8 *)fwdata;
  1046  u32 len = FW_DATA_XMIT_SIZE;
  1047  
  1048  /* send the firmware block */
  1049  ret = mwifiex_write_data_sync(adapter, buf, 
&len,
  1050  
MWIFIEX_USB_EP_CMD_EVENT,
  1051  MWIFIEX_USB_TIMEOUT);
  1052  if (ret) {
  1053  mwifiex_dbg(adapter, ERROR,
  1054  "write_data_sync: failed: 
%d\n",
  1055  ret);
  1056  continue;

If this fails 3 times for example.

  1057  }
  1058  
  1059  buf = recv_buff;
  1060  len = FW_DNLD_RX_BUF_SIZE;
  1061  
  1062  /* Receive the firmware block response */
  1063  ret = mwifiex_read_data_sync(adapter, buf, &len,
  1064  
MWIFIEX_USB_EP_CMD_EVENT,
  1065  MWIFIEX_USB_TIMEOUT);
  1066  if (ret) {
  1067  mwifiex_dbg(adapter, ERROR,
  1068  "read_data_sync: failed: 
%d\n",
  1069  ret);
  1070  continue;

Or this.


  1071  }
  1072  
  1073  memcpy(&sync_fw, recv_buff,
  1074 sizeof(struct fw_sync_header));
  1075  
  1076  /* check 1st firmware block resp for highest 
bit set */
  1077  if (check_winner) {
  1078  if (le32_to_cpu(sync_fw.cmd) & 
0x8000) {
  1079  mwifiex_dbg(adapter, WARN,
  1080  "USB is not the 
winner %#x\n",
  1081 

[patch] wil6210: fix a warning message condition

[Dan Carpenter]

"iter" is -1 at the end of the loop and not zero.  It means we don't
print a warning message.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index 48687f1..4544e8c 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -985,7 +985,7 @@ int __wil_down(struct wil6210_priv *wil)
}
mutex_lock(&wil->mutex);
 
-   if (!iter)
+   if (iter < 0)
wil_err(wil, "timeout waiting for idle FW/HW\n");
 
wil_reset(wil, false);
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] mwifiex: fix potential integer truncation

[Amitkumar Karwar]

From: chunfan chen 

At some places, ie length is truncated from u16 to u8 while
storing it to driver's internal variable. This patch fixes
the problem.

Signed-off-by: chunfan chen 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/main.h  | 6 +++---
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 0fa1d8e..2f7f478 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -564,14 +564,14 @@ struct mwifiex_private {
struct mwifiex_wep_key wep_key[NUM_WEP_KEYS];
u16 wep_key_curr_index;
u8 wpa_ie[256];
-   u8 wpa_ie_len;
+   u16 wpa_ie_len;
u8 wpa_is_gtk_set;
struct host_cmd_ds_802_11_key_material aes_key;
struct host_cmd_ds_802_11_key_material_v2 aes_key_v2;
u8 wapi_ie[256];
-   u8 wapi_ie_len;
+   u16 wapi_ie_len;
u8 *wps_ie;
-   u8 wps_ie_len;
+   u16 wps_ie_len;
u8 wmm_required;
u8 wmm_enabled;
u8 wmm_qosinfo;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c 
b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index 439e73f..6a4fc5d 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -759,7 +759,7 @@ static int mwifiex_set_wpa_ie_helper(struct mwifiex_private 
*priv,
return -1;
}
memcpy(priv->wpa_ie, ie_data_ptr, ie_len);
-   priv->wpa_ie_len = (u8) ie_len;
+   priv->wpa_ie_len = ie_len;
mwifiex_dbg(priv->adapter, CMD,
"cmd: Set Wpa_ie_len=%d IE=%#x\n",
priv->wpa_ie_len, priv->wpa_ie[0]);
-- 
1.8.1.4

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

[PATCH 3/4] mwifiex: add missing check for PCIe8997 chipset

[Amitkumar Karwar]

This patch ensures mwifiex_pcie_txbd_empty() does take care
of 8997 chipset.

Fixes: 6d85ef00d9dfe ("mwifiex: add support for 8997 chipset")
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 7db46ee..347ba45 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -342,6 +342,7 @@ mwifiex_pcie_txbd_empty(struct pcie_service_card *card, u32 
rdptr)
return 1;
break;
case PCIE_DEVICE_ID_MARVELL_88W8897:
+   case PCIE_DEVICE_ID_MARVELL_88W8997:
if (((card->txbd_wrptr & reg->tx_mask) ==
 (rdptr & reg->tx_mask)) &&
((card->txbd_wrptr & reg->tx_rollover_ind) ==
-- 
1.8.1.4

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

[PATCH 2/4] mwifiex: fix PCIe register information for 8997 chipset

[Amitkumar Karwar]

This patch corrects some information in mwifiex_pcie_card_reg()
structure for 8997 chipset

Fixes: 6d85ef00d9dfe ("mwifiex: add support for 8997 chipset")
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Shengzhen Li 
---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 48e549c..7db46ee 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -210,17 +210,17 @@ static const struct mwifiex_pcie_card_reg 
mwifiex_reg_8997 = {
.cmdrsp_addr_lo = PCIE_SCRATCH_4_REG,
.cmdrsp_addr_hi = PCIE_SCRATCH_5_REG,
.tx_rdptr = 0xC1A4,
-   .tx_wrptr = 0xC1A8,
-   .rx_rdptr = 0xC1A8,
+   .tx_wrptr = 0xC174,
+   .rx_rdptr = 0xC174,
.rx_wrptr = 0xC1A4,
.evt_rdptr = PCIE_SCRATCH_10_REG,
.evt_wrptr = PCIE_SCRATCH_11_REG,
.drv_rdy = PCIE_SCRATCH_12_REG,
.tx_start_ptr = 16,
.tx_mask = 0x0FFF,
-   .tx_wrap_mask = 0x01FF,
+   .tx_wrap_mask = 0x1FFF,
.rx_mask = 0x0FFF,
-   .rx_wrap_mask = 0x01FF,
+   .rx_wrap_mask = 0x1FFF,
.tx_rollover_ind = BIT(28),
.rx_rollover_ind = BIT(12),
.evt_rollover_ind = MWIFIEX_BD_FLAG_EVT_ROLLOVER_IND,
-- 
1.8.1.4

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

[PATCH 4/4] mwifiex: enable MSI interrupt support in pcie

[Amitkumar Karwar]

From: Avinash Patil 

Newer pcie devices (8897 onwards) support MSI. This
patch enables it.

Signed-off-by: Avinash Patil 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 33 ++---
 drivers/net/wireless/marvell/mwifiex/pcie.h |  1 +
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 21192b6..9703848 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2599,6 +2599,30 @@ static void mwifiex_pcie_cleanup(struct mwifiex_adapter 
*adapter)
kfree(card);
 }
 
+static int mwifiex_pcie_request_irq(struct mwifiex_adapter *adapter)
+{
+   int ret;
+   struct pcie_service_card *card = adapter->card;
+   struct pci_dev *pdev = card->dev;
+
+   if (pci_enable_msi(pdev) != 0)
+   pci_disable_msi(pdev);
+   else
+   card->msi_enable = 1;
+
+   mwifiex_dbg(adapter, INFO, "msi_enable = %d\n", card->msi_enable);
+
+   ret = request_irq(pdev->irq, mwifiex_pcie_interrupt, IRQF_SHARED,
+ "MRVL_PCIE", pdev);
+   if (ret) {
+   pr_err("request_irq failed: ret=%d\n", ret);
+   adapter->card = NULL;
+   return -1;
+   }
+
+   return 0;
+}
+
 /*
  * This function registers the PCIE device.
  *
@@ -2606,21 +2630,14 @@ static void mwifiex_pcie_cleanup(struct mwifiex_adapter 
*adapter)
  */
 static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
 {
-   int ret;
struct pcie_service_card *card = adapter->card;
struct pci_dev *pdev = card->dev;
 
/* save adapter pointer in card */
card->adapter = adapter;
 
-   ret = request_irq(pdev->irq, mwifiex_pcie_interrupt, IRQF_SHARED,
- "MRVL_PCIE", pdev);
-   if (ret) {
-   mwifiex_dbg(adapter, ERROR,
-   "request_irq failed: ret=%d\n", ret);
-   adapter->card = NULL;
+   if (mwifiex_pcie_request_irq(adapter))
return -1;
-   }
 
adapter->dev = &pdev->dev;
adapter->tx_buf_size = card->pcie.tx_buf_size;
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 347ba45..6fc2873 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -326,6 +326,7 @@ struct pcie_service_card {
dma_addr_t sleep_cookie_pbase;
void __iomem *pci_mmap;
void __iomem *pci_mmap1;
+   int msi_enable;
 };
 
 static inline int
-- 
1.8.1.4

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

RE: [patch] wil6210: fix a warning message condition

[Haim, Maya]

Acked-by: Maya Erez 

-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com] 
Sent: Wednesday, December 16, 2015 1:10 PM
To: qca_merez
Cc: Kalle Valo; linux-wireless@vger.kernel.org; wil6210; 
kernel-janit...@vger.kernel.org
Subject: [patch] wil6210: fix a warning message condition

"iter" is -1 at the end of the loop and not zero.  It means we don't print a 
warning message.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index 48687f1..4544e8c 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -985,7 +985,7 @@ int __wil_down(struct wil6210_priv *wil)
}
mutex_lock(&wil->mutex);
 
-   if (!iter)
+   if (iter < 0)
wil_err(wil, "timeout waiting for idle FW/HW\n");
 
wil_reset(wil, false);
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 01:17 AM, Johannes Berg wrote:

On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:

This patch below was added to the kernel around 2/24/2015

I am curious mostly about the first change:  I thought the
transmitter-addr relates to the radio device, not the vdev (sta, ap,
etc).


It doesn't, even on real hardware.


No, I mean that the HWSIM_ATTR_ADDR_TRANSMITTER should relate to the
radio, and not the vdev, see the mac80211_hwsim.h:

 * @HWSIM_ATTR_ADDR_TRANSMITTER: MAC address of the radio device that
 *  the frame was broadcasted from




But, wouldn't using data from the header break that assumption?


Is there any actual advantage to having more than one address per
hwsim radio?  It seems it complicates things for no particular
reason as far as I can tell?



??
You can do this with any regular hardware that supports multiple
virtual interfaces - each one of them gets its own address.

I think you might be confused by how ath*k implements the address
matching - as I understand it there it's a common address (which may or
may not match the programmed hardware address) along with a mask.
That's not true in general though.


Since we are asking user-space to provide HWSIM_ATTR_ADDR_TRANSMITTER,
then we can use that to find the radio device.  Then, normal mac80211
logic can handle finding the vdevs (just as it does for ath9k).

And in this case, there is no reason to have more than one address
associated with the hwsim radio device.  We could add a pretty simple
hash to keep the lookup near constant time instead of linear search
as the current behaviour is...


The hwsim commit here just makes wmediumd able to behave properly when
the user changed the vif interface address.


I think that wmediumd should keep it's own mapping of what radio
a vdev is on and use the proper hwsim radio addr for the 
HWSIM_ATTR_ADDR_TRANSMITTER
attribute.

Thanks,
Ben



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




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: question on "mac80211_hwsim: support any address in userspace"

[m...@bobcopeland.com >> Bob Copeland]

On Tue, Dec 15, 2015 at 07:29:30PM -0800, Ben Greear wrote:
> This patch below was added to the kernel around 2/24/2015
> 
> I am curious mostly about the first change:  I thought the transmitter-addr
> relates to the radio device, not the vdev (sta, ap, etc).
> 
> But, wouldn't using data from the header break that assumption?

I'm not sure this assumption is correct.  I have a hard time
seeing the value in basing the transmitter addr attribute on some
hardware address that may not even be used.

> Is there any actual advantage to having more than one address per
> hwsim radio?  It seems it complicates things for no particular
> reason as far as I can tell?

As a practical matter: the radios already have two "hardware"
addresses, and as reported in the commit log, only one of them
worked with the netlink interface, and it wasn't even the default
address.

I suppose there's no real benefit to multi-vif on hwsim vs multiple
phys, other than testing multi-vif support in the stack, but why not?
I think this patch actually simplifies things.

Does this patch cause problems for your userspace implementation?

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

[PATCH] staging: rtl8723au: hal: rtl8723a_hal_init: fixed 4 spelling errors.

[Jiading Gai]

Fixed four spelling errors.

Signed-off-by: Jiading Gai 
---
 drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c 
b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
index ecf54ee..e3dc889 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
@@ -1044,7 +1044,7 @@ void rtl8723a_InitAntenna_Selection(struct rtw_adapter 
*padapter)
u8 val;
 
val = rtl8723au_read8(padapter, REG_LEDCFG2);
-   /*  Let 8051 take control antenna settting */
+   /*  Let 8051 take control antenna setting */
val |= BIT(7);  /*  DPDT_SEL_EN, 0x4C[23] */
rtl8723au_write8(padapter, REG_LEDCFG2, val);
 }
@@ -1054,7 +1054,7 @@ void rtl8723a_CheckAntenna_Selection(struct rtw_adapter 
*padapter)
u8 val;
 
val = rtl8723au_read8(padapter, REG_LEDCFG2);
-   /*  Let 8051 take control antenna settting */
+   /*  Let 8051 take control antenna setting */
if (!(val & BIT(7))) {
val |= BIT(7);  /*  DPDT_SEL_EN, 0x4C[23] */
rtl8723au_write8(padapter, REG_LEDCFG2, val);
@@ -1066,7 +1066,7 @@ void rtl8723a_DeinitAntenna_Selection(struct rtw_adapter 
*padapter)
u8 val;
 
val = rtl8723au_read8(padapter, REG_LEDCFG2);
-   /*  Let 8051 take control antenna settting */
+   /*  Let 8051 take control antenna setting */
val &= ~BIT(7); /*  DPDT_SEL_EN, clear 0x4C[23] */
rtl8723au_write8(padapter, REG_LEDCFG2, val);
 }
@@ -1297,7 +1297,7 @@ static void _ResetDigitalProcedure1_92C(struct 
rtw_adapter *padapter,
/*  If we want to SS mode, we can not reset 8051. */
if ((val8 & BIT(1)) && padapter->bFWReady) {
/* IF fw in RAM code, do reset */
-   /*  2010/08/25 MH Accordign to RD alfred's
+   /*  2010/08/25 MH According to RD alfred's
suggestion, we need to disable other */
/*  HRCV INT to influence 8051 reset. */
rtl8723au_write8(padapter, REG_FWIMR, 0x20);
-- 
1.9.1

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Johannes Berg]

On Wed, 2015-12-16 at 05:13 -0800, Ben Greear wrote:
> On 12/16/2015 01:17 AM, Johannes Berg wrote:
> > On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:
> > > This patch below was added to the kernel around 2/24/2015
> > > 
> > > I am curious mostly about the first change:  I thought the
> > > transmitter-addr relates to the radio device, not the vdev (sta,
> > > ap,
> > > etc).
> > 
> > It doesn't, even on real hardware.
> 
> No, I mean that the HWSIM_ATTR_ADDR_TRANSMITTER should relate to the
> radio, and not the vdev, see the mac80211_hwsim.h:
> 
>   * @HWSIM_ATTR_ADDR_TRANSMITTER: MAC address of the radio device that
>   *   the frame was broadcasted from

I think that just means the documentation is misleading. Clearly, the
TA (hdr->addr2) is intended and implemented. "radio device" is a bit of
a misleading term when you have virtual interfaces.

> Since we are asking user-space to provide HWSIM_ATTR_ADDR_TRANSMITTER,
> then we can use that to find the radio device.  Then, normal mac80211
> logic can handle finding the vdevs (just as it does for ath9k).

Oh.

So you're basically arguing that we should treat it as a cookie, and on
outgoing frames give the hardware address, and on incoming frames use
it only to look up the struct mac80211_hwsim_data.

> And in this case, there is no reason to have more than one address
> associated with the hwsim radio device.  We could add a pretty simple
> hash to keep the lookup near constant time instead of linear search
> as the current behaviour is...

Yeah, ok, that would be (have been) doable I guess. We'd still have the
real TA in the frame itself (hdr->addr2).

> I think that wmediumd should keep it's own mapping of what radio
> a vdev is on and use the proper hwsim radio addr for the
> HWSIM_ATTR_ADDR_TRANSMITTER attribute.

That's somewhat difficult for it, since it could only populate that
mapping on actual TX frames.

I think this is pretty much a done deal by now though since I don't
really want to break wmediumd.

If we wanted to go this route I think we should be more explicit and
simply use the HWSIM_ATTR_RADIO_ID attribute. We could support that
easily - just see if the RADIO_ID is present and look up the
transmitter (or receiver btw) radio based on the RADIO_ID if present -
that gives a clean path forward too since wmediumd can be taught to
specify both knowing the kernel will prefer the radio ID if present.

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 05:21 AM, m...@bobcopeland.com >> Bob Copeland wrote:

On Tue, Dec 15, 2015 at 07:29:30PM -0800, Ben Greear wrote:

This patch below was added to the kernel around 2/24/2015

I am curious mostly about the first change:  I thought the transmitter-addr
relates to the radio device, not the vdev (sta, ap, etc).

But, wouldn't using data from the header break that assumption?


I'm not sure this assumption is correct.  I have a hard time
seeing the value in basing the transmitter addr attribute on some
hardware address that may not even be used.


Imagine you have 20 virtual radios, and you want to send a beacon (or
other broadcast) to just one radio.

You can use the radio transmitter-addr to let the kernel know which
virtual radio receives the packet.




Is there any actual advantage to having more than one address per
hwsim radio?  It seems it complicates things for no particular
reason as far as I can tell?


As a practical matter: the radios already have two "hardware"
addresses, and as reported in the commit log, only one of them
worked with the netlink interface, and it wasn't even the default
address.

I suppose there's no real benefit to multi-vif on hwsim vs multiple
phys, other than testing multi-vif support in the stack, but why not?
I think this patch actually simplifies things.


As long as you do a mapping in wmediumd, there should be no problem
at all with multiple vifs on a radio.  The HWSIM_ATTR_ADDR_TRANSMITTER
is just a key to let us know which radio we are talking about.  It
never needs to be 'on the air'.



Does this patch cause problems for your userspace implementation?


Yes, because I coded with the assumptions that the radio addr had nothing
to do with the vif addr.

Thanks,
Ben






--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 05:25 AM, Johannes Berg wrote:

On Wed, 2015-12-16 at 05:13 -0800, Ben Greear wrote:

On 12/16/2015 01:17 AM, Johannes Berg wrote:

On Tue, 2015-12-15 at 19:29 -0800, Ben Greear wrote:

This patch below was added to the kernel around 2/24/2015

I am curious mostly about the first change:  I thought the
transmitter-addr relates to the radio device, not the vdev (sta,
ap,
etc).


It doesn't, even on real hardware.


No, I mean that the HWSIM_ATTR_ADDR_TRANSMITTER should relate to the
radio, and not the vdev, see the mac80211_hwsim.h:

   * @HWSIM_ATTR_ADDR_TRANSMITTER: MAC address of the radio device that
   *the frame was broadcasted from


I think that just means the documentation is misleading. Clearly, the
TA (hdr->addr2) is intended and implemented. "radio device" is a bit of
a misleading term when you have virtual interfaces.


Well, the old code used it as a key, and the old documentation used
it as a key, so it is a bit of a regression to change the behaviour
now.


Since we are asking user-space to provide HWSIM_ATTR_ADDR_TRANSMITTER,
then we can use that to find the radio device.  Then, normal mac80211
logic can handle finding the vdevs (just as it does for ath9k).


Oh.

So you're basically arguing that we should treat it as a cookie, and on
outgoing frames give the hardware address, and on incoming frames use
it only to look up the struct mac80211_hwsim_data.


yes.




And in this case, there is no reason to have more than one address
associated with the hwsim radio device.  We could add a pretty simple
hash to keep the lookup near constant time instead of linear search
as the current behaviour is...


Yeah, ok, that would be (have been) doable I guess. We'd still have the
real TA in the frame itself (hdr->addr2).


I think that wmediumd should keep it's own mapping of what radio
a vdev is on and use the proper hwsim radio addr for the
HWSIM_ATTR_ADDR_TRANSMITTER attribute.


That's somewhat difficult for it, since it could only populate that
mapping on actual TX frames.


It can also be managed by an outside entity to set up mappings
as needed.  And, it could be made smarter to listen to wifi
netlink events or whatever.

And anyway, unless you are doing all passive scans, you should always
get at least some packet transmitted (beacon or probe request), right?



I think this is pretty much a done deal by now though since I don't
really want to break wmediumd.


It was not the only user-space to use the API :)



If we wanted to go this route I think we should be more explicit and
simply use the HWSIM_ATTR_RADIO_ID attribute. We could support that
easily - just see if the RADIO_ID is present and look up the
transmitter (or receiver btw) radio based on the RADIO_ID if present -
that gives a clean path forward too since wmediumd can be taught to
specify both knowing the kernel will prefer the radio ID if present.


Well, that would be fine too.  The nice thing about the address,though,
is that you can query it as part of /sys/class/ieee. and other 
already-implemented
interfaces.  Finding the radio-id would require new API in this case, which
is a bit of work.

Thanks,
Ben



johannes




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Johannes Berg]

On Wed, 2015-12-16 at 05:35 -0800, Ben Greear wrote:

> Well, the old code used it as a key, and the old documentation used
> it as a key, so it is a bit of a regression to change the behaviour
> now.

But it's still used as a key, no? Just the value changed. If you treat
it as a key then you'd just have it for a frame incoming and outgoing?

> > I think this is pretty much a done deal by now though since I don't
> > really want to break wmediumd.
> 
> It was not the only user-space to use the API :)

So you're saying you have code that broke? How did it break though, I
don't really see it yet. Can you explain?

> Well, that would be fine too.  The nice thing about the
> address,though, is that you can query it as part of
> /sys/class/ieee. and other already-implemented
> interfaces.  Finding the radio-id would require new API in this case,
> which is a bit of work.

Well, it was always rather awkward since it was the *second* address :)

You can query the ID/index already through the netlink API, or even
from sysfs since the virtual device name is essentially
sprintf(name, "hwsim%d", idx)

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

[PATCH] mac80211: clear local->sched_scan_req properly on reconfig

[Emmanuel Grumbach]

From: Eliad Peller 

On reconfig, in case of sched_scan_req->n_scan_plans > 1,
local->sched_scan_req was never cleared, although
cfg80211_sched_scan_stopped_rtnl() was called, resulting
in local->sched_scan_req holding a stale and preventing
further scheduled scan requests.

Clear it explicitly in this case.

Fixes: 42a7e82c6792 ("mac80211: Do not restart scheduled scan if multiple scan 
plans are set")
Signed-off-by: Eliad Peller 
Signed-off-by: Emmanuel Grumbach 
---
 net/mac80211/util.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 0186178..884033e 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2046,8 +2046,11 @@ int ieee80211_reconfig(struct ieee80211_local *local)
 */
if (sched_scan_req->n_scan_plans > 1 ||
__ieee80211_request_sched_scan_start(sched_scan_sdata,
-sched_scan_req))
+sched_scan_req)) {
+   RCU_INIT_POINTER(local->sched_scan_sdata, NULL);
+   RCU_INIT_POINTER(local->sched_scan_req, NULL);
sched_scan_stopped = true;
+   }
mutex_unlock(&local->mtx);
 
if (sched_scan_stopped)
-- 
2.5.0

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

Re: question on "mac80211_hwsim: support any address in userspace"

[m...@bobcopeland.com >> Bob Copeland]

On Wed, Dec 16, 2015 at 05:27:44AM -0800, Ben Greear wrote:
> >Does this patch cause problems for your userspace implementation?
> 
> Yes, because I coded with the assumptions that the radio addr had nothing
> to do with the vif addr.

I see -- but looking back at wmediumd history (before I had anything to
do with it) it seems it always had the opposite assumption -- e.g. the
ATTR_ADDR_TRANSMITTER mac address was compared against addresses in the
frame for delivery decisions.

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 05:42 AM, Johannes Berg wrote:

On Wed, 2015-12-16 at 05:35 -0800, Ben Greear wrote:


Well, the old code used it as a key, and the old documentation used
it as a key, so it is a bit of a regression to change the behaviour
now.


But it's still used as a key, no? Just the value changed. If you treat
it as a key then you'd just have it for a frame incoming and outgoing?


I think this is pretty much a done deal by now though since I don't
really want to break wmediumd.


It was not the only user-space to use the API :)


So you're saying you have code that broke? How did it break though, I
don't really see it yet. Can you explain?


My code expected that the key was the MAC of the radio, not the
MAC of a vif.  It set up mappings accordingly in the user-space
program.

And, if I change a vif's mac address, the previous 'key' is no longer
valid with the new patch.  If I have multiple vifs on one radio
and want to send a broadcast pkt to that radio, then at best the
patched API is lame because you would have to specify the address
of one of the vifs on the radio, but it is not really destined for
just that vif.

A fair bit of code was written, and not just by me, against the
API that assumed the MAC of the radio was a unique key.  The
code can be changed of course, but if Bob's change does not
really offer any advantage, then I think the patch should
be reverted.

If wmediumd needs more info, then I think adding a new netlink
message or attribute is the way to go..that way it should be fully
backwards compatible.



Well, that would be fine too.  The nice thing about the
address,though, is that you can query it as part of
/sys/class/ieee. and other already-implemented
interfaces.  Finding the radio-id would require new API in this case,
which is a bit of work.


Well, it was always rather awkward since it was the *second* address :)


Yes, it was always weird, but predictably so.



You can query the ID/index already through the netlink API, or even
from sysfs since the virtual device name is essentially
sprintf(name, "hwsim%d", idx)


Good lord, please don't even suggest parsing the name.  You can easily
rename a phy device.  I do it all the time to keep a phyname associated
with a real radio through module reloads.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Johannes Berg]

On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:
> 
> > You can query the ID/index already through the netlink API, or even
> > from sysfs since the virtual device name is essentially
> > sprintf(name, "hwsim%d", idx)
> 
> Good lord, please don't even suggest parsing the name.  You can
> easily rename a phy device.  I do it all the time to keep a phyname
> associated with a real radio through module reloads.
> 

You're confusing the wiphy name and the hwsim virtual class device name
(which you can't touch) :)

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 05:57 AM, m...@bobcopeland.com >> Bob Copeland wrote:

On Wed, Dec 16, 2015 at 05:27:44AM -0800, Ben Greear wrote:

Does this patch cause problems for your userspace implementation?


Yes, because I coded with the assumptions that the radio addr had nothing
to do with the vif addr.


I see -- but looking back at wmediumd history (before I had anything to
do with it) it seems it always had the opposite assumption -- e.g. the
ATTR_ADDR_TRANSMITTER mac address was compared against addresses in the
frame for delivery decisions.


Even so, I think it is more important to keep the kernel API stable than
to work around issues in relatively obscure user-space apps.

There could of course be more than just my app and wmediumd that uses
the kernel API

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Johannes Berg]

On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:

> My code expected that the key was the MAC of the radio, not the
> MAC of a vif.  It set up mappings accordingly in the user-space
> program.
> 
> And, if I change a vif's mac address, the previous 'key' is no longer
> valid with the new patch.  If I have multiple vifs on one radio
> and want to send a broadcast pkt to that radio, then at best the
> patched API is lame because you would have to specify the address
> of one of the vifs on the radio, but it is not really destined for
> just that vif.
> 
> A fair bit of code was written, and not just by me, against the
> API that assumed the MAC of the radio was a unique key.  The
> code can be changed of course, but if Bob's change does not
> really offer any advantage, then I think the patch should
> be reverted.
> 

I guess you were trying to be much smarter than wmediumd :)

Bob, any thoughts?

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

Re: pull request: iwlwifi 2015-12-16

[Kalle Valo]

"Grumbach, Emmanuel"  writes:

> This is a pull request with small fixes for 4.4. Note that due to the
> large number of files being renamed, you need to set merge.renameLimit
> to a big number to merge wl-drv into wl-drv-next but you probably
> noticed that already :)

Actually I don't normally merge wireless-drivers to
wireless-drivers-next, that happens "automatically" the way I follow
net-next. But I'll keep this in mind, thanks.

>   iwlwifi: separate firmware version for 7260 devices

Was this patch sent for public review? I can't seem to find it.

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

RE: pull request: iwlwifi 2015-12-16

[Grumbach, Emmanuel]

> 
> "Grumbach, Emmanuel"  writes:
> 
> > This is a pull request with small fixes for 4.4. Note that due to the
> > large number of files being renamed, you need to set merge.renameLimit
> > to a big number to merge wl-drv into wl-drv-next but you probably
> > noticed that already :)
> 
> Actually I don't normally merge wireless-drivers to wireless-drivers-next, 
> that
> happens "automatically" the way I follow net-next. But I'll keep this in mind,
> thanks.
> 
> >   iwlwifi: separate firmware version for 7260 devices
> 
> Was this patch sent for public review? I can't seem to find it.
> 

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

[PATCH 1/2] iwlwifi: separate firmware version for 7260 devices

[Emmanuel Grumbach]

From: Johannes Berg 

The 7260 devices aren't going to be updated for completely new
firmware versions any more (only bugfixes), and haven't been
since API version 17. Encode that in the data structures to
avoid trying to load FW images that will never exist.

Signed-off-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/iwl-7000.c | 49 +++--
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-7000.c 
b/drivers/net/wireless/iwlwifi/iwl-7000.c
index bf88ec3..d9a4aee 100644
--- a/drivers/net/wireless/iwlwifi/iwl-7000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-7000.c
@@ -69,13 +69,19 @@
 #include "iwl-agn-hw.h"
 
 /* Highest firmware API version supported */
-#define IWL7260_UCODE_API_MAX  19
+#define IWL7260_UCODE_API_MAX  17
+#define IWL7265_UCODE_API_MAX  19
+#define IWL7265D_UCODE_API_MAX 19
 
 /* Oldest version we won't warn about */
 #define IWL7260_UCODE_API_OK   13
+#define IWL7265_UCODE_API_OK   13
+#define IWL7265D_UCODE_API_OK  13
 
 /* Lowest firmware API version supported */
 #define IWL7260_UCODE_API_MIN  13
+#define IWL7265_UCODE_API_MIN  13
+#define IWL7265D_UCODE_API_MIN 13
 
 /* NVM versions */
 #define IWL7260_NVM_VERSION0x0a1d
@@ -149,10 +155,7 @@ static const struct iwl_ht_params iwl7000_ht_params = {
.ht40_bands = BIT(IEEE80211_BAND_2GHZ) | BIT(IEEE80211_BAND_5GHZ),
 };
 
-#define IWL_DEVICE_7000\
-   .ucode_api_max = IWL7260_UCODE_API_MAX, \
-   .ucode_api_ok = IWL7260_UCODE_API_OK,   \
-   .ucode_api_min = IWL7260_UCODE_API_MIN, \
+#define IWL_DEVICE_7000_COMMON \
.device_family = IWL_DEVICE_FAMILY_7000,\
.max_inst_size = IWL60_RTC_INST_SIZE,   \
.max_data_size = IWL60_RTC_DATA_SIZE,   \
@@ -163,6 +166,24 @@ static const struct iwl_ht_params iwl7000_ht_params = {
.max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,\
.dccm_offset = IWL7000_DCCM_OFFSET
 
+#define IWL_DEVICE_7000\
+   IWL_DEVICE_7000_COMMON, \
+   .ucode_api_max = IWL7260_UCODE_API_MAX, \
+   .ucode_api_ok = IWL7260_UCODE_API_OK,   \
+   .ucode_api_min = IWL7260_UCODE_API_MIN
+
+#define IWL_DEVICE_7005\
+   IWL_DEVICE_7000_COMMON, \
+   .ucode_api_max = IWL7265_UCODE_API_MAX, \
+   .ucode_api_ok = IWL7265_UCODE_API_OK,   \
+   .ucode_api_min = IWL7265_UCODE_API_MIN
+
+#define IWL_DEVICE_7005D   \
+   IWL_DEVICE_7000_COMMON, \
+   .ucode_api_max = IWL7265D_UCODE_API_MAX,\
+   .ucode_api_ok = IWL7265D_UCODE_API_OK,  \
+   .ucode_api_min = IWL7265D_UCODE_API_MIN
+
 const struct iwl_cfg iwl7260_2ac_cfg = {
.name = "Intel(R) Dual Band Wireless AC 7260",
.fw_name_pre = IWL7260_FW_PRE,
@@ -266,7 +287,7 @@ static const struct iwl_ht_params iwl7265_ht_params = {
 const struct iwl_cfg iwl3165_2ac_cfg = {
.name = "Intel(R) Dual Band Wireless AC 3165",
.fw_name_pre = IWL7265D_FW_PRE,
-   IWL_DEVICE_7000,
+   IWL_DEVICE_7005D,
.ht_params = &iwl7000_ht_params,
.nvm_ver = IWL3165_NVM_VERSION,
.nvm_calib_ver = IWL3165_TX_POWER_VERSION,
@@ -277,7 +298,7 @@ const struct iwl_cfg iwl3165_2ac_cfg = {
 const struct iwl_cfg iwl7265_2ac_cfg = {
.name = "Intel(R) Dual Band Wireless AC 7265",
.fw_name_pre = IWL7265_FW_PRE,
-   IWL_DEVICE_7000,
+   IWL_DEVICE_7005,
.ht_params = &iwl7265_ht_params,
.nvm_ver = IWL7265_NVM_VERSION,
.nvm_calib_ver = IWL7265_TX_POWER_VERSION,
@@ -288,7 +309,7 @@ const struct iwl_cfg iwl7265_2ac_cfg = {
 const struct iwl_cfg iwl7265_2n_cfg = {
.name = "Intel(R) Dual Band Wireless N 7265",
.fw_name_pre = IWL7265_FW_PRE,
-   IWL_DEVICE_7000,
+   IWL_DEVICE_7005,
.ht_params = &iwl7265_ht_params,
.nvm_ver = IWL7265_NVM_VERSION,
.nvm_calib_ver = IWL7265_TX_POWER_VERSION,
@@ -299,7 +320,7 @@ const struct iwl_cfg iwl7265_2n_cfg = {
 const struct iwl_cfg iwl7265_n_cfg = {
.name = "Intel(R) Wireless N 7265",
.fw_name_pre = IWL7265_FW_PRE,
-   IWL_DEVICE_7000,
+   IWL_DEVICE_7005,
.ht_params = &iwl7265_ht_params,
.nvm_ver = IWL7265_NVM_VERSION,
.nvm_calib_ver = IWL7265_TX_POWER_VERSION,
@@ -310,7 +331,7 @@ const struct iwl_cfg iwl7265_n_cfg = {
 const struct iwl_cfg iwl7265d_2ac_cfg = {
.name = "Intel(R) Dual Band Wireless AC 7265",
.fw_name_pre = IWL7265D_FW_PRE,
-   IWL_DEVICE_7000,
+   

[PATCH 2/2] iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

[Emmanuel Grumbach]

From: Johannes Berg 

Properly protect the RCU dereference in iwl_mvm_get_key_sta_id() when
coming from iwl_mvm_update_tkip_key() which cannot hold the mvm->mutex
by moving the call into the RCU critical section.
Modify the check to use rcu_dereference_check() to permit this.

Fixes: 9513c5e18a0d ("iwlwifi: mvm: Avoid dereferencing sta if it was already 
flushed")
Reported-by: Laura Abbott 
Signed-off-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/sta.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/iwlwifi/mvm/sta.c
index 354acbd..2b976b1 100644
--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -1222,8 +1222,8 @@ static u8 iwl_mvm_get_key_sta_id(struct iwl_mvm *mvm,
mvmvif->ap_sta_id != IWL_MVM_STATION_COUNT) {
u8 sta_id = mvmvif->ap_sta_id;
 
-   sta = rcu_dereference_protected(mvm->fw_id_to_mac_id[sta_id],
-   lockdep_is_held(&mvm->mutex));
+   sta = rcu_dereference_check(mvm->fw_id_to_mac_id[sta_id],
+   lockdep_is_held(&mvm->mutex));
/*
 * It is possible that the 'sta' parameter is NULL,
 * for example when a GTK is removed - the sta_id will then
@@ -1590,14 +1590,15 @@ void iwl_mvm_update_tkip_key(struct iwl_mvm *mvm,
 u16 *phase1key)
 {
struct iwl_mvm_sta *mvm_sta;
-   u8 sta_id = iwl_mvm_get_key_sta_id(mvm, vif, sta);
+   u8 sta_id;
bool mcast = !(keyconf->flags & IEEE80211_KEY_FLAG_PAIRWISE);
 
-   if (WARN_ON_ONCE(sta_id == IWL_MVM_STATION_COUNT))
-   return;
-
rcu_read_lock();
 
+   sta_id = iwl_mvm_get_key_sta_id(mvm, vif, sta);
+   if (WARN_ON_ONCE(sta_id == IWL_MVM_STATION_COUNT))
+   goto unlock;
+
if (!sta) {
sta = rcu_dereference(mvm->fw_id_to_mac_id[sta_id]);
if (WARN_ON(IS_ERR_OR_NULL(sta))) {
@@ -1609,6 +1610,8 @@ void iwl_mvm_update_tkip_key(struct iwl_mvm *mvm,
mvm_sta = iwl_mvm_sta_from_mac80211(sta);
iwl_mvm_send_sta_key(mvm, mvm_sta, keyconf, mcast,
 iv32, phase1key, CMD_ASYNC, keyconf->hw_key_idx);
+
+ unlock:
rcu_read_unlock();
 }
 
-- 
2.5.0

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

Re: question on "mac80211_hwsim: support any address in userspace"

[m...@bobcopeland.com >> Bob Copeland]

On Wed, Dec 16, 2015 at 06:16:06AM -0800, Ben Greear wrote:
> Even so, I think it is more important to keep the kernel API stable than
> to work around issues in relatively obscure user-space apps.

Let's face it, everything using hwsim netlink api is already obscure :)

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

Re: [PATCH] ssb: pick SoC invariants code from MIPS BCM47xx arch

[Kalle Valo]

Rafał Miłecki  writes:

> There is code in ssb fetching "invariants" that is basically a set of
> board specific data. Every host requires its own implementation of
> reading function. In ssb we have support for PCI, PCMCIA & SDIO.
> For some (historical?) reason code reading "invariants" for SoC was
> placed in arch code and provided by a callback. This is not needed
> nowadays, so lets move that into ssb. This way we keep all "invariants"
> functions in a single module making code cleaner.
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next.git, thanks.

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

Re: [PATCH 1/2] wil6210: fix kernel OOPS when stopping interface during Rx traffic

[Kalle Valo]

Maya Erez  writes:

> From: Hamad Kadmany 
>
> When network interface is stopping, some resources may
> be already released by the network stack, and Rx frames
> cause kernel OOPS (observed one is in netfilter code)
>
> Proper solution is to drop packets pending in reorder buffer.
>
> Signed-off-by: Vladimir Kondratiev 
> Signed-off-by: Maya Erez 

This is missing Hamad's Signed-off-by line. It should be the first
before Vladimir's and yours.

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

Re: [PATCH] staging: rtl8723au: change parameter type in rtl8723a_set_rssi_cmd declaration

[Jes Sorensen]

drivengro...@gmail.com writes:
> From: Anatoly Stepanov 
>
> Previosly the function had the following prototype:
> int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
>
> My suggestion here is to modify the prototype this way:
> int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u32 *param)
>
> We can do this based on the following considerations:
> 1. rtl8723a_set_rssi_cmd is used only with 32-bit "param" values
> 2. There's no point in using "__u8 *param" until we pass param length
>
> Signed-off-by: Anatoly Stepanov 
> ---
>  drivers/staging/rtl8723au/hal/odm.c  | 2 +-
>  drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 6 +++---
>  drivers/staging/rtl8723au/include/rtl8723a_cmd.h | 2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/hal/odm.c 
> b/drivers/staging/rtl8723au/hal/odm.c
> index 6b9dbef..6fed13e 100644
> --- a/drivers/staging/rtl8723au/hal/odm.c
> +++ b/drivers/staging/rtl8723au/hal/odm.c
> @@ -1274,7 +1274,7 @@ static void odm_RSSIMonitorCheck(struct dm_odm_t 
> *pDM_Odm)
>  
>   for (i = 0; i < sta_cnt; i++) {
>   if (PWDB_rssi[i] != (0))
> - rtl8723a_set_rssi_cmd(Adapter, (u8 *)&PWDB_rssi[i]);
> + rtl8723a_set_rssi_cmd(Adapter, &PWDB_rssi[i]);
>   }
>  
>   pdmpriv->EntryMaxUndecoratedSmoothedPWDB = MaxDB;
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c 
> b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> index 1662c03c..e899d05 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> @@ -113,11 +113,11 @@ exit:
>   return ret;
>  }
>  
> -int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
> +int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u32 *param)
>  {
> - *((u32 *)param) = cpu_to_le32(*((u32 *)param));
> + __le32 cmd = cpu_to_le32(*param);
>  
> - FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param);
> + FillH2CCmd(padapter, RSSI_SETTING_EID, 3, (void *)&cmd);
>  
>   return _SUCCESS;
>  }

This is a step in the right direction, but lets get it right the first
time. There really is little reason for passing this by reference when
it should suffice passing by value.

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Bob Copeland]

On Wed, Dec 16, 2015 at 03:15:40PM +0100, Johannes Berg wrote:
> On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:
> 
> > My code expected that the key was the MAC of the radio, not the
> > MAC of a vif.  It set up mappings accordingly in the user-space
> > program.
> 
> I guess you were trying to be much smarter than wmediumd :)
> 
> Bob, any thoughts?

So, now that I understand the argument, I see the value in having
an unchanging key for each phy.  I'm also pretty sure that it was by
accident that it used to work that way.  If we were designing the ABI
from scratch, radio id would probably be better than a mac address for
that purpose.

Anyway, in the interest of not breaking userspace, I'm not opposed to
reverting that patch, and perhaps adding some documentation on top to make
it clear that the addr attributes have nothing to do with any mac addresses
actually in use.

For wmediumd users that would mean going back to the way it was previously,
in which only the 42:xx mac addresses will work, until I can work out another
way to do it.  I think that would break the test_wmediumd.py in hostapd
test suite in the meantime though.

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 06:59 AM, Bob Copeland wrote:

On Wed, Dec 16, 2015 at 03:15:40PM +0100, Johannes Berg wrote:

On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:


My code expected that the key was the MAC of the radio, not the
MAC of a vif.  It set up mappings accordingly in the user-space
program.


I guess you were trying to be much smarter than wmediumd :)

Bob, any thoughts?


So, now that I understand the argument, I see the value in having
an unchanging key for each phy.  I'm also pretty sure that it was by
accident that it used to work that way.  If we were designing the ABI
from scratch, radio id would probably be better than a mac address for
that purpose.

Anyway, in the interest of not breaking userspace, I'm not opposed to
reverting that patch, and perhaps adding some documentation on top to make
it clear that the addr attributes have nothing to do with any mac addresses
actually in use.

For wmediumd users that would mean going back to the way it was previously,
in which only the 42:xx mac addresses will work, until I can work out another
way to do it.  I think that would break the test_wmediumd.py in hostapd
test suite in the meantime though.



Ok, thanks.

I'm fine with waiting a bit before reverting..its easy enough for me to carry
a private patch for a while.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

[PATCH v1 0/2] wil6210 patches

[Maya Erez]

Chanes in V1:
- Fixed patches author and sign-off.

Those patches fix wil6210 issue and add support for platform specific recovery 
after FW crash

Hamad Kadmany (1):
  wil6210: fix kernel OOPS when stopping interface during Rx traffic

Lior David (1):
  wil6210: support for platform specific crash recovery

 drivers/net/wireless/ath/wil6210/interrupt.c  |  8 +++--
 drivers/net/wireless/ath/wil6210/pcie_bus.c   | 30 --
 drivers/net/wireless/ath/wil6210/rx_reorder.c | 12 ++-
 drivers/net/wireless/ath/wil6210/wil6210.h|  1 +
 drivers/net/wireless/ath/wil6210/wil_crash_dump.c |  3 +-
 drivers/net/wireless/ath/wil6210/wil_platform.c   |  3 +-
 drivers/net/wireless/ath/wil6210/wil_platform.h   | 38 +--
 7 files changed, 84 insertions(+), 11 deletions(-)

-- 
1.8.5.2

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

[PATCH v1 1/2] wil6210: fix kernel OOPS when stopping interface during Rx traffic

[Maya Erez]

From: Hamad Kadmany 

When network interface is stopping, some resources may
be already released by the network stack, and Rx frames
cause kernel OOPS (observed one is in netfilter code)

Proper solution is to drop packets pending in reorder buffer.

Signed-off-by: Hamad Kadmany 
Signed-off-by: Vladimir Kondratiev 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/rx_reorder.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/rx_reorder.c 
b/drivers/net/wireless/ath/wil6210/rx_reorder.c
index e3d1be8..32031e7 100644
--- a/drivers/net/wireless/ath/wil6210/rx_reorder.c
+++ b/drivers/net/wireless/ath/wil6210/rx_reorder.c
@@ -261,9 +261,19 @@ struct wil_tid_ampdu_rx *wil_tid_ampdu_rx_alloc(struct 
wil6210_priv *wil,
 void wil_tid_ampdu_rx_free(struct wil6210_priv *wil,
   struct wil_tid_ampdu_rx *r)
 {
+   int i;
+
if (!r)
return;
-   wil_release_reorder_frames(wil, r, r->head_seq_num + r->buf_size);
+
+   /* Do not pass remaining frames to the network stack - it may be
+* not expecting to get any more Rx. Rx from here may lead to
+* kernel OOPS since some per-socket accounting info was already
+* released.
+*/
+   for (i = 0; i < r->buf_size; i++)
+   kfree_skb(r->reorder_buf[i]);
+
kfree(r->reorder_buf);
kfree(r->reorder_time);
kfree(r);
-- 
1.8.5.2

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

[PATCH v1 2/2] wil6210: support for platform specific crash recovery

[Maya Erez]

From: Lior David 

Added a simple interface for platform to perform crash
recovery.
When firmware crashes, wil driver can notify the platform
which can trigger a crash recovery process. During
the process the platform can request a ram dump
from the wil driver as well as control when firmware
recovery will start. This interface allows the platform
to implement a more advanced crash recovery, for
example to reset dependent subsystems in proper order, or
to provide its own notifications during the recovery process.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/interrupt.c  |  8 +++--
 drivers/net/wireless/ath/wil6210/pcie_bus.c   | 30 --
 drivers/net/wireless/ath/wil6210/wil6210.h|  1 +
 drivers/net/wireless/ath/wil6210/wil_crash_dump.c |  3 +-
 drivers/net/wireless/ath/wil6210/wil_platform.c   |  3 +-
 drivers/net/wireless/ath/wil6210/wil_platform.h   | 38 +--
 6 files changed, 73 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index 50c136e..4f2ffa5 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -394,9 +394,13 @@ static irqreturn_t wil6210_irq_misc_thread(int irq, void 
*cookie)
wil_fw_core_dump(wil);
wil_notify_fw_error(wil);
isr &= ~ISR_MISC_FW_ERROR;
-   wil_fw_error_recovery(wil);
+   if (wil->platform_ops.notify_crash) {
+   wil_err(wil, "notify platform driver about FW crash");
+   wil->platform_ops.notify_crash(wil->platform_handle);
+   } else {
+   wil_fw_error_recovery(wil);
+   }
}
-
if (isr & ISR_MISC_MBOX_EVT) {
wil_dbg_irq(wil, "MBOX event\n");
wmi_recv_cmd(wil);
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c 
b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 1a3142c3..e36f2a0 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012-2014 Qualcomm Atheros, Inc.
+ * Copyright (c) 2012-2015 Qualcomm Atheros, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -125,11 +125,37 @@ static int wil_if_pcie_disable(struct wil6210_priv *wil)
return 0;
 }
 
+static int wil_platform_rop_ramdump(void *wil_handle, void *buf, uint32_t size)
+{
+   struct wil6210_priv *wil = wil_handle;
+
+   if (!wil)
+   return -EINVAL;
+
+   return wil_fw_copy_crash_dump(wil, buf, size);
+}
+
+static int wil_platform_rop_fw_recovery(void *wil_handle)
+{
+   struct wil6210_priv *wil = wil_handle;
+
+   if (!wil)
+   return -EINVAL;
+
+   wil_fw_error_recovery(wil);
+
+   return 0;
+}
+
 static int wil_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
struct wil6210_priv *wil;
struct device *dev = &pdev->dev;
int rc;
+   const struct wil_platform_rops rops = {
+   .ramdump = wil_platform_rop_ramdump,
+   .fw_recovery = wil_platform_rop_fw_recovery,
+   };
 
/* check HW */
dev_info(&pdev->dev, WIL_NAME
@@ -154,7 +180,7 @@ static int wil_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
/* rollback to if_free */
 
wil->platform_handle =
-   wil_platform_init(&pdev->dev, &wil->platform_ops);
+   wil_platform_init(&pdev->dev, &wil->platform_ops, &rops, wil);
if (!wil->platform_handle) {
rc = -ENODEV;
wil_err(wil, "wil_platform_init failed\n");
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index ade5f3b8..235e205 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -828,6 +828,7 @@ int wil_can_suspend(struct wil6210_priv *wil, bool 
is_runtime);
 int wil_suspend(struct wil6210_priv *wil, bool is_runtime);
 int wil_resume(struct wil6210_priv *wil, bool is_runtime);
 
+int wil_fw_copy_crash_dump(struct wil6210_priv *wil, void *dest, u32 size);
 void wil_fw_core_dump(struct wil6210_priv *wil);
 
 #endif /* __WIL6210_H__ */
diff --git a/drivers/net/wireless/ath/wil6210/wil_crash_dump.c 
b/drivers/net/wireless/ath/wil6210/wil_crash_dump.c
index 7e70934..b57d280 100644
--- a/drivers/net/wireless/ath/wil6210/wil_crash_dump.c
+++ b/drivers/net/wireless/ath/wil6210/wil_crash_dump.c
@@ -51,8 +51,7 @@ static int wil_fw_get_crash_dump_bounds(struct wil6210_priv 
*wil,
return 0;
 }
 
-static int wil_fw_copy_crash_dump(struct wil6210_priv *wil, void *dest,
- u32 size)
+int wil_fw_copy_

RE: question on "mac80211_hwsim: support any address in userspace"

[Adam R. Welle]

> Well, it was always rather awkward since it was the *second* address :)

Could somebody provide background information on why the decision was
made to use a second address for the netlink frames instead of the same
address as was used for the non-netlink frames? 

I too have an obscure user-space app which uses this API :)

My app was written to account for both the old and new logic being debated,
so I can cope either way with the flip of a switch. I would just like to
say that for my purposes the patch worked better as I already intended for
my app to track MAC address changes made by a user.

I should note that I am passing these frames between virtual machines so
the use of unique addresses (instead of hard-coded 0x42 addresses) as a key
simplifies things when determining which radio transmitted a given frame
and which radio needs to receive the frame. My app has always relied on the
MAC address assigned by the user as a unique key across virtual machines.
Also, I will point out that I am not using multiple vifs on a radio but if
I were, I imagine that I would send a copy of the frame to each vif.

Adam

[ANNOUNCE] New location for wireless-testing tree

[Bob Copeland]

As reported previously[1], John Linville will be moving on from maintenance
of the wireless-testing[2] tree at the end of the year.  A huge thank you to
John for doing all this work for so many years!

We now have a shared wireless directory on kernel.org where we (currently
myself and Kalle as backup) will continue to maintain this tree going
forward.  The new tree can be found at:

git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git

Note: unlike John's tree, we are going to try rebasing this tree on every
build (like linux-next) instead of merging the downstream trees, in order
to avoid certain merge problems when those trees are rebased.

This means that if you are working directly off of wireless-testing, use
'git pull --rebase' to sync, instead of just 'git pull'.

We'll see how this goes and reassess after a couple of cycles.

Please let me know of any issues.

[1] http://comments.gmane.org/gmane.linux.kernel.wireless.general/145291

[2] wireless-testing is an integration testing tree, consisting of:

 * Linus's latest -rc
 * patches in mac80211 and wireless-drivers (for the upcoming release)
 * patches in mac80211-next and wireless-drivers-next (for the next release)

It is not pulled into any upstream tree, but it should be a pretty good
indication of what is baking in Linux wireless for the next release, without
having unrelated changes from all the other subsystems as in linux-next.

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

Re: question on "mac80211_hwsim: support any address in userspace"

[Bob Copeland]

On Wed, Dec 16, 2015 at 05:30:20PM +, Adam R. Welle wrote:
> 
> > Well, it was always rather awkward since it was the *second* address :)
> 
> Could somebody provide background information on why the decision was
> made to use a second address for the netlink frames instead of the same
> address as was used for the non-netlink frames? 

I can't; I believe it was done that way from the start but I don't really
know if there was a reason.

> I too have an obscure user-space app which uses this API :)
> 
> My app was written to account for both the old and new logic being debated,
> so I can cope either way with the flip of a switch. I would just like to
> say that for my purposes the patch worked better as I already intended for
> my app to track MAC address changes made by a user.

In any case, we'll need to support that.  However the addr attribute is
interpreted, the actual userspace app should accept any user defined address
as long as it can map it back to the attribute.  It just may be the case
going forward that the attribute bears no obvious relationship to the
addresses used in frames.

> I should note that I am passing these frames between virtual machines so
> the use of unique addresses (instead of hard-coded 0x42 addresses) as a key
> simplifies things when determining which radio transmitted a given frame
> and which radio needs to receive the frame. My app has always relied on the
> MAC address assigned by the user as a unique key across virtual machines.

Sounds interesting - is this app open source?

> Also, I will point out that I am not using multiple vifs on a radio but if
> I were, I imagine that I would send a copy of the frame to each vif.

I guess this is what wmediumd would wind up doing too, but it would result in
duplicate frames at the receivers with multiple vifs.

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

[PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh 
---
 drivers/net/wireless/ath/ath10k/core.c | 6 ++
 drivers/net/wireless/ath/ath10k/core.h | 3 +++
 drivers/net/wireless/ath/ath10k/mac.c  | 3 ++-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index fca702c..fcfccd8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -35,18 +35,21 @@ static unsigned int ath10k_cryptmode_param;
 static bool uart_print;
 static bool skip_otp;
 static bool rawmode;
+static bool hw_csum = true;
 
 module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
 module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
 module_param(uart_print, bool, 0644);
 module_param(skip_otp, bool, 0644);
 module_param(rawmode, bool, 0644);
+module_param(hw_csum, bool, 0644);
 
 MODULE_PARM_DESC(debug_mask, "Debugging mask");
 MODULE_PARM_DESC(uart_print, "Uart target debugging");
 MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode");
 MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software");
 MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath");
+MODULE_PARM_DESC(hw_csum, "Enable HW checksum offload (default: on)");
 
 static const struct ath10k_hw_params ath10k_hw_params_list[] = {
{
@@ -1405,6 +1408,9 @@ static int ath10k_core_init_firmware_features(struct 
ath10k *ar)
ar->htt.max_num_amsdu = 1;
}
 
+   if (!hw_csum)
+   set_bit(ATH10K_FLAG_HW_CSUM_DISABLED, &ar->dev_flags);
+
/* Backwards compatibility for firmwares without
 * ATH10K_FW_IE_WMI_OP_VERSION.
 */
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 3c8a510..1972439 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -535,6 +535,9 @@ enum ath10k_dev_flags {
 
/* Bluetooth coexistance enabled */
ATH10K_FLAG_BTCOEX,
+
+   /* Do not use checksum offload */
+   ATH10K_FLAG_HW_CSUM_DISABLED,
 };
 
 enum ath10k_cal_mode {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a4c5c1d..f87f521 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7332,7 +7332,8 @@ int ath10k_mac_register(struct ath10k *ar)
goto err_free;
}
 
-   if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags))
+   if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags) &&
+   !test_bit(ATH10K_FLAG_HW_CSUM_DISABLED, &ar->dev_flags))
ar->hw->netdev_features = NETIF_F_HW_CSUM;
 
if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED)) {
-- 
1.9.1

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Felix Fietkau]

On 2015-12-16 19:20, Peter Oh wrote:
> Some hardwares such as QCA988X and QCA99X0 doesn't have
> capability of checksum offload when frame formats are not
> suitable for it such as Mesh frame.
> Hence add a module parameter, hw_csum, to make checksum offload
> configurable during module registration time.
> 
> Signed-off-by: Peter Oh 
How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

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

Re: About adding support for MT76x2U to Linux kernel

[Felix Fietkau]

On 2015-08-14 14:32, Jakub Kiciński wrote:
> CC: Linus W who was hacking on mt7630e recently.
> 
> On Fri, 14 Aug 2015 11:15:26 +0300, Tuomas Räsänen wrote:
>> Hi
>> 
>> I'm very interested in adding support (especially AP mode) for MT76x2U
>> USB-dongles to Linux kernel. I'm aware of the work you both have done, 
>> Felix's
>> work on MT76x2 PCI-devices and Jakub's work to add support for MT7601U. So I
>> guess no one knows this exact problem domain better than you (perhaps 
>> excluding
>> MediaTek's subcontractors who wrote the original vendor driver), that is why 
>> I'm
>> writing specifically to you.
>> 
>> I have ASUS USB-N53_B1 adapter (0b05:180b) as a test device:
>> https://wikidevi.com/wiki/ASUS_USB-N53_B1
>> 
>> As far as I know, no one has been / is working on MT76x2U USB-dongles, please
>> correct me if I'm wrong.
>> 
>> I have a strong system programming background, some knowledge on 802.11 in
>> general, but no actual experience in Linux kernel programming. So I'm pretty
>> confident that I'll have many questions to throw at you before I have 
>> managed to
>> make anything functional.
>> 
>> So, to get started, I was wondering what would be the best way forward. I can
>> think of two reasonable approaches:
>> 
>>   #1 Base the new driver on Felix's mt76 and modify it to work on USB-bus
>>  instead of PCI.
>> 
>>   #2 Base the new driver on Jakub's mt7601u and modify it to handle mt76x2u
>>  devices by using Felix's mt76 and the vendor driver as a reference.
>> 
>> Of course there's the third option to write it from scratch based solely on 
>> the
>> vendor driver, but because you have already done such a great job in
>> interpreting the outdated and quite ugly (subjective view?) vendor driver 
>> code,
>> that would be foolish.
> 
> There is a fourth option: merge mt76 and mt7601u and add support for
> mt76x2u along the way ;)
> 
>> At first I had a hunch that #1 would be the easiest way forward, but now 
>> that I
>> skimmed through the code, I'm beginning to think that approach #2 has the 
>> least
>> resistance. However, I'm not necessarily looking for the easiest way but *the
>> best/right* way. So any ideas, opinions and thoughts are more than welcome.
> 
> Hardware wise your chipsets will be closer to the ones Felix is
> supporting and mt76 has AP support as well (which mt7601u is lacking).
> But mt76 is not upstream and I don't think USB is a priority there...
> 
> On my side, I won't be able to help you or do mentoring for next few
> months for contractual reasons :(
Hey guys,

I just wanted to let you know that I'm making good progress with mt76
support for mt7603e chips.

I think I finally have a good code structure in place to deal with with
very different chipsets.
While mt7603 has an entirely different register layout, MCU packet
format and MAC interface, I was able to share a lot of code between 76x2
and 7603 with very little indirection.

Once I'm done with mt7603 bringup (monitor mode rx already works), I
plan on submitting mt76 upstream, and then we can see about adding
support for 76x2u, or even merging the hardware support for mt7601u.

You can check out my work in the mt7603 branch here:
https://github.com/openwrt/mt76/tree/mt7603

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

RE: question on "mac80211_hwsim: support any address in userspace"

[Adam R. Welle]

> > I should note that I am passing these frames between virtual machines
> > so the use of unique addresses (instead of hard-coded 0x42 addresses)
> > as a key simplifies things when determining which radio transmitted a
> > given frame and which radio needs to receive the frame. My app has
> > always relied on the MAC address assigned by the user as a unique key
> > across virtual machines.
> 
> Sounds interesting - is this app open source?

We intend for it to be but I am not sure how long it will take to make that
happen. I told Johannes a few months ago that I was using mac80211_hwsim and
a wmediumd-inspired app to train wireless pen-testing skills. I am using
VMWare as the hypervisor and everything has been working pretty well.

Adam

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

Re: Information leak in llcp_sock_bind/llcp_raw_sock_bind

[Dmitry Vyukov]

On Tue, Dec 15, 2015 at 9:58 PM, David Miller  wrote:
> From: Dmitry Vyukov 
> Date: Tue, 15 Dec 2015 21:55:37 +0100
>
>> I've seen a kernel address at least in pptp_bind,
>
> We're not talking about pptp_bind.
>
> We're talking about llcp_{,raw}_sock_bind().
>
> If your hex dump doesn't show it, don't report anything unless you are
> absolutely sure via code inspection that there could be a leak.  And
> in that case make it perfectly clear exactly how that can happen.
>
> I am generally unimpressed with your reports half of the time,
> and just a small amount of extra effort would extraordinarily
> improve the quality of the things your post.
>
> Thanks.
>
>> So it is almost impossible to prove that a PC cannot be leaked.
>
> You can't show that anything is actually being leaked in this specific
> case, period.


I am a human and sometimes do mistakes.

In this case, I checked that the bind succeeds when I pass
sockaddrlen=0, which is suspicious and matches the behavior of pptp
case (not checking sockaddrlen at all). Then I looked at the code and
misread it, because it uses a different idiom from other cases I saw
(explicitly checking sockaddrlen value). Then I wrote a test program
and observed a varying, garbage-looking values returned from
getsockname. From that I concluded that there is an information leak.
This is wrong.

For the purpose of improvement of my reports, what are the other
reports you are not impressed with and why?

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh 

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)
That will be good option for hardware not supporting HW checksum, but I 
mind that using the function will add more workload per every packet on 
critical data path when HW supports checksum resulting in throughput down.

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

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Felix Fietkau]

On 2015-12-16 21:29, Peter Oh wrote:
> 
> On 12/16/2015 10:27 AM, Felix Fietkau wrote:
>> On 2015-12-16 19:20, Peter Oh wrote:
>>> Some hardwares such as QCA988X and QCA99X0 doesn't have
>>> capability of checksum offload when frame formats are not
>>> suitable for it such as Mesh frame.
>>> Hence add a module parameter, hw_csum, to make checksum offload
>>> configurable during module registration time.
>>>
>>> Signed-off-by: Peter Oh 
>> How about instead of inventing yet another crappy module parameter, you
>> call skb_checksum_help() in the driver in cases where the hardware is
>> unable to offload the checksum calculation.
>>
>> That way the user has to worry about less driver specific hackery ;)
> That will be good option for hardware not supporting HW checksum, but I 
> mind that using the function will add more workload per every packet on 
> critical data path when HW supports checksum resulting in throughput down.
I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh 

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.
To call it selectively for Mesh frame or interface, we need to add it on 
mac80211 layer such as ieee80211_build_hdr() since driver layer does not 
care the interface type in data path.
In that case it will also introduce throughput degrade to HW that 
supports HW checksum for Mesh.

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

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Felix Fietkau]

On 2015-12-16 21:46, Peter Oh wrote:
> 
> On 12/16/2015 12:35 PM, Felix Fietkau wrote:
>> On 2015-12-16 21:29, Peter Oh wrote:
>>> On 12/16/2015 10:27 AM, Felix Fietkau wrote:
 On 2015-12-16 19:20, Peter Oh wrote:
> Some hardwares such as QCA988X and QCA99X0 doesn't have
> capability of checksum offload when frame formats are not
> suitable for it such as Mesh frame.
> Hence add a module parameter, hw_csum, to make checksum offload
> configurable during module registration time.
>
> Signed-off-by: Peter Oh 
 How about instead of inventing yet another crappy module parameter, you
 call skb_checksum_help() in the driver in cases where the hardware is
 unable to offload the checksum calculation.

 That way the user has to worry about less driver specific hackery ;)
>>> That will be good option for hardware not supporting HW checksum, but I
>>> mind that using the function will add more workload per every packet on
>>> critical data path when HW supports checksum resulting in throughput down.
>> I didn't mean calling it for every single frame in the data path.
>> What I'm suggesting is calling it selectively only for mesh frames, or
>> any other frames that the hardware cannot offload, and leaving the rest
>> for the hardware to process.
>>
>> There should be no performance difference between disabling checksum
>> offload and calling skb_checksum_help from the driver.
> To call it selectively for Mesh frame or interface, we need to add it on 
> mac80211 layer such as ieee80211_build_hdr() since driver layer does not 
> care the interface type in data path.
No need to change mac80211 - it only touches the headers, and
skb_checksum_help does not care about that. The skb has enough
information for it to find the right range to calculate the checksum and
the place to store it.

> In that case it will also introduce throughput degrade to HW that 
> supports HW checksum for Mesh.
This doesn't make any sense to me. Are you saying that there's no way
for the driver to detect the cases where the hardware cannot do checksum
offloading? How is the user supposed to know when to change that module
parameter? Trial and error?

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 12:53 PM, Felix Fietkau wrote:

On 2015-12-16 21:46, Peter Oh wrote:

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh 

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.

To call it selectively for Mesh frame or interface, we need to add it on
mac80211 layer such as ieee80211_build_hdr() since driver layer does not
care the interface type in data path.

No need to change mac80211 - it only touches the headers, and
skb_checksum_help does not care about that. The skb has enough
information for it to find the right range to calculate the checksum and
the place to store it.
If mentioned to use the function to mesh frame only without touching 
mac80211, then how do you suggest it to apply it only to mesh frame 
without interfere other data frames?

Can you share your example?



In that case it will also introduce throughput degrade to HW that
supports HW checksum for Mesh.

This doesn't make any sense to me. Are you saying that there's no way
for the driver to detect the cases where the hardware cannot do checksum
offloading?
I'm saying the case that HW supports checksum except for specific frame 
such as Mesh and to make driver support both case dynamically at code 
level, it requires extra codes which need to check if the frame is Mesh 
or not. Since this approach requires extra workload especially in data 
path, it will degrade driver's performance.

  How is the user supposed to know when to change that module
parameter? Trial and error?

- Felix


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

[PATCH] Print warnings for missing cfg80211_ops implementations

[Ola Olsson]

Print a warning whenever an expected callback function
lacks implementation.

Signed-off-by: Ola Olsson 
---
 net/wireless/core.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index b091551..3a9c41b 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -352,6 +352,16 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, 
int sizeof_priv,
WARN_ON(ops->add_station && !ops->del_station);
WARN_ON(ops->add_mpath && !ops->del_mpath);
WARN_ON(ops->join_mesh && !ops->leave_mesh);
+   WARN_ON(ops->start_p2p_device && !ops->stop_p2p_device);
+   WARN_ON(ops->start_ap && !ops->stop_ap);
+   WARN_ON(ops->join_ocb && !ops->leave_ocb);
+   WARN_ON(ops->suspend && !ops->resume);
+   WARN_ON(ops->sched_scan_start && !ops->sched_scan_stop);
+   WARN_ON(ops->remain_on_channel && !ops->cancel_remain_on_channel);
+   WARN_ON(ops->tdls_channel_switch && !ops->tdls_cancel_channel_switch);
+   WARN_ON(ops->add_tx_ts && !ops->del_tx_ts);
+   WARN_ON(ops->set_tx_power && !ops->get_tx_power);
+   WARN_ON(ops->set_antenna && !ops->get_antenna);
 
alloc_size = sizeof(*rdev) + sizeof_priv;
 
-- 
1.7.9.5

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Felix Fietkau]

On 2015-12-16 22:19, Peter Oh wrote:
> 
> On 12/16/2015 12:53 PM, Felix Fietkau wrote:
>> On 2015-12-16 21:46, Peter Oh wrote:
>>> On 12/16/2015 12:35 PM, Felix Fietkau wrote:
 On 2015-12-16 21:29, Peter Oh wrote:
> On 12/16/2015 10:27 AM, Felix Fietkau wrote:
>> On 2015-12-16 19:20, Peter Oh wrote:
>>> Some hardwares such as QCA988X and QCA99X0 doesn't have
>>> capability of checksum offload when frame formats are not
>>> suitable for it such as Mesh frame.
>>> Hence add a module parameter, hw_csum, to make checksum offload
>>> configurable during module registration time.
>>>
>>> Signed-off-by: Peter Oh 
>> How about instead of inventing yet another crappy module parameter, you
>> call skb_checksum_help() in the driver in cases where the hardware is
>> unable to offload the checksum calculation.
>>
>> That way the user has to worry about less driver specific hackery ;)
> That will be good option for hardware not supporting HW checksum, but I
> mind that using the function will add more workload per every packet on
> critical data path when HW supports checksum resulting in throughput down.
 I didn't mean calling it for every single frame in the data path.
 What I'm suggesting is calling it selectively only for mesh frames, or
 any other frames that the hardware cannot offload, and leaving the rest
 for the hardware to process.

 There should be no performance difference between disabling checksum
 offload and calling skb_checksum_help from the driver.
>>> To call it selectively for Mesh frame or interface, we need to add it on
>>> mac80211 layer such as ieee80211_build_hdr() since driver layer does not
>>> care the interface type in data path.
>> No need to change mac80211 - it only touches the headers, and
>> skb_checksum_help does not care about that. The skb has enough
>> information for it to find the right range to calculate the checksum and
>> the place to store it.
> If mentioned to use the function to mesh frame only without touching 
> mac80211, then how do you suggest it to apply it only to mesh frame 
> without interfere other data frames?
> Can you share your example?
It's trivial - in ath10k_tx you do this:

if (vif->type == NL80211_IFTYPE_MESH_POINT &&
skb->ip_summed == CHECKSUM_PARTIAL)
skb_checksum_help(skb);

>>> In that case it will also introduce throughput degrade to HW that
>>> supports HW checksum for Mesh.
>> This doesn't make any sense to me. Are you saying that there's no way
>> for the driver to detect the cases where the hardware cannot do checksum
>> offloading?
> I'm saying the case that HW supports checksum except for specific frame 
> such as Mesh and to make driver support both case dynamically at code 
> level, it requires extra codes which need to check if the frame is Mesh 
> or not. Since this approach requires extra workload especially in data 
> path, it will degrade driver's performance.
The check is cheap enough that it will not have any visible impact. And
the improved user experience is certainly worth it ;)

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

Re: About adding support for MT76x2U to Linux kernel

[Johannes Stezenbach]

Hi,

On Wed, Dec 16, 2015 at 07:53:04PM +0100, Felix Fietkau wrote:
> Once I'm done with mt7603 bringup (monitor mode rx already works), I
> plan on submitting mt76 upstream, and then we can see about adding
> support for 76x2u, or even merging the hardware support for mt7601u.
> 
> You can check out my work in the mt7603 branch here:
> https://github.com/openwrt/mt76/tree/mt7603

let me chime in to say that I'm interested to work on
support for mt7610u (TP-LINK Archer T2U/T2UH).
https://wikidevi.com/wiki/TP-LINK_Archer_T2U

I'm facing the same question as Tuomas about using
mt76 or mt7601u as the base?


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

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 09:30 AM, Adam R. Welle wrote:



Well, it was always rather awkward since it was the *second* address :)


Could somebody provide background information on why the decision was
made to use a second address for the netlink frames instead of the same
address as was used for the non-netlink frames?


I would be fine with always using the first address instead of the second,
in case that helps someone.

We could also set the address at creation time easily enough.  Then it
could still be unique across many machines if you managed it.

Thanks,
Ben



I too have an obscure user-space app which uses this API :)

My app was written to account for both the old and new logic being debated,
so I can cope either way with the flip of a switch. I would just like to
say that for my purposes the patch worked better as I already intended for
my app to track MAC address changes made by a user.

I should note that I am passing these frames between virtual machines so
the use of unique addresses (instead of hard-coded 0x42 addresses) as a key
simplifies things when determining which radio transmitted a given frame
and which radio needs to receive the frame. My app has always relied on the
MAC address assigned by the user as a unique key across virtual machines.
Also, I will point out that I am not using multiple vifs on a radio but if
I were, I imagine that I would send a copy of the frame to each vif.

Adam




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

RE: question on "mac80211_hwsim: support any address in userspace"

[Adam R. Welle]

> > Could somebody provide background information on why the decision was
> > made to use a second address for the netlink frames instead of the
> > same address as was used for the non-netlink frames?
> 
> I would be fine with always using the first address instead of the
> second, in case that helps someone.
> 
> We could also set the address at creation time easily enough.  Then it
> could still be unique across many machines if you managed it.

I actually apply a patch for that. I have added a module parameter which
is used as the MAC address for the first radio, and I increment the final
octet for each additional radio. This is so that my users do not have
to manually reset the MAC address to get a unique one. I apply the address
to both addresses mentioned above though I only use the netlink datapath.

If there is interest in this I can submit it as an RFC patch tomorrow.

Adam


--
Adam Welle 




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

Re: question on "mac80211_hwsim: support any address in userspace"

[Ben Greear]

On 12/16/2015 02:56 PM, Adam R. Welle wrote:

Could somebody provide background information on why the decision was
made to use a second address for the netlink frames instead of the
same address as was used for the non-netlink frames?


I would be fine with always using the first address instead of the
second, in case that helps someone.

We could also set the address at creation time easily enough.  Then it
could still be unique across many machines if you managed it.


I actually apply a patch for that. I have added a module parameter which
is used as the MAC address for the first radio, and I increment the final
octet for each additional radio. This is so that my users do not have
to manually reset the MAC address to get a unique one. I apply the address
to both addresses mentioned above though I only use the netlink datapath.

If there is interest in this I can submit it as an RFC patch tomorrow.


I'd rather see support for specifying an arbitrary MAC upon creation
with a netlink attribute than a module parameter...

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: pull-request: mac80211 2015-12-15

[David Miller]

From: Johannes Berg 
Date: Tue, 15 Dec 2015 13:30:21 +0100

> After going through my patch queue, I have another set of fixes that
> I think is still appropriate for the current cycle.
> 
> Two of my own restart changes there are fairly big but for the most
> part just move code around so it can be called in a slightly different
> order.
> 
> Let me know if there are any issues.

Something about your text encoding kept this from ending up
in patchwork for some reason.

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 01:54 PM, Felix Fietkau wrote:

On 2015-12-16 22:19, Peter Oh wrote:

On 12/16/2015 12:53 PM, Felix Fietkau wrote:

On 2015-12-16 21:46, Peter Oh wrote:

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh 

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.

To call it selectively for Mesh frame or interface, we need to add it on
mac80211 layer such as ieee80211_build_hdr() since driver layer does not
care the interface type in data path.

No need to change mac80211 - it only touches the headers, and
skb_checksum_help does not care about that. The skb has enough
information for it to find the right range to calculate the checksum and
the place to store it.

If mentioned to use the function to mesh frame only without touching
mac80211, then how do you suggest it to apply it only to mesh frame
without interfere other data frames?
Can you share your example?

It's trivial - in ath10k_tx you do this:

if (vif->type == NL80211_IFTYPE_MESH_POINT &&
 skb->ip_summed == CHECKSUM_PARTIAL)
skb_checksum_help(skb);

Thank you Felix for the quick response.
I agree on your user experience opinion,
but what do you think when ath10k has a new chip supporting HW checksum 
for Mesh?

In that case it will also introduce throughput degrade to HW that
supports HW checksum for Mesh.

This doesn't make any sense to me. Are you saying that there's no way
for the driver to detect the cases where the hardware cannot do checksum
offloading?

I'm saying the case that HW supports checksum except for specific frame
such as Mesh and to make driver support both case dynamically at code
level, it requires extra codes which need to check if the frame is Mesh
or not. Since this approach requires extra workload especially in data
path, it will degrade driver's performance.

The check is cheap enough that it will not have any visible impact. And
the improved user experience is certainly worth it ;)

- Felix

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

RE: question on "mac80211_hwsim: support any address in userspace"

[Adam R. Welle]

> >> We could also set the address at creation time easily enough.  Then
> >> it could still be unique across many machines if you managed it.
> >
> > I actually apply a patch for that. I have added a module parameter
> > which is used as the MAC address for the first radio, and I increment
> > the final octet for each additional radio. This is so that my users do
> > not have to manually reset the MAC address to get a unique one. I
> > apply the address to both addresses mentioned above though I only use
> > the netlink datapath.
> >
> > If there is interest in this I can submit it as an RFC patch tomorrow.
> 
> I'd rather see support for specifying an arbitrary MAC upon creation
> with a netlink attribute than a module parameter...

I can see the usefulness in your suggestion as you would be able to specify 
non-sequential addresses to the radios. I hadn't thought of that since I load 
the module with one radio and do not use the netlink API to add or remove 
radios.

Adam

--

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Felix Fietkau]

On 2015-12-17 00:50, Peter Oh wrote:
> 
> On 12/16/2015 01:54 PM, Felix Fietkau wrote:
>> On 2015-12-16 22:19, Peter Oh wrote:
>>> On 12/16/2015 12:53 PM, Felix Fietkau wrote:
 On 2015-12-16 21:46, Peter Oh wrote:
> On 12/16/2015 12:35 PM, Felix Fietkau wrote:
>> On 2015-12-16 21:29, Peter Oh wrote:
>>> On 12/16/2015 10:27 AM, Felix Fietkau wrote:
 On 2015-12-16 19:20, Peter Oh wrote:
> Some hardwares such as QCA988X and QCA99X0 doesn't have
> capability of checksum offload when frame formats are not
> suitable for it such as Mesh frame.
> Hence add a module parameter, hw_csum, to make checksum offload
> configurable during module registration time.
>
> Signed-off-by: Peter Oh 
 How about instead of inventing yet another crappy module parameter, you
 call skb_checksum_help() in the driver in cases where the hardware is
 unable to offload the checksum calculation.

 That way the user has to worry about less driver specific hackery ;)
>>> That will be good option for hardware not supporting HW checksum, but I
>>> mind that using the function will add more workload per every packet on
>>> critical data path when HW supports checksum resulting in throughput 
>>> down.
>> I didn't mean calling it for every single frame in the data path.
>> What I'm suggesting is calling it selectively only for mesh frames, or
>> any other frames that the hardware cannot offload, and leaving the rest
>> for the hardware to process.
>>
>> There should be no performance difference between disabling checksum
>> offload and calling skb_checksum_help from the driver.
> To call it selectively for Mesh frame or interface, we need to add it on
> mac80211 layer such as ieee80211_build_hdr() since driver layer does not
> care the interface type in data path.
 No need to change mac80211 - it only touches the headers, and
 skb_checksum_help does not care about that. The skb has enough
 information for it to find the right range to calculate the checksum and
 the place to store it.
>>> If mentioned to use the function to mesh frame only without touching
>>> mac80211, then how do you suggest it to apply it only to mesh frame
>>> without interfere other data frames?
>>> Can you share your example?
>> It's trivial - in ath10k_tx you do this:
>>
>> if (vif->type == NL80211_IFTYPE_MESH_POINT &&
>>  skb->ip_summed == CHECKSUM_PARTIAL)
>>  skb_checksum_help(skb);
> Thank you Felix for the quick response.
> I agree on your user experience opinion,
> but what do you think when ath10k has a new chip supporting HW checksum 
> for Mesh?
Then you simply update the checks. What's the big deal?

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

Re: [PATCH] Print warnings for missing cfg80211_ops implementations

[Joe Perches]

On Wed, 2015-12-16 at 22:43 +0100, Ola Olsson wrote:
> Print a warning whenever an expected callback function
> lacks implementation.
> 
> Signed-off-by: Ola Olsson 
> ---
>  net/wireless/core.c |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index b091551..3a9c41b 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -352,6 +352,16 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops 
> *ops, int sizeof_priv,
>   WARN_ON(ops->add_station && !ops->del_station);
>   WARN_ON(ops->add_mpath && !ops->del_mpath);
>   WARN_ON(ops->join_mesh && !ops->leave_mesh);
> + WARN_ON(ops->start_p2p_device && !ops->stop_p2p_device);
> + WARN_ON(ops->start_ap && !ops->stop_ap);
> + WARN_ON(ops->join_ocb && !ops->leave_ocb);
> + WARN_ON(ops->suspend && !ops->resume);
> + WARN_ON(ops->sched_scan_start && !ops->sched_scan_stop);
> + WARN_ON(ops->remain_on_channel && !ops->cancel_remain_on_channel);
> + WARN_ON(ops->tdls_channel_switch && !ops->tdls_cancel_channel_switch);
> + WARN_ON(ops->add_tx_ts && !ops->del_tx_ts);
> + WARN_ON(ops->set_tx_power && !ops->get_tx_power);
> + WARN_ON(ops->set_antenna && !ops->get_antenna);

maybe all of these should be a nand b?

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

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

[Dave Young]

Hi, Johannes

Sorry for late feedback, I was busying on other things.

On 12/11/15 at 03:38pm, Johannes Berg wrote:
> On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote:
> > cfg80211 module prints a lot of messages like below. Actually
> > printing once is acceptable but sometimes it will print again and
> > again, it looks very annoying. It is better to change these detail
> > messages to debugging only.
> > 
> 
> Despite the objections, I've applied this patch now.
> 

Thanks a lot.

> I've made one change: keeping the alpha2 (e.g. "US") printed in some of
> the pr_err() cases in this file.
> I also got rid of CONFIG_CFG80211_REG_DEBUG in a separate patch.
> 
> I somewhat agree with the objections, but if the kernel is with
> CONFIG_DYNAMIC_DEBUG then it's really simple to get the messages back
> by enabling them for this file.
> 
> Where the messages were used as an indication of something having gone
> awry at a different level (e.g. mac80211 disconnect) I don't really
> quite agree - that then perhaps should have a more explicit (and less
> noisy) message.
> 
> I also agree that the regulatory code is quite opaque, and the way it
> arrives at certain conclusions is not always obvious. These messages
> don't help all that much though since they don't contain the actual
> input to the decisions. I think for that, we'd be much better served
> with some kind of tracepoint or so that records all the information.

I think you guys are expert in this area, I will agree with all of
above. But I hope we can have some rate limited messages at least
especially for endless things.

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

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

[Dave Young]

Hi,

On 12/11/15 at 03:26pm, Johannes Berg wrote:
> On Mon, 2015-11-23 at 09:37 +0800, Dave Young wrote:
> 
> > Seems there're a lot of other wireless messages. Should we refactor 
> > them as well? I still did not get chance to see where is the code.
> > (My wireless driver being used is iwlwifi)
> 
> Most are probably from net/mac80211/.
> 
> > # dmesg|grep "Limiting TX power"|wc
> >    4128   49600  360052
> > 
> 
> I fixed this one recently, due to a bug it was printed all the time
> instead of just once when taking effect.

Cool, has the fix been in mainline or somewhere else?

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

Re: [PATCH] Print warnings for missing cfg80211_ops implementations

[Joe Perches]

On Thu, 2015-12-17 at 05:19 +0100, Ola Olsson wrote:
> Hi Joe,
> 
> > maybe all of these should be a nand b?
> 
> You're right but i don't understand where the problem is. Please help
> me.
> 

The code is currently like:

       WARN_ON(ops->add_station && !ops->del_station);
 
but maybe it should be

WARN_ON((ops->add_station && !ops->del_station) ||
(!opt->add_station && ops->del_station))

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Michal Kazior]

On 17 December 2015 at 00:50, Peter Oh  wrote:
> On 12/16/2015 01:54 PM, Felix Fietkau wrote:
>> On 2015-12-16 22:19, Peter Oh wrote:
[...]
>>> If mentioned to use the function to mesh frame only without touching
>>> mac80211, then how do you suggest it to apply it only to mesh frame
>>> without interfere other data frames?
>>> Can you share your example?
>>
>> It's trivial - in ath10k_tx you do this:
>>
>> if (vif->type == NL80211_IFTYPE_MESH_POINT &&
>>  skb->ip_summed == CHECKSUM_PARTIAL)
>> skb_checksum_help(skb);
>
> Thank you Felix for the quick response.
> I agree on your user experience opinion,
> but what do you think when ath10k has a new chip supporting HW checksum for
> Mesh?

You can simply introduce a fw-feature flag saying
"supports_mesh_csum_offload" later and skip the skb_checksum_help() if
it's set.


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

Re: [PATCH] Print warnings for missing cfg80211_ops implementations

[Ola Olsson]

> but maybe it should be
>
> WARN_ON((ops->add_station && !ops->del_station) ||
> (!opt->add_station && ops->del_station))
>
> etc...

Ahh, got it! I really like your idea but I assume it's quite rare to
implement the "stop/del/leave/disconnect" callbacks and at the same
time forget to implement the "start/add/join/connect". You will
probably find out pretty quickly if the "start" functions are missing,
while it might take some time debugging why you lack the "stop"
functions (reinitialization issues/ resource leaks for example).

With that said, don't take my word for it, I was only following the
existing pattern and I assume someone else had a good reason in the
first place.

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

Re: [PATCH] Print warnings for missing cfg80211_ops implementations

[Johannes Berg]

On Thu, 2015-12-17 at 08:34 +0100, Ola Olsson wrote:
> > but maybe it should be
> > 
> > WARN_ON((ops->add_station && !ops->del_station) ||
> > (!opt->add_station && ops->del_station))
> > 
> > etc...
> 
> Ahh, got it! I really like your idea but I assume it's quite rare to
> implement the "stop/del/leave/disconnect" callbacks and at the same
> time forget to implement the "start/add/join/connect". You will
> probably find out pretty quickly if the "start" functions are
> missing,
> while it might take some time debugging why you lack the "stop"
> functions (reinitialization issues/ resource leaks for example).
> 
> With that said, don't take my word for it, I was only following the
> existing pattern and I assume someone else had a good reason in the
> first place.
> 

Pretty much what you said :)

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

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

[Johannes Berg]

On Thu, 2015-12-17 at 11:19 +0800, Dave Young wrote:
> 
> Cool, has the fix been in mainline or somewhere else?
> 

https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=a87da0cbc42949cefc8282c39ab4cb8c460bd6ea

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