Re: [PATCH] rtl8xxxu: increase polling timeout for firmware startup

[Jes Sorensen]

Daniel Lenski  writes:
> On Fri, May 20, 2016 at 1:50 PM, Daniel Lenski  wrote:
>> Am I understanding your idea correctly? To put a loop around the 8051
>> reset and the firmware polling loop, with a delay between failure and retry?
>
> That was some sloppy pseudo-code by me... here's what I think you're
> suggesting:

Actually I was more thinking along resetting it properly before tryinhg
to launch the firmware. Ie. before enabling execution.

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: [PATCH] rtl8xxxu: increase polling timeout for firmware startup

[Daniel Lenski]

On Fri, May 20, 2016 at 7:08 AM, Jes Sorensen  wrote:
>
> Daniel Lenski  writes:
> > Unfortunately, I ran into a case today where even 5000 loops was not
> > enough after a cold boot. 5000 loops meant about 1.5 second delay
> > between finishing the firmware checksum poll, while waiting for the
> > firmware to start. It now appears to me that the number of required
> > polling loops must be strongly bimodal.
> >
> > I added some logging, so that the driver reports to me the number of
> > loops required for the firmware to start.
>
> This is bizarre, I wonder if the hardware is having issues in your
> laptop? Another thing to try would be to do an additional reset of the
> chip and wait a bit before trying to load the firmware?

I tried various versions of running rtl8xxxu_init_device in a loop, with
delays in between retries, and did not have any success.

If the device doesn't want to start on the first load after boot, running
various parts of init over and over just doesn't fix it. But unloading the
driver and reloading does seem to fix it.

So then I wondered...

- Why does the firmware always (?) start on the *second try* of
  loading rtl8xxxu, even if it failed to load after thousands of loops on
  the first load attempt.
- What would be the difference between the two cases?
- As far as I understand it, the main effect on the hardware of unloading
  the driver and then reloading it is that the device is power-cycled
  (rtl8xxxu_power_off in rtl8xxxu_disable_device).
- Is it possible that the device sometimes starts up in an unknown state
  after a cold boot?
- Hypothesis: since the rtl8xxxu driver does not explicitly power off the
  device before attempting to power it on, if it boots up in an unknown
  state, it will remain in this state until explicitly power-cycled.

So then I tried powering off the device for 500ms after a failure in
rtl8xxxu_init_device, before a retry:

   for (retry=5; retry>=0; retry--) {
   ret = rtl8xxxu_init_device(hw);
   if (ret==0) {
   break;
   } else {
   dev_err(>dev, "Failed to init device,
will retry %d more times.\n", retry);
   if (retry==0)
   goto exit;
   else {
   /* power off for 500 ms before retry */
   rtl8xxxu_power_off(priv);
   msleep(500);
   }
   }
   }

So far, this always seems to work on the second try, even with a very
short firmware_poll_max (50).

I even tried forcing 50 power-cycles and inits in a row, and the firmware
still starts up on the 51st cycle, and everything works fine.

I don't understand *why* this works, but it seems like it might be a
more reliable solution, since it addresses the experience common to
the multiple bug reports, wherein the failure is only on the first attempt
after cold boot.

Thanks,
Dan
--
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: wireless-drivers-next 2016-05-13 (take two)

[David Miller]

From: Kalle Valo 
Date: Thu, 19 May 2016 15:45:08 +0300

> this the second version of the last pull request to net-next for 4.7,
> which got postponed due to the recent iwlwifi merge conflict. Now that
> Linus fixed the merge problem in his tree I actually didn't have to fix
> anything in my tree anymore. So that's why I still use the same tag as
> in my previous pull request.
> 
> The only dependency is that you need Linus' iwlwifi fix in your tree
> before you pull this:
> 
> 0e034f5c4bc4 iwlwifi: fix mis-merge that breaks the driver
> 
> So if you could pull latest Linus' tree to net-next that would solve
> that. I just did a test merge of that on your net-next tree and didn't
> see any conflicts, so this pull should go smoothly. Also these patches
> have been in linux-next at least a week now. But please let me know if
> you see any issues.

Done, pulled, thanks a lot!

> And I think a lesson learned from this is that I need to immediately
> merge wireless-drivers to wireless-drivers-next if there are any
> conflicts between the trees. Or how do you suggest to handle cases like
> that?

You shouldn't have to worry about this kind of stuff at all, and let's
just hope I handle the conflict better next time. :-)

--
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] rtl8xxxu: increase polling timeout for firmware startup

[Daniel Lenski]

On Fri, May 20, 2016 at 1:50 PM, Daniel Lenski  wrote:
> Am I understanding your idea correctly? To put a loop around the 8051
> reset and the firmware polling loop, with a delay between failure and retry?

That was some sloppy pseudo-code by me... here's what I think you're
suggesting:

for (retry=1; retry<=5; retry++) {
/* Reset the 8051 */
priv->fops->reset_8051(priv);

/* Wait for firmware to become ready */
for (i=0; i

Re: [PATCH] rtl8xxxu: increase polling timeout for firmware startup

[Daniel Lenski]

Jes Sorensen  writes:
> > Unfortunately, I ran into a case today where even 5000 loops was not
> > enough after a cold boot. 5000 loops meant about 1.5 second delay
> > between finishing the firmware checksum poll, while waiting for the
> > firmware to start. It now appears to me that the number of required
> > polling loops must be strongly bimodal.
> >
> > I added some logging, so that the driver reports to me the number of
> > loops required for the firmware to start.
>
> This is bizarre, I wonder if the hardware is having issues in your
> laptop?

The other bug reports I linked to seem identical to what's happening to
mine, so I doubt it is an issue with one specific instance of the hardware.

> Another thing to try would be to do an additional reset of the
> chip and wait a bit before trying to load the firmware?

Thanks, I will give this a shot.

Am I understanding your idea correctly? To put a loop around the 8051
reset and the firmware polling loop, with a delay between failure and retry?

for (int retry=1; ii<=MAX_RETRIES; ii++) {
for (retry=1; retry<=5; retry++) {
/* Reset the 8051 */
priv->fops->reset_8051(priv);

/* Wait for firmware to become ready */
for (i=0; i

Re: updating carl9170-1.fw in linux-firmware.git

[Xose Vazquez Perez]

On 04/20/2016 11:11 PM, Christian Lamparter wrote:

> On Wednesday, April 20, 2016 10:59:44 AM Kalle Valo wrote:
>> Christian Lamparter  writes:
>>
>>> On Monday, April 18, 2016 07:42:05 PM Kalle Valo wrote:
 Christian Lamparter  writes:

> On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote:
>
>> Why even mention anything about a "special firmware" as the firmware is
>> already available from linux-firmware.git? 
>
> Yes and no. 1.9.6 is in linux-firmware.git. I've tried to add 1.9.9 too
> but that failed.
> 

 Rick's comment makes sense to me, better just to provide the latest
 version. No need to unnecessary confuse the users. And if someone really
 wants to use an older version that she can retrieve it from the git
 history.
>>>
>>> Part of the fun here is that firmware is GPLv2. The linux-firmware.git has
>>> to point to or add the firmware source to their tree. They have added every
>>> single source file to it instead of "packaging" it in a tar.bz2/gz/xz
>>> like you normally do for release sources.
>>>
>>> If you want to read more about it:
>>> 
>>
>> Yeah, that's more work. I get that. But I'm still not understanding
>> what's the actual problem which prevents us from updating carl9170
>> firmware in linux-firmware.

> I'm not sure, but why not ask? I've added the cc'ed Linux Firmware
> Maintainers. So for those people reading the fw list:
> 
> What would it take to update the carl9170-1.fw firmware file in your
> repository to the latest version?
> 
> Who has to sent the firmware update. Does it have to be the person who
> sent the first request? (Xose)? The maintainer of the firmware (me)?
> someone from Qualcomm Atheros? Or someone else (specific)? (the 
> firmware is licensed as GPLv2 - in theory anyone should be able to
> do that)
> 
> How should the firmware source update be handled? Currently the latest
> .tar.xz of the firmware has ~130kb. The formated patches from 1.9.6 to
> latest are about ~100kb (182 individual patches).
> 
> How does linux-firmware handle new binary firmware images and new 
> sources? What if carl9170fw-2.bin is added. Do we need another
> source directory for this in the current tree then? Because 
> carl9170fw-1.bin will still be needed for backwards compatibility
> so we basically need to duplicate parts of the source?
> 
> Also, how's the situation with ath9k_htc? The 1.4.0 image contains
> some GPLv2 code as well? So, why is there no source in the tree, but 
> just the link to it? Because, I would like to do basically the same
> for carl9170fw and just add a link to the carl9170fw repository and
> save everyone this source update "song and dance".

Hi Ben, could you assist Christian ?

-thanks-
--
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: "kernel: BUG: scheduling while atomic:" errors with linux kernel 4.6

[Larry Finger]

On 05/19/2016 05:56 PM, Bob Copeland wrote:

+linux-wireless

On Thu, May 19, 2016 at 03:11:16PM -0600, James Feeney wrote:

Arch linux 4.6-1
wpa_supplicant 1:2.5-3
Toshiba Satellite, circa 2011, with a Pentium Dual-Core Mobile
Error is not seen on other machines.

kernel: BUG: scheduling while atomic: wpa_supplicant/375/0x0002


This is a kernel bug, not a wpa_supplicant bug.  The linux-wireless mailing
list would be a more appropriate venue for this bug report.



May 19 10:26:07 lapis kernel: BUG: scheduling while atomic: 
wpa_supplicant/627/0x0002

[...]

May 19 10:26:07 lapis kernel:  [] __schedule+0x899/0xad0
May 19 10:26:07 lapis kernel:  [] schedule+0x3c/0x90
May 19 10:26:07 lapis kernel:  [] 
schedule_hrtimeout_range_clock+0xa2/0x120
May 19 10:26:07 lapis kernel:  [] ? hrtimer_init+0x120/0x120
May 19 10:26:07 lapis kernel:  [] ? 
schedule_hrtimeout_range_clock+0x96/0x120
May 19 10:26:07 lapis kernel:  [] 
schedule_hrtimeout_range+0x13/0x20
May 19 10:26:07 lapis kernel:  [] usleep_range+0x4f/0x70
May 19 10:26:07 lapis kernel:  [] rtl_rfreg_delay+0x38/0x50 
[rtlwifi]
May 19 10:26:07 lapis kernel:  [] 
rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]


[Probably due to this kernel change:

commit 49f86ec21c01b654f6ec47f2f4567f4f9ebaa26b
Author: Larry Finger 
Date:   Mon Feb 15 16:12:07 2016 -0600

 rtlwifi: Change long delays to sleeps


...apparently this function isn't in sleepable context after all.]



@James: Please run the command "dmesg | grep rtl_rfreg_delay". Do any of the 
resulting lines show a value other than "+0x38" for the offset? If that is the 
only one, the attached patch should fix the problem.


Thanks,

Larry

diff --git a/Makefile b/Makefile
index 0f9cb36..080962b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 4
-PATCHLEVEL = 6
+PATCHLEVEL = 7
 SUBLEVEL = 0
-EXTRAVERSION =
+EXTRAVERSION = rc1
 NAME = Charred Weasel
 
 # *DOCUMENTATION*
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index 0f48048..2fc0e26 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -75,7 +75,7 @@ void rtl_rfreg_delay(struct ieee80211_hw *hw, enum radio_path rfpath, u32 addr,
 		rtl_addr_delay(addr);
 	} else {
 		rtl_set_rfreg(hw, rfpath, addr, mask, data);
-		usleep_range(1, 2);
+		udelay(1);
 	}
 }
 EXPORT_SYMBOL(rtl_rfreg_delay);

[PATCH 2/2] ath10k: Add board data download from target

[Sven Eckelmann]

The QCA9887 stores its calibration data (board.bin) inside the EEPROM of
the target. This has to be downloaded manually to allow the device to
initialize correctly.

Signed-off-by: Sven Eckelmann 
---
 drivers/net/wireless/ath/ath10k/core.c |  41 +-
 drivers/net/wireless/ath/ath10k/core.h |   3 +
 drivers/net/wireless/ath/ath10k/hif.h  |  14 
 drivers/net/wireless/ath/ath10k/hw.h   |  22 ++
 drivers/net/wireless/ath/ath10k/pci.c  | 139 +
 5 files changed, 218 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 0f4a4f6..a70759a 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "core.h"
 #include "mac.h"
@@ -550,6 +551,34 @@ out:
return ret;
 }
 
+static int ath10k_download_cal_eeprom(struct ath10k *ar)
+{
+   size_t data_len;
+   void *data = NULL;
+   int ret;
+
+   ret = ath10k_hif_fetch_target_board_data(ar, , _len);
+   if (ret) {
+   ath10k_warn(ar, "failed to read calibration data from EEPROM: 
%d\n",
+   ret);
+   goto out_free;
+   }
+
+   ret = ath10k_download_board_data(ar, data, data_len);
+   if (ret) {
+   ath10k_warn(ar, "failed to download calibration data from 
EEPROM: %d\n",
+   ret);
+   goto out_free;
+   }
+
+   ret = 0;
+
+out_free:
+   kfree(data);
+
+   return ret;
+}
+
 static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
 {
u32 result, address;
@@ -1312,7 +1341,17 @@ static int ath10k_download_cal_data(struct ath10k *ar)
}
 
ath10k_dbg(ar, ATH10K_DBG_BOOT,
-  "boot did not find DT entry, try OTP next: %d\n",
+  "boot did not find DT entry, try target EEPROM next: %d\n",
+  ret);
+
+   ret = ath10k_download_cal_eeprom(ar);
+   if (ret == 0) {
+   ar->cal_mode = ATH10K_CAL_MODE_EEPROM;
+   goto done;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "boot did not find target EEPROM entry, try OTP next: %d\n",
   ret);
 
ret = ath10k_download_and_run_otp(ar);
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..86d7642 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -571,6 +571,7 @@ enum ath10k_cal_mode {
ATH10K_CAL_MODE_DT,
ATH10K_PRE_CAL_MODE_FILE,
ATH10K_PRE_CAL_MODE_DT,
+   ATH10K_CAL_MODE_EEPROM,
 };
 
 enum ath10k_crypt_mode {
@@ -593,6 +594,8 @@ static inline const char *ath10k_cal_mode_str(enum 
ath10k_cal_mode mode)
return "pre-cal-file";
case ATH10K_PRE_CAL_MODE_DT:
return "pre-cal-dt";
+   case ATH10K_CAL_MODE_EEPROM:
+   return "eeprom";
}
 
return "unknown";
diff --git a/drivers/net/wireless/ath/ath10k/hif.h 
b/drivers/net/wireless/ath/ath10k/hif.h
index 89e7076..c18b8c8 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -87,6 +87,10 @@ struct ath10k_hif_ops {
 
int (*suspend)(struct ath10k *ar);
int (*resume)(struct ath10k *ar);
+
+   /* fetch board data from target eeprom */
+   int (*fetch_target_board_data)(struct ath10k *ar, void **data,
+  size_t *data_len);
 };
 
 static inline int ath10k_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
@@ -202,4 +206,14 @@ static inline void ath10k_hif_write32(struct ath10k *ar,
ar->hif.ops->write32(ar, address, data);
 }
 
+static inline int ath10k_hif_fetch_target_board_data(struct ath10k *ar,
+void **data,
+size_t *data_len)
+{
+   if (!ar->hif.ops->fetch_target_board_data)
+   return -EOPNOTSUPP;
+
+   return ar->hif.ops->fetch_target_board_data(ar, data, data_len);
+}
+
 #endif /* _HIF_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index 9108831..53ca40e 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -557,7 +557,10 @@ enum ath10k_hw_4addr_pad {
 #define WLAN_SYSTEM_SLEEP_DISABLE_MASK 0x0001
 
 #define WLAN_GPIO_PIN0_ADDRESS 0x0028
+#define WLAN_GPIO_PIN0_CONFIG_LSB  11
 #define WLAN_GPIO_PIN0_CONFIG_MASK 0x7800
+#define WLAN_GPIO_PIN0_PAD_PULL_LSB5
+#define WLAN_GPIO_PIN0_PAD_PULL_MASK   0x0060
 #define WLAN_GPIO_PIN1_ADDRESS 0x002c
 #define WLAN_GPIO_PIN1_CONFIG_MASK 0x7800
 #define 

[PATCH 0/2] ath10k: Add support for QCA9887

[Sven Eckelmann]

Hi,

the QCA9887 chip is similar to the QCA988x chips. But it requires a special
firmware and uses a different calibration data source. Unfortunately, no
working firmware currently exists. But it is possible to create a semi working
one by binary patching the current version.

# download new fw + set 
ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX+ATH10K_FW_FEATURE_NO_P2P
curl -o firmware-5.bin 
https://raw.githubusercontent.com/kvalo/ath10k-firmware/master/QCA9887/firmware-5.bin_10.2.3.31.7-1
echo -en '\x0c'|dd conv=notrunc bs=1 seek=231112 of=firmware-5.bin
mkdir -p /lib/firmware/ath10k/QCA9887/hw1.0/
mv firmware-5.bin /lib/firmware/ath10k/QCA9887/hw1.0/firmware-5.bin

I am also guessing that ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT should
also be set but this would require a ie_len of 2.


The QCA9887 support should be considered really experimental because we don't
have any information how the interface to firmware actually looks like. The
workarounds mentioned above were just implemented because we saw the firmware
crashing and then guessed the most plausible reason for it.

We are also guessing that there is no HTT_10X_T2H_MSG_TYPE_MGMT_TX_COMPL_IND in
this firmware and WMI_10X_VDEV_PARAM_RTS_FIXED_RATE maybe is also not existing
(which would reduce the value of every entry in wmi_10x_vdev_param after that
by one). But this is just a wild guess and we don't have any real information
about that.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

[PATCH 1/2] ath10k: add QCA9887 chipset support

[Sven Eckelmann]

Add the hardware name, revision, firmware names and update the pci_id
table.

QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
he firmware interface are currently unknown.

Signed-off-by: Sven Eckelmann 
---
 drivers/net/wireless/ath/ath10k/core.c  | 20 
 drivers/net/wireless/ath/ath10k/hw.h| 10 ++
 drivers/net/wireless/ath/ath10k/pci.c   | 20 ++--
 drivers/net/wireless/ath/ath10k/targaddrs.h |  3 +++
 4 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 49af624..0f4a4f6 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -69,6 +69,25 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
},
},
{
+   .id = QCA9887_HW_1_0_VERSION,
+   .dev_id = QCA9887_1_0_DEVICE_ID,
+   .name = "qca9887 hw1.0",
+   .patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
+   .uart_pin = 7,
+   .has_shifted_cc_wraparound = true,
+   .otp_exe_param = 0,
+   .channel_counters_freq_hz = 88000,
+   .max_probe_resp_desc_thres = 0,
+   .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
+   .cal_data_len = 2116,
+   .fw = {
+   .dir = QCA9887_HW_1_0_FW_DIR,
+   .board = QCA9887_HW_1_0_BOARD_DATA_FILE,
+   .board_size = QCA9887_BOARD_DATA_SZ,
+   .board_ext_size = QCA9887_BOARD_EXT_DATA_SZ,
+   },
+   },
+   {
.id = QCA6174_HW_2_1_VERSION,
.dev_id = QCA6164_2_1_DEVICE_ID,
.name = "qca6164 hw2.1",
@@ -2062,6 +2081,7 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
struct device *dev,
 
switch (hw_rev) {
case ATH10K_HW_QCA988X:
+   case ATH10K_HW_QCA9887:
ar->regs = _regs;
ar->hw_values = _values;
break;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index aedd898..9108831 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -27,6 +27,7 @@
 #define QCA6174_2_1_DEVICE_ID   (0x003e)
 #define QCA99X0_2_0_DEVICE_ID   (0x0040)
 #define QCA9377_1_0_DEVICE_ID   (0x0042)
+#define QCA9887_1_0_DEVICE_ID   (0x0050)
 
 /* QCA988X 1.0 definitions (unsupported) */
 #define QCA988X_HW_1_0_CHIP_ID_REV 0x0
@@ -38,6 +39,13 @@
 #define QCA988X_HW_2_0_BOARD_DATA_FILE "board.bin"
 #define QCA988X_HW_2_0_PATCH_LOAD_ADDR 0x1234
 
+/* QCA9887 1.0 definitions */
+#define QCA9887_HW_1_0_VERSION 0x4100016d
+#define QCA9887_HW_1_0_CHIP_ID_REV 0
+#define QCA9887_HW_1_0_FW_DIR  ATH10K_FW_DIR "/QCA9887/hw1.0"
+#define QCA9887_HW_1_0_BOARD_DATA_FILE "board.bin"
+#define QCA9887_HW_1_0_PATCH_LOAD_ADDR 0x1234
+
 /* QCA6174 target BMI version signatures */
 #define QCA6174_HW_1_0_VERSION 0x0500
 #define QCA6174_HW_1_1_VERSION 0x0501
@@ -195,6 +203,7 @@ enum ath10k_hw_rev {
ATH10K_HW_QCA99X0,
ATH10K_HW_QCA9377,
ATH10K_HW_QCA4019,
+   ATH10K_HW_QCA9887,
 };
 
 struct ath10k_hw_regs {
@@ -247,6 +256,7 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct 
survey_info *survey,
u32 cc, u32 rcc, u32 cc_prev, u32 rcc_prev);
 
 #define QCA_REV_988X(ar) ((ar)->hw_rev == ATH10K_HW_QCA988X)
+#define QCA_REV_9887(ar) ((ar)->hw_rev == ATH10K_HW_QCA9887)
 #define QCA_REV_6174(ar) ((ar)->hw_rev == ATH10K_HW_QCA6174)
 #define QCA_REV_99X0(ar) ((ar)->hw_rev == ATH10K_HW_QCA99X0)
 #define QCA_REV_9377(ar) ((ar)->hw_rev == ATH10K_HW_QCA9377)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 8133d7b..b799f46 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -57,6 +57,7 @@ static const struct pci_device_id ath10k_pci_id_table[] = {
{ PCI_VDEVICE(ATHEROS, QCA6174_2_1_DEVICE_ID) }, /* PCI-E QCA6174 V2.1 
*/
{ PCI_VDEVICE(ATHEROS, QCA99X0_2_0_DEVICE_ID) }, /* PCI-E QCA99X0 V2 */
{ PCI_VDEVICE(ATHEROS, QCA9377_1_0_DEVICE_ID) }, /* PCI-E QCA9377 V1 */
+   { PCI_VDEVICE(ATHEROS, QCA9887_1_0_DEVICE_ID) }, /* PCI-E QCA9887 */
{0}
 };
 
@@ -83,6 +84,8 @@ static const struct ath10k_pci_supp_chip 
ath10k_pci_supp_chips[] = {
 
{ QCA9377_1_0_DEVICE_ID, QCA9377_HW_1_0_CHIP_ID_REV },
{ QCA9377_1_0_DEVICE_ID, QCA9377_HW_1_1_CHIP_ID_REV },
+
+   { QCA9887_1_0_DEVICE_ID, QCA9887_HW_1_0_CHIP_ID_REV },
 };
 
 static void ath10k_pci_buffer_cleanup(struct ath10k *ar);
@@ -837,6 +840,7 @@ static u32 ath10k_pci_targ_cpu_to_ce_addr(struct ath10k 
*ar, u32 addr)
 
switch (ar->hw_rev) {
case 

Re: [PATCH] rtl8xxxu: increase polling timeout for firmware startup

[Jes Sorensen]

Daniel Lenski  writes:
> You're welcome, and thanks for writing this great driver. It really
> makes a huge difference for stability of the Yoga 13 wifi!

You're welcome! It made a big difference for my own Yoga 13 and it's
been an exciting project. I learned a lot in the process.

> Unfortunately, I ran into a case today where even 5000 loops was not
> enough after a cold boot. 5000 loops meant about 1.5 second delay
> between finishing the firmware checksum poll, while waiting for the
> firmware to start. It now appears to me that the number of required
> polling loops must be strongly bimodal.
>
> I added some logging, so that the driver reports to me the number of
> loops required for the firmware to start.

This is bizarre, I wonder if the hardware is having issues in your
laptop? Another thing to try would be to do an additional reset of the
chip and wait a bit before trying to load the firmware?

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

[PATCH 1/2] ath10k: Remove duplicate and unused rx rate flags

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

All these flags are not used and their use is completely
covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
and RX_PPDU_START_RATE_FLAG

Signed-off-by: Mohammed Shafi Shajakhan 
---
[thanks Michal/Kalle/Vasanth for the first level review]

 drivers/net/wireless/ath/ath10k/rx_desc.h |   39 -
 1 file changed, 39 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h 
b/drivers/net/wireless/ath/ath10k/rx_desc.h
index ca8d168..aa660a4 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -656,26 +656,6 @@ struct rx_msdu_end {
  * Reserved: HW should fill with zero.  FW should ignore.
  */
 
-#define RX_PPDU_START_SIG_RATE_SELECT_OFDM 0
-#define RX_PPDU_START_SIG_RATE_SELECT_CCK  1
-
-#define RX_PPDU_START_SIG_RATE_OFDM_48 0
-#define RX_PPDU_START_SIG_RATE_OFDM_24 1
-#define RX_PPDU_START_SIG_RATE_OFDM_12 2
-#define RX_PPDU_START_SIG_RATE_OFDM_6  3
-#define RX_PPDU_START_SIG_RATE_OFDM_54 4
-#define RX_PPDU_START_SIG_RATE_OFDM_36 5
-#define RX_PPDU_START_SIG_RATE_OFDM_18 6
-#define RX_PPDU_START_SIG_RATE_OFDM_9  7
-
-#define RX_PPDU_START_SIG_RATE_CCK_LP_11  0
-#define RX_PPDU_START_SIG_RATE_CCK_LP_5_5 1
-#define RX_PPDU_START_SIG_RATE_CCK_LP_2   2
-#define RX_PPDU_START_SIG_RATE_CCK_LP_1   3
-#define RX_PPDU_START_SIG_RATE_CCK_SP_11  4
-#define RX_PPDU_START_SIG_RATE_CCK_SP_5_5 5
-#define RX_PPDU_START_SIG_RATE_CCK_SP_2   6
-
 #define HTT_RX_PPDU_START_PREAMBLE_LEGACY0x04
 #define HTT_RX_PPDU_START_PREAMBLE_HT0x08
 #define HTT_RX_PPDU_START_PREAMBLE_HT_WITH_TXBF  0x09
@@ -711,25 +691,6 @@ struct rx_msdu_end {
 /* No idea what this flag means. It seems to be always set in rate. */
 #define RX_PPDU_START_RATE_FLAG BIT(3)
 
-enum rx_ppdu_start_rate {
-   RX_PPDU_START_RATE_OFDM_48M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_48M,
-   RX_PPDU_START_RATE_OFDM_24M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_24M,
-   RX_PPDU_START_RATE_OFDM_12M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_12M,
-   RX_PPDU_START_RATE_OFDM_6M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_6M,
-   RX_PPDU_START_RATE_OFDM_54M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_54M,
-   RX_PPDU_START_RATE_OFDM_36M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_36M,
-   RX_PPDU_START_RATE_OFDM_18M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_18M,
-   RX_PPDU_START_RATE_OFDM_9M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_OFDM_9M,
-
-   RX_PPDU_START_RATE_CCK_LP_11M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_11M,
-   RX_PPDU_START_RATE_CCK_LP_5_5M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_5_5M,
-   RX_PPDU_START_RATE_CCK_LP_2M   = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_2M,
-   RX_PPDU_START_RATE_CCK_LP_1M   = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_LP_1M,
-   RX_PPDU_START_RATE_CCK_SP_11M  = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_SP_11M,
-   RX_PPDU_START_RATE_CCK_SP_5_5M = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_SP_5_5M,
-   RX_PPDU_START_RATE_CCK_SP_2M   = RX_PPDU_START_RATE_FLAG | 
ATH10K_HW_RATE_CCK_SP_2M,
-};
-
 struct rx_ppdu_start {
struct {
u8 pri20_mhz;
-- 
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

[PATCH 2/2] ath10k: Fix CCK h/w rates for QCA99X0 and newer chipsets

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below

ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,

This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards

Signed-off-by: Mohammed Shafi Shajakhan 
---
[thanks Michal/Kalle/Vasanth for the first level review]

 drivers/net/wireless/ath/ath10k/core.c |2 ++
 drivers/net/wireless/ath/ath10k/core.h |6 +
 drivers/net/wireless/ath/ath10k/hw.h   |   10 
 drivers/net/wireless/ath/ath10k/mac.c  |   39 ++--
 4 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 49af624..86ed64d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -148,6 +148,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -205,6 +206,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.has_shifted_cc_wraparound = true,
.otp_exe_param = 0x001,
.continuous_frag_desc = true,
+   .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 125000,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..04cea23 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -716,6 +716,12 @@ struct ath10k {
 */
bool continuous_frag_desc;
 
+   /* CCK hardware rate table mapping for the newer chipsets
+* like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+* are in a proper order with respect to the rate/preamble
+*/
+   bool cck_rate_map_rev2;
+
u32 channel_counters_freq_hz;
 
/* Mgmt tx descriptors threshold for limiting probe response
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index aedd898..3d5648d 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -315,6 +315,16 @@ enum ath10k_hw_rate_cck {
ATH10K_HW_RATE_CCK_SP_2M,
 };
 
+enum ath10k_hw_rate_rev2_cck {
+   ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
+   ATH10K_HW_RATE_REV2_CCK_LP_2M,
+   ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+   ATH10K_HW_RATE_REV2_CCK_LP_11M,
+   ATH10K_HW_RATE_REV2_CCK_SP_2M,
+   ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+   ATH10K_HW_RATE_REV2_CCK_SP_11M,
+};
+
 enum ath10k_hw_4addr_pad {
ATH10K_HW_4ADDR_PAD_AFTER,
ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 6dd1d26..a55e3ae 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -62,6 +62,32 @@ static struct ieee80211_rate ath10k_rates[] = {
{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
 };
 
+static struct ieee80211_rate ath10k_rates_rev2[] = {
+   { .bitrate = 10,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_1M },
+   { .bitrate = 20,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_2M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_2M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+   { .bitrate = 55,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+   { .bitrate = 110,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_11M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_11M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+
+   { .bitrate = 60, .hw_value = ATH10K_HW_RATE_OFDM_6M },
+   { .bitrate = 90, .hw_value = ATH10K_HW_RATE_OFDM_9M },
+   { .bitrate = 120, .hw_value = ATH10K_HW_RATE_OFDM_12M },
+   { .bitrate = 

Re: Who is the maintainer of net/wireless/wext* ?

[Johannes Berg]

On Fri, 2016-05-20 at 12:34 +0200, Sedat Dilek wrote:
> On 5/20/16, Ujjal Roy  wrote:
> > 
> > I want to know the maintainer of
> > 
> > net/wireless/wext*. Please any reply.
> > 
> For example, you can look in the MAINTAINERS file.
> 
> CFG80211 and NL80211
> M:Johannes Berg 
> L:linux-wireless@vger.kernel.org
> W:http://wireless.kernel.org/
> T:git
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
> T:git
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
> S:Maintained
> F:include/uapi/linux/nl80211.h
> F:include/net/cfg80211.h
> F:net/wireless/*
> X:net/wireless/wext*
> 

I think the X means that it doesn't fall under this entry ...

De-facto, I'm still the maintainer though, but the status is "odd
fixes" at best.

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 V2 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

[Rafał Miłecki]

This is important for brcmfmac as some of released firmwares (e.g.
brcmfmac4366b-pcie.bin) may pick different channel than requested. This
has been tested with BCM4366B1 in D-Link DIR-885L.

Signed-off-by: Rafał Miłecki 
---
V2: Check if ndev isn't NULL, update description.
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 597495d..299a404 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4892,6 +4892,68 @@ exit:
return err;
 }
 
+static int brcmf_cfg80211_get_channel(struct wiphy *wiphy,
+ struct wireless_dev *wdev,
+ struct cfg80211_chan_def *chandef)
+{
+   struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
+   struct net_device *ndev = wdev->netdev;
+   struct brcmf_if *ifp;
+   struct brcmu_chan ch;
+   enum nl80211_band band = 0;
+   enum nl80211_chan_width width = 0;
+   u32 chanspec;
+   int freq, err;
+
+   if (!ndev)
+   return -ENODEV;
+   ifp = netdev_priv(ndev);
+
+   err = brcmf_fil_iovar_int_get(ifp, "chanspec", );
+   if (err) {
+   brcmf_err("chanspec failed (%d)\n", err);
+   return err;
+   }
+
+   ch.chspec = chanspec;
+   cfg->d11inf.decchspec();
+
+   switch (ch.band) {
+   case BRCMU_CHAN_BAND_2G:
+   band = NL80211_BAND_2GHZ;
+   break;
+   case BRCMU_CHAN_BAND_5G:
+   band = NL80211_BAND_5GHZ;
+   break;
+   }
+
+   switch (ch.bw) {
+   case BRCMU_CHAN_BW_80:
+   width = NL80211_CHAN_WIDTH_80;
+   break;
+   case BRCMU_CHAN_BW_40:
+   width = NL80211_CHAN_WIDTH_40;
+   break;
+   case BRCMU_CHAN_BW_20:
+   width = NL80211_CHAN_WIDTH_20;
+   break;
+   case BRCMU_CHAN_BW_80P80:
+   width = NL80211_CHAN_WIDTH_80P80;
+   break;
+   case BRCMU_CHAN_BW_160:
+   width = NL80211_CHAN_WIDTH_160;
+   break;
+   }
+
+   freq = ieee80211_channel_to_frequency(ch.control_ch_num, band);
+   chandef->chan = ieee80211_get_channel(wiphy, freq);
+   chandef->width = width;
+   chandef->center_freq1 = ieee80211_channel_to_frequency(ch.chnum, band);
+   chandef->center_freq2 = 0;
+
+   return 0;
+}
+
 static int brcmf_cfg80211_crit_proto_start(struct wiphy *wiphy,
   struct wireless_dev *wdev,
   enum nl80211_crit_proto_id proto,
@@ -5054,6 +5116,7 @@ static struct cfg80211_ops brcmf_cfg80211_ops = {
.mgmt_tx = brcmf_cfg80211_mgmt_tx,
.remain_on_channel = brcmf_p2p_remain_on_channel,
.cancel_remain_on_channel = brcmf_cfg80211_cancel_remain_on_channel,
+   .get_channel = brcmf_cfg80211_get_channel,
.start_p2p_device = brcmf_p2p_start_device,
.stop_p2p_device = brcmf_p2p_stop_device,
.crit_proto_start = brcmf_cfg80211_crit_proto_start,
-- 
1.8.4.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

[PATCH V2 4.8 1/2] brcmutil: add field storing control channel to the struct brcmu_chan

[Rafał Miłecki]

Our d11 code supports encoding/decoding channel info into/from chanspec
format used by firmware. Current implementation is quite misleading
because of the way "chnum" field is used.
When encoding channel info, "chnum" has to be filled by a caller with
*center* channel number. However when decoding chanspec the same field
is filled with a *control* channel number.

1) This can be confusing. It's expected for information to be the same
   after encoding and decoding.
2) It doesn't allow accessing all info when decoding. Some functions may
   need to know both channel numbers, e.g. cfg80211 callback getting
   current channel.
Solve this by adding a separated field for control channel.

Signed-off-by: Rafał Miłecki 
Reviewed-by: Arend van Spriel 
---
V2: Update commit description message.
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 17 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 10 +-
 .../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 18 ++
 .../broadcom/brcm80211/include/brcmu_d11.h | 22 ++
 4 files changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index d0631b6..597495d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2734,7 +2734,7 @@ static s32 brcmf_inform_single_bss(struct 
brcmf_cfg80211_info *cfg,
if (!bi->ctl_ch) {
ch.chspec = le16_to_cpu(bi->chanspec);
cfg->d11inf.decchspec();
-   bi->ctl_ch = ch.chnum;
+   bi->ctl_ch = ch.control_ch_num;
}
channel = bi->ctl_ch;
 
@@ -2852,7 +2852,7 @@ static s32 brcmf_inform_ibss(struct brcmf_cfg80211_info 
*cfg,
else
band = wiphy->bands[NL80211_BAND_5GHZ];
 
-   freq = ieee80211_channel_to_frequency(ch.chnum, band->band);
+   freq = ieee80211_channel_to_frequency(ch.control_ch_num, band->band);
cfg->channel = freq;
notify_channel = ieee80211_get_channel(wiphy, freq);
 
@@ -2862,7 +2862,7 @@ static s32 brcmf_inform_ibss(struct brcmf_cfg80211_info 
*cfg,
notify_ielen = le32_to_cpu(bi->ie_length);
notify_signal = (s16)le16_to_cpu(bi->RSSI) * 100;
 
-   brcmf_dbg(CONN, "channel: %d(%d)\n", ch.chnum, freq);
+   brcmf_dbg(CONN, "channel: %d(%d)\n", ch.control_ch_num, freq);
brcmf_dbg(CONN, "capability: %X\n", notify_capability);
brcmf_dbg(CONN, "beacon interval: %d\n", notify_interval);
brcmf_dbg(CONN, "signal: %d\n", notify_signal);
@@ -5280,7 +5280,7 @@ brcmf_bss_roaming_done(struct brcmf_cfg80211_info *cfg,
else
band = wiphy->bands[NL80211_BAND_5GHZ];
 
-   freq = ieee80211_channel_to_frequency(ch.chnum, band->band);
+   freq = ieee80211_channel_to_frequency(ch.control_ch_num, band->band);
notify_channel = ieee80211_get_channel(wiphy, freq);
 
 done:
@@ -5802,14 +5802,15 @@ static int brcmf_construct_chaninfo(struct 
brcmf_cfg80211_info *cfg,
channel = band->channels;
index = band->n_channels;
for (j = 0; j < band->n_channels; j++) {
-   if (channel[j].hw_value == ch.chnum) {
+   if (channel[j].hw_value == ch.control_ch_num) {
index = j;
break;
}
}
channel[index].center_freq =
-   ieee80211_channel_to_frequency(ch.chnum, band->band);
-   channel[index].hw_value = ch.chnum;
+   ieee80211_channel_to_frequency(ch.control_ch_num,
+  band->band);
+   channel[index].hw_value = ch.control_ch_num;
 
/* assuming the chanspecs order is HT20,
 * HT40 upper, HT40 lower, and VHT80.
@@ -5911,7 +5912,7 @@ static int brcmf_enable_bw40_2g(struct 
brcmf_cfg80211_info *cfg)
if (WARN_ON(ch.bw != BRCMU_CHAN_BW_40))
continue;
for (j = 0; j < band->n_channels; j++) {
-   if (band->channels[j].hw_value == ch.chnum)
+   if (band->channels[j].hw_value == 
ch.control_ch_num)
break;
}
if (WARN_ON(j == band->n_channels))
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index a70cda6..1652a48 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -1246,7 +1246,7 @@ bool 

Re: [PATCH 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

[Rafał Miłecki]

On 20 May 2016 at 09:42, Arend Van Spriel  wrote:
> On 19-5-2016 13:02, Rafał Miłecki wrote:
>> This is important for brcmfmac as the firmware may pick different
>> channel than requested. This has been tested with BCM4366B1 (in D-Link
>> DIR-885L).
>
> Can you elaborate? Is this for AP or STA mode?

This happens when using 5 GHz PHY with one AP interface. It seems
firmware respects: band, channel width & control channel location.
However it picks center channel in a more or less random way.

E.g. I configured hostapd to setup AP using 36 control channel with
VHT80 (chanspec 0xe02a). Almost every time I was restarting AP I got
firmware picking different chanspecs, all cases listed below:
0xe03a BND_5G | BW_80 | SB_LL | 58
0xe06a BND_5G | BW_80 | SB_LL | 106
0xe07a BND_5G | BW_80 | SB_LL | 122
0xe09b BND_5G | BW_80 | SB_LL | 155

I'm a bit disappointed seeing this FullMAC firmware doing such tricks
on its own. I would prefer to simply relay on hostapd doing this kind
of channel switching. I saw many times hostapd e.g. respecting my
40/80 MHz channel but switching control one in order to avoid
collisions with another AP's control frames on the same frequency.

On the other hand I never got this problem with BCM43602 using
Broadcom's official firmware, so it's some new feature you enabled
when building brcmfmac4366b-pcie.bin.


>> Signed-off-by: Rafał Miłecki 
>> ---
>>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 59 
>> ++
>>  1 file changed, 59 insertions(+)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> index 597495d..4fb9e3a 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> @@ -4892,6 +4892,64 @@ exit:
>>   return err;
>>  }
>>
>> +static int brcmf_cfg80211_get_channel(struct wiphy *wiphy,
>> +   struct wireless_dev *wdev,
>> +   struct cfg80211_chan_def *chandef)
>> +{
>> + struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
>> + struct net_device *ndev = wdev->netdev;
>> + struct brcmf_if *ifp = netdev_priv(ndev);
>
> Can this operation be done on a P2P_DEVICE interface, ie. wdev->netdev
> == NULL?

I don't have any experience with P2P, thanks a lot for pointing this to me!


>> + struct brcmu_chan ch;
>> + enum nl80211_band band = 0;
>> + enum nl80211_chan_width width = 0;
>> + u32 chanspec;
>> + int freq, err;
>> +
>> + err = brcmf_fil_iovar_int_get(ifp, "chanspec", );
>> + if (err) {
>> + brcmf_err("chanspec failed (%d)\n", err);
>> + return err;
>> + }
>> +
>> + ch.chspec = chanspec;
>> + cfg->d11inf.decchspec();
>> +
>> + switch (ch.band) {
>> + case BRCMU_CHAN_BAND_2G:
>> + band = NL80211_BAND_2GHZ;
>> + break;
>> + case BRCMU_CHAN_BAND_5G:
>> + band = NL80211_BAND_5GHZ;
>> + break;
>> + }
>> +
>> + switch (ch.bw) {
>> + case BRCMU_CHAN_BW_80:
>> + width = NL80211_CHAN_WIDTH_80;
>> + break;
>> + case BRCMU_CHAN_BW_40:
>> + width = NL80211_CHAN_WIDTH_40;
>> + break;
>> + case BRCMU_CHAN_BW_20:
>> + width = NL80211_CHAN_WIDTH_20;
>> + break;
>> + case BRCMU_CHAN_BW_80P80:
>> + width = NL80211_CHAN_WIDTH_80P80;
>> + break;
>
> Not much sense to support this given that center_freq2 is set to zero below.

OK.
--
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: Who is the maintainer of net/wireless/wext* ?

[Zefir Kurtisi]

On 05/20/2016 12:34 PM, Sedat Dilek wrote:
> On 5/20/16, Ujjal Roy  wrote:
>> I want to know the maintainer of
>>
>> net/wireless/wext*. Please any reply.
>>
> 
> For example, you can look in the MAINTAINERS file.
> 
> CFG80211 and NL80211
> M:Johannes Berg 
> L:linux-wireless@vger.kernel.org
> W:http://wireless.kernel.org/
> T:git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
> T:git 
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
> S:Maintained
> F:include/uapi/linux/nl80211.h
> F:include/net/cfg80211.h
> F:net/wireless/*
> X:net/wireless/wext*
> 
> - Sedat -
> 
> [1] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n2890

Maybe also helpful: ./scripts/get_maintainer.pl -f net/wireless/wext*

Cheers,
Zefir
--
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: Who is the maintainer of net/wireless/wext* ?

[Sedat Dilek]

On 5/20/16, Ujjal Roy  wrote:
> I want to know the maintainer of
>
> net/wireless/wext*. Please any reply.
>

For example, you can look in the MAINTAINERS file.

CFG80211 and NL80211
M:  Johannes Berg 
L:  linux-wireless@vger.kernel.org
W:  http://wireless.kernel.org/
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
T:  git 
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S:  Maintained
F:  include/uapi/linux/nl80211.h
F:  include/net/cfg80211.h
F:  net/wireless/*
X:  net/wireless/wext*

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n2890
--
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

Who is the maintainer of net/wireless/wext* ?

[Ujjal Roy]

I want to know the maintainer of

net/wireless/wext*. Please any reply.

Thanks,
UjjaL Roy
--
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 iw] add "channels" PHY command listing frequencies with more details

[Rafał Miłecki]

Channels (frequencies) are getting more details that users may want to
know about. E.g. it's important to know which frequencies allow using
40/80/160 MHz channels to setup AP properly.

We list channels in "info" command output but it's already quite big and
it was agreed to introduce new command rather than expand the old one.

This patch adds "channels" command printing what was already available
in the "info" plus details about supported channel widths. It also
removes DFS info from the "info" output.

Signed-off-by: Rafał Miłecki 
---
 info.c |  30 --
 phy.c  | 143 +
 2 files changed, 143 insertions(+), 30 deletions(-)

diff --git a/info.c b/info.c
index 32de0af..b375123 100644
--- a/info.c
+++ b/info.c
@@ -47,20 +47,6 @@ static char *cipher_name(__u32 c)
}
 }
 
-static char *dfs_state_name(enum nl80211_dfs_state state)
-{
-   switch (state) {
-   case NL80211_DFS_USABLE:
-   return "usable";
-   case NL80211_DFS_AVAILABLE:
-   return "available";
-   case NL80211_DFS_UNAVAILABLE:
-   return "unavailable";
-   default:
-   return "unknown";
-   }
-}
-
 static int ext_feature_isset(const unsigned char *ext_features, int 
ext_features_len,
 enum nl80211_ext_feature_index ftidx)
 {
@@ -198,22 +184,6 @@ next:
if (open)
printf(")");
printf("\n");
-
-   if 
(!tb_freq[NL80211_FREQUENCY_ATTR_DISABLED] && 
tb_freq[NL80211_FREQUENCY_ATTR_DFS_STATE]) {
-   enum nl80211_dfs_state state = 
nla_get_u32(tb_freq[NL80211_FREQUENCY_ATTR_DFS_STATE]);
-   unsigned long time;
-
-   printf("\t\t\t  DFS state: %s", 
dfs_state_name(state));
-   if 
(tb_freq[NL80211_FREQUENCY_ATTR_DFS_TIME]) {
-   time = 
nla_get_u32(tb_freq[NL80211_FREQUENCY_ATTR_DFS_TIME]);
-   printf(" (for %lu 
sec)", time/1000);
-   }
-   printf("\n");
-   if 
(tb_freq[NL80211_FREQUENCY_ATTR_DFS_CAC_TIME])
-   printf("\t\t\t  DFS CAC 
time: %u ms\n",
-  
nla_get_u32(tb_freq[NL80211_FREQUENCY_ATTR_DFS_CAC_TIME]));
-   }
-
}
}
 
diff --git a/phy.c b/phy.c
index 13e8260..0639f25 100644
--- a/phy.c
+++ b/phy.c
@@ -14,6 +14,149 @@
 #include "nl80211.h"
 #include "iw.h"
 
+static char *dfs_state_name(enum nl80211_dfs_state state)
+{
+   switch (state) {
+   case NL80211_DFS_USABLE:
+   return "usable";
+   case NL80211_DFS_AVAILABLE:
+   return "available";
+   case NL80211_DFS_UNAVAILABLE:
+   return "unavailable";
+   default:
+   return "unknown";
+   }
+}
+
+static int print_channels_handler(struct nl_msg *msg, void *arg)
+{
+   struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+
+   struct nlattr *tb_msg[NL80211_ATTR_MAX + 1];
+   struct nlattr *tb_band[NL80211_BAND_ATTR_MAX + 1];
+   struct nlattr *tb_freq[NL80211_FREQUENCY_ATTR_MAX + 1];
+   struct nlattr *nl_band;
+   struct nlattr *nl_freq;
+   int rem_band, rem_freq;
+   static int last_band = -1;
+   bool width_40, width_80, width_160;
+
+   nla_parse(tb_msg, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0), 
genlmsg_attrlen(gnlh, 0), NULL);
+
+   if (tb_msg[NL80211_ATTR_WIPHY_BANDS]) {
+   nla_for_each_nested(nl_band, tb_msg[NL80211_ATTR_WIPHY_BANDS], 
rem_band) {
+   if (last_band != nl_band->nla_type) {
+   printf("Band %d:\n", nl_band->nla_type + 1);
+   width_40 = false;
+   width_80 = false;
+   width_160 = false;
+   last_band = nl_band->nla_type;
+   }
+
+   nla_parse(tb_band, NL80211_BAND_ATTR_MAX, 
nla_data(nl_band), nla_len(nl_band), NULL);
+
+   if (tb_band[NL80211_BAND_ATTR_HT_CAPA]) {
+   __u16 cap = 
nla_get_u16(tb_band[NL80211_BAND_ATTR_HT_CAPA]);
+
+   if (cap & BIT(1))
+   width_40 = true;
+   }
+
+   if (tb_band[NL80211_BAND_ATTR_VHT_CAPA]) {
+

Re: [PATCH] brcmfmac: use kmemdup

[Arend Van Spriel]

On 19-5-2016 15:59, Muhammad Falak R Wani wrote:
> Use kmemdup when some other buffer is immediately copied into allocated
> region. It replaces call to allocation followed by memcpy, by a single
> call to kmemdup.

Acked-by: Arend van Spriel 
> Signed-off-by: Muhammad Falak R Wani 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index d0631b6..705adaa 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6699,11 +6699,10 @@ struct brcmf_cfg80211_info 
> *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
>   return NULL;
>   }
>  
> - ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> + ops = kmemdup(_cfg80211_ops, sizeof(*ops), GFP_KERNEL);
>   if (!ops)
>   return NULL;
>  
> - memcpy(ops, _cfg80211_ops, sizeof(*ops));
>   ifp = netdev_priv(ndev);
>  #ifdef CONFIG_PM
>   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_WOWL_GTK))
> 
--
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 4.8 1/2] brcmutil: add field storing control channel to the struct brcmu_chan

[Arend Van Spriel]

On 19-5-2016 13:02, Rafał Miłecki wrote:
> Our d11 code supports encoding/decoding channel info into/from chanspec
> format used by firmware. Current implementation is quite misleading
> because of the way "chnum" field is used.
> When encoding channel info, "chnum" has to be filled by a caller with
> *center* channel number. However when decoding chanspec the same field
> is filled with a *control* channel number.
> 
> This can be confusing and doesn't allow accessing all info when
> decoding. Solve it by adding a separated field for control channel.

The need to "access all info" is probably the other patch so you might
hint here that this change is needed for the .get_channel() callback.

Reviewed-by: Arend van Spriel 
> Signed-off-by: Rafał Miłecki 
> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 17 +
>  .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 10 +-
>  .../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 18 ++
>  .../broadcom/brcm80211/include/brcmu_d11.h | 22 
> ++
>  4 files changed, 46 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index d0631b6..597495d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -2734,7 +2734,7 @@ static s32 brcmf_inform_single_bss(struct 
> brcmf_cfg80211_info *cfg,
>   if (!bi->ctl_ch) {
>   ch.chspec = le16_to_cpu(bi->chanspec);
>   cfg->d11inf.decchspec();
> - bi->ctl_ch = ch.chnum;
> + bi->ctl_ch = ch.control_ch_num;
>   }
>   channel = bi->ctl_ch;
>  
> @@ -2852,7 +2852,7 @@ static s32 brcmf_inform_ibss(struct brcmf_cfg80211_info 
> *cfg,
>   else
>   band = wiphy->bands[NL80211_BAND_5GHZ];
>  
> - freq = ieee80211_channel_to_frequency(ch.chnum, band->band);
> + freq = ieee80211_channel_to_frequency(ch.control_ch_num, band->band);
>   cfg->channel = freq;
>   notify_channel = ieee80211_get_channel(wiphy, freq);
>  
> @@ -2862,7 +2862,7 @@ static s32 brcmf_inform_ibss(struct brcmf_cfg80211_info 
> *cfg,
>   notify_ielen = le32_to_cpu(bi->ie_length);
>   notify_signal = (s16)le16_to_cpu(bi->RSSI) * 100;
>  
> - brcmf_dbg(CONN, "channel: %d(%d)\n", ch.chnum, freq);
> + brcmf_dbg(CONN, "channel: %d(%d)\n", ch.control_ch_num, freq);
>   brcmf_dbg(CONN, "capability: %X\n", notify_capability);
>   brcmf_dbg(CONN, "beacon interval: %d\n", notify_interval);
>   brcmf_dbg(CONN, "signal: %d\n", notify_signal);
> @@ -5280,7 +5280,7 @@ brcmf_bss_roaming_done(struct brcmf_cfg80211_info *cfg,
>   else
>   band = wiphy->bands[NL80211_BAND_5GHZ];
>  
> - freq = ieee80211_channel_to_frequency(ch.chnum, band->band);
> + freq = ieee80211_channel_to_frequency(ch.control_ch_num, band->band);
>   notify_channel = ieee80211_get_channel(wiphy, freq);
>  
>  done:
> @@ -5802,14 +5802,15 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>   channel = band->channels;
>   index = band->n_channels;
>   for (j = 0; j < band->n_channels; j++) {
> - if (channel[j].hw_value == ch.chnum) {
> + if (channel[j].hw_value == ch.control_ch_num) {
>   index = j;
>   break;
>   }
>   }
>   channel[index].center_freq =
> - ieee80211_channel_to_frequency(ch.chnum, band->band);
> - channel[index].hw_value = ch.chnum;
> + ieee80211_channel_to_frequency(ch.control_ch_num,
> +band->band);
> + channel[index].hw_value = ch.control_ch_num;
>  
>   /* assuming the chanspecs order is HT20,
>* HT40 upper, HT40 lower, and VHT80.
> @@ -5911,7 +5912,7 @@ static int brcmf_enable_bw40_2g(struct 
> brcmf_cfg80211_info *cfg)
>   if (WARN_ON(ch.bw != BRCMU_CHAN_BW_40))
>   continue;
>   for (j = 0; j < band->n_channels; j++) {
> - if (band->channels[j].hw_value == ch.chnum)
> + if (band->channels[j].hw_value == 
> ch.control_ch_num)
>   break;
>   }
>   if (WARN_ON(j == band->n_channels))
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
> index a70cda6..1652a48 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
> @@ -1246,7 

Re: [PATCH 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

[Arend Van Spriel]

On 19-5-2016 13:02, Rafał Miłecki wrote:
> This is important for brcmfmac as the firmware may pick different
> channel than requested. This has been tested with BCM4366B1 (in D-Link
> DIR-885L).

Can you elaborate? Is this for AP or STA mode?

> Signed-off-by: Rafał Miłecki 
> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 59 
> ++
>  1 file changed, 59 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 597495d..4fb9e3a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -4892,6 +4892,64 @@ exit:
>   return err;
>  }
>  
> +static int brcmf_cfg80211_get_channel(struct wiphy *wiphy,
> +   struct wireless_dev *wdev,
> +   struct cfg80211_chan_def *chandef)
> +{
> + struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
> + struct net_device *ndev = wdev->netdev;
> + struct brcmf_if *ifp = netdev_priv(ndev);

Can this operation be done on a P2P_DEVICE interface, ie. wdev->netdev
== NULL?

> + struct brcmu_chan ch;
> + enum nl80211_band band = 0;
> + enum nl80211_chan_width width = 0;
> + u32 chanspec;
> + int freq, err;
> +
> + err = brcmf_fil_iovar_int_get(ifp, "chanspec", );
> + if (err) {
> + brcmf_err("chanspec failed (%d)\n", err);
> + return err;
> + }
> +
> + ch.chspec = chanspec;
> + cfg->d11inf.decchspec();
> +
> + switch (ch.band) {
> + case BRCMU_CHAN_BAND_2G:
> + band = NL80211_BAND_2GHZ;
> + break;
> + case BRCMU_CHAN_BAND_5G:
> + band = NL80211_BAND_5GHZ;
> + break;
> + }
> +
> + switch (ch.bw) {
> + case BRCMU_CHAN_BW_80:
> + width = NL80211_CHAN_WIDTH_80;
> + break;
> + case BRCMU_CHAN_BW_40:
> + width = NL80211_CHAN_WIDTH_40;
> + break;
> + case BRCMU_CHAN_BW_20:
> + width = NL80211_CHAN_WIDTH_20;
> + break;
> + case BRCMU_CHAN_BW_80P80:
> + width = NL80211_CHAN_WIDTH_80P80;
> + break;

Not much sense to support this given that center_freq2 is set to zero below.

Regards,
Arend

> + case BRCMU_CHAN_BW_160:
> + width = NL80211_CHAN_WIDTH_160;
> + break;
> + }
> +
> + freq = ieee80211_channel_to_frequency(ch.control_ch_num, band);
> + chandef->chan = ieee80211_get_channel(wiphy, freq);
> + chandef->width = width;
> + chandef->center_freq1 = ieee80211_channel_to_frequency(ch.chnum, band);
> + chandef->center_freq2 = 0;
> +
> + return 0;
> +}
> +
>  static int brcmf_cfg80211_crit_proto_start(struct wiphy *wiphy,
>  struct wireless_dev *wdev,
>  enum nl80211_crit_proto_id proto,
> @@ -5054,6 +5112,7 @@ static struct cfg80211_ops brcmf_cfg80211_ops = {
>   .mgmt_tx = brcmf_cfg80211_mgmt_tx,
>   .remain_on_channel = brcmf_p2p_remain_on_channel,
>   .cancel_remain_on_channel = brcmf_cfg80211_cancel_remain_on_channel,
> + .get_channel = brcmf_cfg80211_get_channel,
>   .start_p2p_device = brcmf_p2p_start_device,
>   .stop_p2p_device = brcmf_p2p_stop_device,
>   .crit_proto_start = brcmf_cfg80211_crit_proto_start,
> 
--
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