Re: [PATCH 1/3] ath10k: embed supported chip ids in hw_params

[Michal Kazior]

On 26 November 2014 at 08:21, Kalle Valo  wrote:
> Michal Kazior  writes:
>
>> This will make it easier to extend and maintain
>> list of supported hardware.
>>
>> As a requirement this moves chip_id checking a
>> little later because target_version isn't known
>> until BMI can be queried.
>>
>> Signed-off-by: Michal Kazior 
>
> The reason why I originally added the chip_id check was that QCA988X hw
> 1.0 failed badly (ath10k might have even crashed, don't remember
> anymore) and I added this chip_id as an ugly workaround to detect hw1.0
> early. Most likely with this patch the problem comes back again.

Hmm.. good point. I think it mostly failed during firmware transfer to
target but since BMI also needs CE then it might as well fail mid-way.


> I don't know what's a good solution, need to think more. Any ideas?

Hmm.. I have a couple of ideas:

1. Don't use BMI to read target_version. Instead use a register
(assuming there is one). This implies each transport (we have pci only
now) would need to be able to read it somehow unless we support a
fallback to BMI if it wasn't prepped by the transport.

2. Have a dedicatd pci-specific structure:

 struct ath10k_pci_supported_chip {
   u16 dev_id;
   u32 chip_id;
 };

 struct ath10k_pci_supported_chip ath10k_pci_supported_chips[] = {
   { QCA988X_2_0_DEVICE_ID, QCA988X_HW_2_0_CHIP_ID_REV },
   // ...
 };

Probably the simplest and has least impact.

3. Don't use target_version to decide hw_params. Use pci device id
instead. This is a bit of a problem because ath10k_hw_params_list is
in core and is supposed to be transport-agnostic (but should it really
be? I can imagine theoretical usb transport could have devices
reporting identical target_version as a pci one but would need
different firmware files to be used). This probably needs more
thinking through.


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 1/3] ath10k: embed supported chip ids in hw_params

[Kalle Valo]

Michal Kazior  writes:

> This will make it easier to extend and maintain
> list of supported hardware.
>
> As a requirement this moves chip_id checking a
> little later because target_version isn't known
> until BMI can be queried.
>
> Signed-off-by: Michal Kazior 

The reason why I originally added the chip_id check was that QCA988X hw
1.0 failed badly (ath10k might have even crashed, don't remember
anymore) and I added this chip_id as an ugly workaround to detect hw1.0
early. Most likely with this patch the problem comes back again.

I don't know what's a good solution, need to think more. Any ideas?

-- 
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 2/2] ath10k: add new wmi interface of NF cal period

[Kalle Valo]

Peter Oh  writes:

> Introduce a new wmi interface controls noise floor (NF) calibration
> period via debugfs as firmware has introduced it on v10.2.
>
> It allows users to modify frequency of NF calibration in millisecond
> and changes RSSI reporting frequency consequently.
> Short calibration period will trigger more frequent NF calibration,
> so that RSSI reported in receive frames is more realistic.
>
> Till now calibration was done at 30 seconds.
>
> Signed-off-by: Peter Oh 

There was a trivial conflict in struct ath10k_debug, please double check
my conflict resolution:

https://github.com/kvalo/ath/commit/1abcc1aa6046231a55a296ea78ab2f374f6f791b

-- 
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 v2 1/3] ath10k: add missing goto

[Kalle Valo]

Michal Kazior  writes:

> This prevents warning spamming if peer creation
> fails during sta_state in some cases.
>
> Signed-off-by: Michal Kazior 

Thanks, all three patches applied.

-- 
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 v3 0/2] ath10k: firmware memory debugfs interface

[Kalle Valo]

Kalle Valo  writes:

> this is v3 of Yanbo's firmware memory debugfs interface.
>
> Changelog:
>
> v3:
>
> * check ath10k state and return an error if firmware is not running
>
> * switch to use conf_mutex because using ar->state
>
> * fix copy_from_user() error handling
>
> v2:
>
> * split patches into two
>
> * simplify the commit logs
>
> * remove extra #include "hif.h" from debug.c
>
> ---
>
> Yanbo Li (2):
>   ath10k: add register access debugfs interface
>   ath10k: add memory dump debugfs interface

Thanks Yanbo, both patches applied.

-- 
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 v2 1/3] ath10k: Fix shared WEP

[Kalle Valo]

Sujith Manoharan  writes:

> From: Sujith Manoharan 
>
> When static keys are used in shared WEP, when a
> station is associated, message 3 is sent with an
> encrypted payload. But, for subsequent
> authentications that are triggered without a
> deauth, the auth frame is decrypted by the HW.
>
> To handle this, check if the WEP keys have already
> been set for the peer and if so, mark the
> frame as decrypted. This scenario can happen
> when a station changes its default TX key and initiates
> a new authentication sequence.
>
> Signed-off-by: Sujith Manoharan 

Thanks, all three applied.

-- 
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] ath10k: don't drop corrupted mgmt frames

[Kalle Valo]

Michal Kazior  writes:

> Some firmware revisions don't seem to deilver
> management frames with FCS error via WMI so narrow
> down the HTT rule to not drop corrupted management
> frames.
>
> This basically increases number of frames ath10k
> reports while sniffing.
>
> Signed-off-by: Michal Kazior 

Thanks, applied.

-- 
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] ath10k: don't drop corrupted mgmt frames

[Kalle Valo]

Michal Kazior  writes:

> Some firmware revisions don't seem to deilver
> management frames with FCS error via WMI so narrow
> down the HTT rule to not drop corrupted management
> frames.
>
> This basically increases number of frames ath10k
> reports while sniffing.
>
> Signed-off-by: Michal Kazior 

Thanks, applied.

-- 
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/3] ath10k: fix offchan reliability

[Kalle Valo]

Michal Kazior  writes:

> New firmware revisions don't need peer creation
> when doing offchannel tx. Earlier revisions would
> queue and never release frames without a peer.
>
> This prevent new firmware revisions from stopping
> replenishing wmi-htc tx credits and improves
> reliability of offchannel tx which would sometimes
> silently fail.
>
> Signed-off-by: Michal Kazior 

Thanks, all three patches applied.

-- 
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] ath10k: remove extra_tx_headroom

[Kalle Valo]

Michal Kazior  writes:

> Comment was out-of-date. The headroom is no longer
> necessary because HTT Tx fragment list is stored
> in dma pool item associated with each sk_buff.
>
> Signed-off-by: Michal Kazior 

Thanks, applied.

-- 
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 v2 06/10] ath10k: use configured nss instead of max nss.

[Kalle Valo]

gree...@candelatech.com writes:

> From: Ben Greear 
>
> When re-associating a station, the nss was set back to
> maximum value even if user had configured small number
> of tx chains.  So, pay attention to user's config in
> this case as well.
>
> Signed-off-by: Ben Greear 

Thanks, applied.

-- 
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 v2 05/10] ath10k: apply chainmask settings to vdev on creation.

[Kalle Valo]

gree...@candelatech.com writes:

> From: Ben Greear 
>
> It appears it takes more than just setting the
> hardware's chainmask to make things work well.  Without
> this patch, a vdev would only use 1x1 rates when chainmask
> was set to 0x3.
>
> Setting the 'nss' (number of spatial streams) on the vdev
> helps the firmware's rate-control algorithm work properly.
>
> Tested on CT firmware, but probably this works (and
> is required) on normal firmware.
>
> Signed-off-by: Ben Greear 
> ---
>
> v2:  Add warning if chainmask is set to probably-invalid configuration.
>   Also, from a quick test, it appears you cannot even set the chainmask
>   using 'iw' when vdevs are active.

Thanks, applied.

-- 
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

[PATCH] mmc: new API for data write using scatter gather DMA

[Avinash Patil]

From: Bing Zhao 

This patch adds new API to handle scatter gather aggregation.

Signed-off-by: Bing Zhao 
Signed-off-by: Avinash Patil 
Signed-off-by: Xinming Hu 
Signed-off-by: Cathy Luo 
---
 drivers/mmc/core/sdio_ops.c   | 65 +++
 include/linux/mmc/sdio_func.h |  5 
 2 files changed, 70 insertions(+)

diff --git a/drivers/mmc/core/sdio_ops.c b/drivers/mmc/core/sdio_ops.c
index 62508b4..4c5e362 100644
--- a/drivers/mmc/core/sdio_ops.c
+++ b/drivers/mmc/core/sdio_ops.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "core.h"
 #include "sdio_ops.h"
@@ -204,6 +205,70 @@ int mmc_io_rw_extended(struct mmc_card *card, int write, 
unsigned fn,
return 0;
 }
 
+int mmc_io_rw_extended_sg(struct mmc_card *card, int write, unsigned fn,
+ unsigned addr, int incr_addr,
+ struct sg_table *sgt, unsigned blksz)
+{
+   struct mmc_request mrq = {NULL};
+   struct mmc_command cmd = {0};
+   struct mmc_data data = {0};
+   struct scatterlist *sg_ptr;
+   unsigned blocks = 0;
+   int i;
+
+   BUG_ON(!card || !card->host);
+   BUG_ON(fn > 7);
+   BUG_ON(!blksz);
+   for_each_sg(sgt->sgl, sg_ptr, sgt->nents, i) {
+   WARN_ON(sg_ptr->length > card->host->max_seg_size);
+   blocks += DIV_ROUND_UP(sg_ptr->length, blksz);
+   }
+
+   /* sanity check */
+   if (addr & ~0x1)
+   return -EINVAL;
+
+   mrq.cmd = &cmd;
+   mrq.data = &data;
+
+   cmd.opcode = SD_IO_RW_EXTENDED;
+   cmd.arg = write ? 0x8000 : 0x;
+   cmd.arg |= fn << 28;
+   cmd.arg |= incr_addr ? 0x0400 : 0x;
+   cmd.arg |= addr << 9;
+   cmd.arg |= 0x0800 | blocks;
+   cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_ADTC;
+
+   data.blksz = blksz;
+   data.blocks = blocks;
+   data.flags = write ? MMC_DATA_WRITE : MMC_DATA_READ;
+
+   data.sg = sgt->sgl;
+   data.sg_len = sgt->nents;
+
+   mmc_set_data_timeout(&data, card);
+   mmc_wait_for_req(card->host, &mrq);
+
+   if (cmd.error)
+   return cmd.error;
+   if (data.error)
+   return data.error;
+
+   if (mmc_host_is_spi(card->host)) {
+   /* host driver already reported errors */
+   } else {
+   if (cmd.resp[0] & R5_ERROR)
+   return -EIO;
+   if (cmd.resp[0] & R5_FUNCTION_NUMBER)
+   return -EINVAL;
+   if (cmd.resp[0] & R5_OUT_OF_RANGE)
+   return -ERANGE;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(mmc_io_rw_extended_sg);
+
 int sdio_reset(struct mmc_host *host)
 {
int ret;
diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
index 50f0bc9..927ea8f 100644
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -153,6 +154,10 @@ extern int sdio_memcpy_toio(struct sdio_func *func, 
unsigned int addr,
 extern int sdio_writesb(struct sdio_func *func, unsigned int addr,
void *src, int count);
 
+int mmc_io_rw_extended_sg(struct mmc_card *card, int write, unsigned fn,
+ unsigned addr, int incr_addr,
+ struct sg_table *sgt, unsigned blksz);
+
 extern unsigned char sdio_f0_readb(struct sdio_func *func,
unsigned int addr, int *err_ret);
 extern void sdio_f0_writeb(struct sdio_func *func, unsigned char b,
-- 
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: ath9k -> bogus usb xfer on at91

[David Lechner]

On 7 July 2014 17:08, Oleksij Rempel  wrote:
>/  Am 07.07.2014 15:40, schrieb Anders Darander:/
>/> On 4 July 2014 18:54, Oleksij Rempel  wrote:/
>/>> Am 04.07.2014 18:30, schrieb Alan Stern:/
>/>>> On Fri, 4 Jul 2014, Anders Darander wrote:/
>/ ~# usb 1-1: new full-speed USB device number 3 using at91_ohci/
>/ usb 1-1: ath9k_htc: Firmware htc_9271.fw requested/
>/ usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272/
>/ ---[ cut here ]---/
>/ WARNING: CPU: 0 PID: 93 at/
>/ 
/mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450/
>/ usb_submit_urb+0x2ac/0x460()/
>/ usb 1-1: BOGUS urb xfer, pipe 1 != type 3/
>/>/
>/>>>/
>/>>> I can't tell exactly where the fault is, but this message means that an/
>/>>> URB was submitted for a bulk endpoint with a pipe of type/
>/>>> PIPE_INTERRUPT./
>/>>/
>/>> Then kernel driver and firmware should be updated. There was some/
>/>> Bulk/Interrupt issues which was fixed last year./
>/>/
>/> Any pointers to the bulk/interrupt issues? Was it a general issue, or/
>/> related either to/
>/> at91-ohci or ar9271?/
>
>/  It is primary ar9271 issue. The interrupt EP has different response time/
>/  on different host controllers. Initially as workaround ath9k was forcing/
>/  Bulk traffic on Interrupt EP. But this workaround is working with some/
>/  host controllers and completely fails on others. So i removed it. The/
>/  patches are included in master kernel branch and git firmware source./

Thanks for the comments!
I'll take a look at it, though it might have to be scheduled after the
upcoming vacations...

I'll sure try to look into those workarounds (and your removal of
those). I guess that
it's the firmware in open-ath9-htc-firmware you're talking about.

>/>/
>/> As far as I've been able to find out, I've got the latest firmware/
>/> (check again with linux-firmware)./
>/> I've also tried with the master from open-ath9k-htc-firmware./
>/>/
>/>> I hope this HW will not be used as AP./
>/>/
>/> Is this based on the use of at91- SoC, or based on the ar9271?/
>
>/  ar9271 can work as AP with limit on 8 stations but according to user/
>/  reports it fails even with one station on at91/
>
>/> The primary use case is to run as a client, though there will likely/
>/> be some instances where it'll/
>/> function as a AP. (Though primarily for M2M communications), thus/
>/> pretty low traffic./
>
>/  For AP usually should be created monitor mode interface for receiving/
>/  and transmitting management frames. Depending on location and STAs or/
>/  APs working on same channel, you will get a lot of traffic on this usb/
>/  interface./
>/  Some users reported huge traffic drops on at91 based APs. Since i can't/
>/  debug it, i can't promise that it will be fixed any time soon./

Again, thanks for the information.
I think I've got a much better understanding of the issues (both those that I've
seen, and those that you have mentioned / explained). I'll see when/what I can
look into this and what I can find out.

Cheers,
Anders


Anders, did you ever have a chance to look at this? I am seeing this 
same warning that is filling up the kernel logs in v3.18-rc6.


The device I am using is:

|ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]||

I found that if I revert kernel commit 2b72111 that the warning stops, but the device 
does not work very well.||If you are interested to know more about the symptoms we 
are seeing, there is a bug report here: 
. But, I figured at least knowing 
the kernel commit that introduced the problem would be helpful.|



||
--
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: Setting WLAN RF Sensitivity value

[Dan Williams]

On Wed, 2014-11-26 at 02:12 +0300, Sergey Ryazanov wrote:
> 2014-11-25 19:21 GMT+03:00 Mohammad Ali Ma Abu Shattal
> :
> > Dear Sir/Madam,
> >
> > I'm working on a project in which we need to set and get RF sensitivity of 
> > WLAN device.
> Could you specify, what exactly parameter do you want to control? In
> the your askubuntu post, you refer to "iwconfig wlan0 sens" command,
> which can control too many aspects, including the selection of the
> best AP and the detection of channel busy condition. And actual
> parameter "depends on the hardware implementation" as said in iwconfig
> manpage.

Indeed, only airo, ipw2200, hostap, and prism54 support this feature,
all of these are extremely old drivers.  mac80211 does not support it.
It appears to be used in the old drivers to ignore any signal quieter
than the given sensitivity.

Dan

> > I tried to set other settings such as operation mode, txpower and frequency 
> > using Linux commands : "ioctl" and "iwconfig" and it works fine.
> Consider using NL80211 and "iw" utility, since IOCTL based
> wireless-extensions interface is deprecated.
> 
> > Manufacturer of my device is Broadcom. It seems that either the hardware or 
> > the driver doesn't support setting and getting sensitivity. I need to know 
> > if there exists a device and/or device driver that support this feature. 
> > details of my current hardware and device driver are posted in the 
> > askubuntu question:
> > http://askubuntu.com/questions/553286/wlan-sensitivity-setting-is-not-supported
> > kindly send me your recommendation for such device or device driver.
> >
> > best regards,
> > Mohammad
> > 
> > Mohammad Abu Shattal
> > Ph.D Student
> > Department of Electrical & Computer Engineering
> > Western Michigan University
> > Kalamazoo, MI 49008
> 


--
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: Setting WLAN RF Sensitivity value

[Sergey Ryazanov]

2014-11-25 19:21 GMT+03:00 Mohammad Ali Ma Abu Shattal
:
> Dear Sir/Madam,
>
> I'm working on a project in which we need to set and get RF sensitivity of 
> WLAN device.
Could you specify, what exactly parameter do you want to control? In
the your askubuntu post, you refer to "iwconfig wlan0 sens" command,
which can control too many aspects, including the selection of the
best AP and the detection of channel busy condition. And actual
parameter "depends on the hardware implementation" as said in iwconfig
manpage.

> I tried to set other settings such as operation mode, txpower and frequency 
> using Linux commands : "ioctl" and "iwconfig" and it works fine.
Consider using NL80211 and "iw" utility, since IOCTL based
wireless-extensions interface is deprecated.

> Manufacturer of my device is Broadcom. It seems that either the hardware or 
> the driver doesn't support setting and getting sensitivity. I need to know if 
> there exists a device and/or device driver that support this feature. details 
> of my current hardware and device driver are posted in the askubuntu question:
> http://askubuntu.com/questions/553286/wlan-sensitivity-setting-is-not-supported
> kindly send me your recommendation for such device or device driver.
>
> best regards,
> Mohammad
> 
> Mohammad Abu Shattal
> Ph.D Student
> Department of Electrical & Computer Engineering
> Western Michigan University
> Kalamazoo, MI 49008

-- 
BR,
Sergey
--
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: [ath5k-devel] Support for ath9k chipset

[Sergey Ryazanov]

Cc linux-wireless

2014-11-26 1:20 GMT+03:00 Milos Ivanovic :
> Ok. I installed the wirelless card ath9k on Ubuntu.
>
> Only what i need is how can i change the frequency of wirelless card from
> terminal ? Which command ?
>
Action depends on mode of wireless interface. In case of AP you should
specify frequency in the hostapd configuration file, in case of
Managed sta your interface just running on the same channel as the AP
to which it is connected, in case of Mesh or IBSS your should specify
frequency in the same command which you use to start operation. And
finally, if your card run as Monitor you could type "iw mon0 set freq
2412".

More details about iw utility you can find in [1].

1. http://wireless.kernel.org/en/users/Documentation/iw

> Thanks
> Milos
>
>
> Sent from Samsung Mobile
>
>
>  Original message 
> From: Sergey Ryazanov
> Date:25/11/2014 23:10 (GMT+01:00)
> To: Milos Ivanovic
> Cc: ath5k-de...@lists.ath5k.org
> Subject: Re: [ath5k-devel] Support for ath9k chipset
>
> Hi Milos,
>
> 2014-11-25 14:19 GMT+03:00 Milos Ivanovic :
>> Dear all,
>>
>> Please, I need a help about installation Atheros AR9220 on Linux Debian
>> with kernel 3.2.
>>
> For questions about ath9k chips, please, use appropriate mailing list:
> ath9k-devel 
>
>>
>> Can you help me about this issue ? Because I have tried in several ways to
>> do this but without success.
>>
> Could you be more concrete: what do you try do and what exactly issue
> do you faced? That raises your chances to get an answer.
>
>>
>>
>> Thank you in advance,
>>
>>
>>
>> --
>> Milos Ivanovic, M.Sc.
>> Software Engineer
>> --
>> Phone: +381.63.469.824
>> E-mail:
>>
>> milos.ivano...@q-free.com
>>
>> --
>> Elcom d.o.o.
>> 41h Sinjska Street
>> 11050 Belgrade
>> Serbia
>>
>> VAT: 101821850
>>
>> www.elcombgd.rs
>> --
>
> --
> BR,
> Sergey

-- 
BR,
Sergey
--
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 V2 1/2] brcmutil: add helper function to format board revision

[Arend van Spriel]

On 11/25/14 21:39, Rafał Miłecki wrote:

On 25 November 2014 at 20:55, Arend van Spriel  wrote:

+/* Produce a human-readable string for boardrev */
+char *brcmu_boardrev_str(u32 brev, char *buf)
+{
+   char c;
+
+   if (brev<  0x100) {
+   snprintf(buf, 8, "%d.%d", (brev&  0xf0)>>  4, brev&  0xf);
+   } else {
+   c = (brev&  0xf000) == 0x1000 ? 'P' : 'A';
+   snprintf(buf, 8, "%c%03x", c, brev&  0xfff);
+   }
+   return buf;
+}


Is this known what do 'P' and 'A' mean? Just curious.


Me too, but never found out ;-) The test boards I have over here all 
have 'P' prefix.


Regards,
Arend
--
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 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem

[John W. Linville]

On Tue, Nov 25, 2014 at 01:50:32PM -0600, Larry Finger wrote:
> On 11/25/2014 12:46 PM, John W. Linville wrote:
> >On Tue, Nov 25, 2014 at 10:32:06AM -0600, Larry Finger wrote:
> >>The changes associated with moving this driver from staging to the regular
> >>tree missed one section setting the allowable rates for the 5GHz band.
> >>
> >>This patch is needed to fix the regression reported in Bug #88811
> >>(https://bugzilla.kernel.org/show_bug.cgi?id=88811).
> >>
> >>Reported-by: Valerio Passini 
> >>Tested-by: Valerio Passini 
> >>Signed-off-by: Larry Finger 
> >>Cc: Valerio Passini 
> >>---
> >>  drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c 
> >>b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> >>index 310d316..18f34f7 100644
> >>--- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> >>+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> >>@@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct 
> >>ieee80211_hw *hw,
> >>mac->opmode == NL80211_IFTYPE_ADHOC)
> >>macid = sta->aid + 1;
> >>if (wirelessmode == WIRELESS_MODE_N_5G ||
> >>-   wirelessmode == WIRELESS_MODE_AC_5G)
> >>-   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
> >>+   wirelessmode == WIRELESS_MODE_AC_5G ||
> >>+   wirelessmode == WIRELESS_MODE_A)
> >>+   ratr_bitmap = (sta->supp_rates[NL80211_BAND_5GHZ])<<4;
> >
> >The parenthesis seem superfluous.  How about this line instead?
> >
> >+ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ] << 4;
> >
> >>else
> >>ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];
> 
> Good idea. V2 is on its way.

No need -- I merged it with my version of the line. :-)

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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 V2 1/2] brcmutil: add helper function to format board revision

[Rafał Miłecki]

On 25 November 2014 at 20:55, Arend van Spriel  wrote:
> +/* Produce a human-readable string for boardrev */
> +char *brcmu_boardrev_str(u32 brev, char *buf)
> +{
> +   char c;
> +
> +   if (brev < 0x100) {
> +   snprintf(buf, 8, "%d.%d", (brev & 0xf0) >> 4, brev & 0xf);
> +   } else {
> +   c = (brev & 0xf000) == 0x1000 ? 'P' : 'A';
> +   snprintf(buf, 8, "%c%03x", c, brev & 0xfff);
> +   }
> +   return buf;
> +}

Is this known what do 'P' and 'A' mean? Just curious.
--
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 V3 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem

[Larry Finger]

The changes associated with moving this driver from staging to the regular
tree missed one section setting the allowable rates for the 5GHz band.

This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).

Reported-by: Valerio Passini 
Tested-by: Valerio Passini 
Signed-off-by: Larry Finger 
Cc: Valerio Passini 
---

V2 - removed extra parentheses as suggested by John Linville.
V3 - Add spaces around the << operator
---
 drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
index 310d316..18f34f7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
@@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct 
ieee80211_hw *hw,
mac->opmode == NL80211_IFTYPE_ADHOC)
macid = sta->aid + 1;
if (wirelessmode == WIRELESS_MODE_N_5G ||
-   wirelessmode == WIRELESS_MODE_AC_5G)
-   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
+   wirelessmode == WIRELESS_MODE_AC_5G ||
+   wirelessmode == WIRELESS_MODE_A)
+   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ] << 4;
else
ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];
 
-- 
2.1.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

Re: [PATCH v3 3/3] cfg80211: Allow usermode to query wiphy specific regd info

[Luis R. Rodriguez]

On Sun, Nov 23, 2014 at 05:02:21PM +0200, Arik Nemtsov wrote:
> From: Jonathan Doron 
> 
> Allow usermode to query wiphy-specific regd info, for drivers that use
> wiphy-specific regulatory management.
> 
> Use the existing API for sending regdomain info to usermode, but return
> the wiphy-specific regd in case wiphy index is provided and the driver
> employs wiphy-specific management. This implies user and kernel-mode
> support for the feature and is backward compatible.
> 
> Signed-off-by: Jonathan Doron 
> Signed-off-by: Arik Nemtsov 
> ---
>  include/uapi/linux/nl80211.h | 18 ++-
>  net/wireless/nl80211.c   | 71 
> 
>  net/wireless/reg.c   |  2 +-
>  net/wireless/reg.h   |  1 +
>  4 files changed, 78 insertions(+), 14 deletions(-)
> 
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 3771e7d..b222e5c 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -252,7 +252,12 @@
>   *   %NL80211_ATTR_IFINDEX.
>   *
>   * @NL80211_CMD_GET_REG: ask the wireless core to send us its currently set
> - *   regulatory domain.
> + *   regulatory domain. If %NL80211_ATTR_WIPHY is specified and the device
> + *   self-manages its regulatory settings, its private regulatory domain
> + *   will be returned.
> + *   If %NL80211_ATTR_WIPHY_GET_PRIV_REG is specified in addition to
> + *   %NL80211_ATTR_WIPHY, a device's private regulatory domain will be
> + *   returned, even if it's regulatory is not self-managed.
>   * @NL80211_CMD_SET_REG: Set current regulatory domain. CRDA sends this 
> command
>   *   after being queried by the kernel. CRDA replies by sending a regulatory
>   *   domain structure which consists of %NL80211_ATTR_REG_ALPHA set to our
> @@ -1693,6 +1698,14 @@ enum nl80211_commands {
>   *
>   * @NL80211_ATTR_MAC_MASK: MAC address mask
>   *
> + * @NL80211_ATTR_WIPHY_SELF_MANAGED_REG: flag attribute indicating the
> + *   regulatory information was obtained from the private regdomain
> + *   of a device with self-managed regulatory.
> + * @NL80211_ATTR_WIPHY_GET_PRIV_REG: flag attribute indicating the regulatory
> + *   information should be obtained from a device's private regdomain,
> + *   if it exists. This will happen even if the device is not self-managing
> + *   its regulatory.

As with REGULATORY_WIPHY_SELF_MANAGED we need a flag that cfg80211 sets for
drivers that use regulatory_hint() API, perhaps REGULATORY_WIPHY_REG_HINT.
Then this can be used by cfg80211 to send to userspace regdomains for wiphys
that have used this API. Below you enable userspace to only query for these
explictly but we want to be able to let userspace get all information, ie
through 'iw reg get'. This should go in as a separate patch along with
NL80211_ATTR_WIPHY_GET_PRIV_REG as its use predates
NL80211_ATTR_WIPHY_SELF_MANAGED_REG, this will also let you stuff in the boiler
plate code for getting that reg first, getting self managed regd's can then
go in as a clear secondary evolutionary step.

The documentation for NL80211_ATTR_WIPHY_GET_PRIV_REG can refer to the new
%REGULATORY_WIPHY_REG_HINT flag. NL80211_ATTR_WIPHY_SELF_MANAGED_REG should
refer to %REGULATORY_WIPHY_SELF_MANAGED

> @@ -5346,13 +5345,54 @@ static int nl80211_get_reg(struct sk_buff *skb, 
> struct genl_info *info)
>   if (!hdr)
>   goto put_failure;
>  
> - if (reg_last_request_cell_base() &&
> - nla_put_u32(msg, NL80211_ATTR_USER_REG_HINT_TYPE,
> - NL80211_USER_REG_HINT_CELL_BASE))
> - goto nla_put_failure;
> + if (info->attrs[NL80211_ATTR_WIPHY]) {
> + u32 reg_flags;
> + struct wiphy *wiphy;
> + struct cfg80211_registered_device *rdev =
> + cfg80211_get_dev_from_info(genl_info_net(info), info);
> +
> + if (IS_ERR(rdev)) {
> + nlmsg_free(msg);
> + return PTR_ERR(rdev);
> + }
> +
> + wiphy = &rdev->wiphy;
> + reg_flags = wiphy->regulatory_flags;
> + if (reg_flags & REGULATORY_WIPHY_SELF_MANAGED ||
> + info->attrs[NL80211_ATTR_WIPHY_GET_PRIV_REG]) {
> + regdom = get_wiphy_regdom(wiphy);
> + if (!regdom) {
> + nlmsg_free(msg);
> + return -EINVAL;
> + }
> +
> + if (nla_put_u32(msg, NL80211_ATTR_WIPHY,
> + rdev->wiphy_idx))
> + goto nla_put_failure;
> +
> + if (reg_flags & REGULATORY_WIPHY_SELF_MANAGED &&
> + nla_put_flag(msg,
> +  NL80211_ATTR_WIPHY_SELF_MANAGED_REG))
> + goto nla_put_failure;
> + }
> + }

If no NL80211_ATTR_WIPHY was requested specifically it would still
be g

Re: [PATCH 1/2 V2 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem

[Sergei Shtylyov]

Hello.

On 11/25/2014 11:02 PM, Larry Finger wrote:


The changes associated with moving this driver from staging to the regular
tree missed one section setting the allowable rates for the 5GHz band.



This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).



Reported-by: Valerio Passini 
Tested-by: Valerio Passini 
Signed-off-by: Larry Finger 
Cc: Valerio Passini 
---



V2 - removed extra parentheses as suggested by John Linville.


   He's also suggested spaces around << in his example


---
  drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
index 310d316..18f34f7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
@@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct 
ieee80211_hw *hw,
mac->opmode == NL80211_IFTYPE_ADHOC)
macid = sta->aid + 1;
if (wirelessmode == WIRELESS_MODE_N_5G ||
-   wirelessmode == WIRELESS_MODE_AC_5G)
-   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
+   wirelessmode == WIRELESS_MODE_AC_5G ||
+   wirelessmode == WIRELESS_MODE_A)
+   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ]<<4;


   The kernel style generally assumes spaces around operators, and it would 
only be consistent with the other code in the vicinity if you added them...


WBR, Sergei

--
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 V2 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem

[Larry Finger]

The changes associated with moving this driver from staging to the regular
tree missed one section setting the allowable rates for the 5GHz band.

This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).

Reported-by: Valerio Passini 
Tested-by: Valerio Passini 
Signed-off-by: Larry Finger 
Cc: Valerio Passini 
---

V2 - removed extra parentheses as suggested by John Linville.

---
 drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
index 310d316..18f34f7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
@@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct 
ieee80211_hw *hw,
mac->opmode == NL80211_IFTYPE_ADHOC)
macid = sta->aid + 1;
if (wirelessmode == WIRELESS_MODE_N_5G ||
-   wirelessmode == WIRELESS_MODE_AC_5G)
-   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
+   wirelessmode == WIRELESS_MODE_AC_5G ||
+   wirelessmode == WIRELESS_MODE_A)
+   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ]<<4;
else
ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];
 
-- 
2.1.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 2/2] ath10k: add new wmi interface of NF cal period

[Peter Oh]

Introduce a new wmi interface controls noise floor (NF) calibration
period via debugfs as firmware has introduced it on v10.2.

It allows users to modify frequency of NF calibration in millisecond
and changes RSSI reporting frequency consequently.
Short calibration period will trigger more frequent NF calibration,
so that RSSI reported in receive frames is more realistic.

Till now calibration was done at 30 seconds.

Signed-off-by: Peter Oh 
---
 drivers/net/wireless/ath/ath10k/core.h  |  1 +
 drivers/net/wireless/ath/ath10k/debug.c | 64 +
 drivers/net/wireless/ath/ath10k/wmi.c   |  2 ++
 drivers/net/wireless/ath/ath10k/wmi.h   |  1 +
 4 files changed, 68 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd3..5de988c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -320,6 +320,7 @@ struct ath10k_debug {
/* protected by conf_mutex */
u32 fw_dbglog_mask;
u32 pktlog_filter;
+   u32 fw_cal_period;
 
u8 htt_max_amsdu;
u8 htt_max_ampdu;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index f10721d..d8426fd 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1381,6 +1381,67 @@ static const struct file_operations fops_cal_data = {
.llseek = default_llseek,
 };
 
+static ssize_t ath10k_read_cal_period(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   unsigned int len;
+   char buf[32];
+
+   len = scnprintf(buf, sizeof(buf), "%d\n",
+   ar->debug.fw_cal_period);
+
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_write_cal_period(struct file *file,
+  const char __user *user_buf,
+  size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   unsigned long period;
+   int ret;
+
+   ret = kstrtoul_from_user(user_buf, count, 0, &period);
+   if (ret)
+   return ret;
+   /* period unit in millisecond */
+   if (period < 1 || period > 6)
+   return -EINVAL;
+
+   mutex_lock(&ar->conf_mutex);
+
+   ar->debug.fw_cal_period = period;
+
+   if (ar->state == ATH10K_STATE_ON) {
+   ret = ath10k_wmi_pdev_set_param
+   (ar, ar->wmi.pdev_param->cal_period,
+   ar->debug.fw_cal_period);
+   if (ret) {
+   ath10k_warn
+   (ar, "cal period cfg failed from debugfs: %d\n",
+   ret);
+   goto exit;
+   }
+   }
+
+   ret = count;
+
+exit:
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static const struct file_operations fops_cal_period = {
+   .read = ath10k_read_cal_period,
+   .write = ath10k_write_cal_period,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 int ath10k_debug_start(struct ath10k *ar)
 {
int ret;
@@ -1645,6 +1706,9 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("cal_data", S_IRUSR, ar->debug.debugfs_phy,
ar, &fops_cal_data);
 
+   debugfs_create_file("cal_period", S_IRUSR | S_IWUSR,
+   ar->debug.debugfs_phy, ar, &fops_cal_period);
+
if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED)) {
debugfs_create_file("dfs_simulate_radar", S_IWUSR,
ar->debug.debugfs_phy, ar,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index c300a53..b144b39 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -434,6 +434,7 @@ static struct wmi_pdev_param_map wmi_pdev_param_map = {
.fast_channel_reset = WMI_PDEV_PARAM_UNSUPPORTED,
.burst_dur = WMI_PDEV_PARAM_UNSUPPORTED,
.burst_enable = WMI_PDEV_PARAM_UNSUPPORTED,
+   .cal_period = WMI_PDEV_PARAM_UNSUPPORTED,
 };
 
 static struct wmi_pdev_param_map wmi_10x_pdev_param_map = {
@@ -486,6 +487,7 @@ static struct wmi_pdev_param_map wmi_10x_pdev_param_map = {
.fast_channel_reset = WMI_10X_PDEV_PARAM_FAST_CHANNEL_RESET,
.burst_dur = WMI_10X_PDEV_PARAM_BURST_DUR,
.burst_enable = WMI_10X_PDEV_PARAM_BURST_ENABLE,
+   .cal_period = WMI_10X_PDEV_PARAM_CAL_PERIOD,
 };
 
 /* firmware 10.2 specific mappings */
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 8fa0192..fe35ba9 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/dr

[PATCH 1/2] ath10k: add new pdev parameters for fw 10.2

[Peter Oh]

New pdev paramters have been added to firmware 10.2,
hence update wmi interfaces to sync with.

Signed-off-by: Peter Oh 
---
 drivers/net/wireless/ath/ath10k/wmi.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index a38d788..8fa0192 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2707,6 +2707,9 @@ enum wmi_10x_pdev_param {
WMI_10X_PDEV_PARAM_SET_MCAST2UCAST_MODE,
WMI_10X_PDEV_PARAM_SET_MCAST2UCAST_BUFFER,
WMI_10X_PDEV_PARAM_REMOVE_MCAST2UCAST_BUFFER,
+   WMI_10X_PDEV_PEER_STA_PS_STATECHG_ENABLE,
+   WMI_10X_PDEV_PARAM_RTS_FIXED_RATE,
+   WMI_10X_PDEV_PARAM_CAL_PERIOD
 };
 
 struct wmi_pdev_set_param_cmd {
-- 
1.9.1

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

[PATCH V2 2/2] brcmsmac: extend hardware info shown in debugfs

[Arend van Spriel]

The hardware info now also include radio and phy information, which
can be helpful in debugging issues.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/brcm80211/brcmsmac/debug.c | 40 +
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/debug.c 
b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
index 19740c1..c9a8b93 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/debug.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
@@ -30,6 +30,7 @@
 #include "main.h"
 #include "debug.h"
 #include "brcms_trace_events.h"
+#include "phy/phy_int.h"
 
 static struct dentry *root_folder;
 
@@ -74,20 +75,33 @@ static
 int brcms_debugfs_hardware_read(struct seq_file *s, void *data)
 {
struct brcms_pub *drvr = s->private;
+   struct brcms_hardware *hw = drvr->wlc->hw;
+   struct bcma_device *core = hw->d11core;
+   struct bcma_bus *bus = core->bus;
+   char boardrev[10];
 
-   seq_printf(s, "board vendor: %x\n"
-  "board type: %x\n"
-  "board revision: %x\n"
-  "board flags: %x\n"
-  "board flags2: %x\n"
-  "firmware revision: %x\n",
-  drvr->wlc->hw->d11core->bus->boardinfo.vendor,
-  drvr->wlc->hw->d11core->bus->boardinfo.type,
-  drvr->wlc->hw->boardrev,
-  drvr->wlc->hw->boardflags,
-  drvr->wlc->hw->boardflags2,
-  drvr->wlc->ucode_rev);
-
+   seq_printf(s, "chipnum 0x%x\n"
+  "chiprev 0x%x\n"
+  "chippackage 0x%x\n"
+  "corerev 0x%x\n"
+  "boardid 0x%x\n"
+  "boardvendor 0x%x\n"
+  "boardrev %s\n"
+  "boardflags 0x%x\n"
+  "boardflags2 0x%x\n"
+  "ucoderev 0x%x\n"
+  "radiorev 0x%x\n"
+  "phytype 0x%x\n"
+  "phyrev 0x%x\n"
+  "anarev 0x%x\n"
+  "nvramrev %d\n",
+  bus->chipinfo.id, bus->chipinfo.rev, bus->chipinfo.pkg,
+  core->id.rev, bus->boardinfo.type, bus->boardinfo.vendor,
+  brcmu_boardrev_str(hw->boardrev, boardrev),
+  drvr->wlc->hw->boardflags, drvr->wlc->hw->boardflags2,
+  drvr->wlc->ucode_rev, hw->band->radiorev,
+  hw->band->phytype, hw->band->phyrev, hw->band->pi->ana_rev,
+  hw->sromrev);
return 0;
 }
 
-- 
1.9.1

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

[PATCH V2 1/2] brcmutil: add helper function to format board revision

[Arend van Spriel]

The board revision that is available in hardware can be translated
so it matches the labelling on the board. This is accomplished by
this helper function.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/brcm80211/brcmutil/utils.c  | 16 
 drivers/net/wireless/brcm80211/include/brcmu_utils.h |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/wireless/brcm80211/brcmutil/utils.c 
b/drivers/net/wireless/brcm80211/brcmutil/utils.c
index 0f7e1c7..906e89d 100644
--- a/drivers/net/wireless/brcm80211/brcmutil/utils.c
+++ b/drivers/net/wireless/brcm80211/brcmutil/utils.c
@@ -261,6 +261,21 @@ struct sk_buff *brcmu_pktq_mdeq(struct pktq *pq, uint 
prec_bmp,
 }
 EXPORT_SYMBOL(brcmu_pktq_mdeq);
 
+/* Produce a human-readable string for boardrev */
+char *brcmu_boardrev_str(u32 brev, char *buf)
+{
+   char c;
+
+   if (brev < 0x100) {
+   snprintf(buf, 8, "%d.%d", (brev & 0xf0) >> 4, brev & 0xf);
+   } else {
+   c = (brev & 0xf000) == 0x1000 ? 'P' : 'A';
+   snprintf(buf, 8, "%c%03x", c, brev & 0xfff);
+   }
+   return buf;
+}
+EXPORT_SYMBOL(brcmu_boardrev_str);
+
 #if defined(DEBUG)
 /* pretty hex print a pkt buffer chain */
 void brcmu_prpkt(const char *msg, struct sk_buff *p0)
@@ -292,4 +307,5 @@ void brcmu_dbg_hex_dump(const void *data, size_t size, 
const char *fmt, ...)
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, data, size);
 }
 EXPORT_SYMBOL(brcmu_dbg_hex_dump);
+
 #endif /* defined(DEBUG) */
diff --git a/drivers/net/wireless/brcm80211/include/brcmu_utils.h 
b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
index 8ba445b..a043e29 100644
--- a/drivers/net/wireless/brcm80211/include/brcmu_utils.h
+++ b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
@@ -218,4 +218,6 @@ void brcmu_dbg_hex_dump(const void *data, size_t size, 
const char *fmt, ...)
 }
 #endif
 
+char *brcmu_boardrev_str(u32 brev, char *buf);
+
 #endif /* _BRCMU_UTILS_H_ */
-- 
1.9.1

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

[PATCH V2 0/2] brcm80211: minor rework

[Arend van Spriel]

Fixing my mistake in utils.c these two patches will
extend the information in the hardware debugfs file.

It is intended for 3.19 and applies to the master
branch of the wireless-next repository, ie.:

  commit 18ca43823f3ce111c6efb8cc90d9f35246527727
  Author: Amitkumar Karwar 
  Date:   Tue Nov 25 06:43:06 2014 -0800

  mwifiex: add Tx status support for ACTION frames

Arend van Spriel (2):
  brcmutil: add helper function to format board revision
  brcmsmac: extend hardware info shown in debugfs

 drivers/net/wireless/brcm80211/brcmsmac/debug.c| 40 +++---
 drivers/net/wireless/brcm80211/brcmutil/utils.c| 16 +
 .../net/wireless/brcm80211/include/brcmu_utils.h   |  2 ++
 3 files changed, 45 insertions(+), 13 deletions(-)

-- 
1.9.1

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

Re: [PATCH 1/2 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem

[Larry Finger]

On 11/25/2014 12:46 PM, John W. Linville wrote:

On Tue, Nov 25, 2014 at 10:32:06AM -0600, Larry Finger wrote:

The changes associated with moving this driver from staging to the regular
tree missed one section setting the allowable rates for the 5GHz band.

This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).

Reported-by: Valerio Passini 
Tested-by: Valerio Passini 
Signed-off-by: Larry Finger 
Cc: Valerio Passini 
---
  drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
index 310d316..18f34f7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
@@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct 
ieee80211_hw *hw,
mac->opmode == NL80211_IFTYPE_ADHOC)
macid = sta->aid + 1;
if (wirelessmode == WIRELESS_MODE_N_5G ||
-   wirelessmode == WIRELESS_MODE_AC_5G)
-   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
+   wirelessmode == WIRELESS_MODE_AC_5G ||
+   wirelessmode == WIRELESS_MODE_A)
+   ratr_bitmap = (sta->supp_rates[NL80211_BAND_5GHZ])<<4;


The parenthesis seem superfluous.  How about this line instead?

+   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ] << 4;


else
ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];


Good idea. V2 is on its way.

Larry


--
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 3/4] brcmsmac: extend hardware info shown in debugfs

[Arend van Spriel]

On 11/25/14 20:20, John W. Linville wrote:

On Tue, Nov 25, 2014 at 08:16:17PM +0100, Arend van Spriel wrote:

On 11/25/14 20:05, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:49:45PM -0500, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:12:34PM +0100, Arend van Spriel wrote:

On 11/24/14 22:50, John W. Linville wrote:

Hmmm...I'm not sure why, but this is causing problems for me...

ERROR: "brcmu_boardrev_str" 
[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!


I am confused as well. I did not have such an issue. The function is
provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and added it
to the include file. Missing something? Also I don't see this issue over
here. I will do a clean build on the wireless-next tree and see if I can
reproduce this.


I did a clean build after applying the patches in question, and I
still got the same issue at link time.  I'll attach my .config for
you to try.


I think that was too big...trying the compressed version...


I received both. I assume he commit mentioned below is without the patches.

Regards,
Arend


FWIW, I am building wireless-testing at commit
733ea24c8c98d99c747b89710e520ac6e9f3951b.


John


That commit includes all 4 patches.  I reverted the last three later
in the wireless-testing history.


In wireless-next I see you included patches 1 and 4 already so I will 
resend only patches 2 and 3.


Arend

John


--
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 v3 2/3] cfg80211: allow wiphy specific regdomain management

[Luis R. Rodriguez]

On Sun, Nov 23, 2014 at 05:02:20PM +0200, Arik Nemtsov wrote:
> From: Jonathan Doron 
> 
> Add a new regulatory flag that allows a driver to manage regdomain
> changes/updates for its own wiphy.
> A self-managed wiphys only employs regulatory information obtained from
> the FW and driver and does not use other cfg80211 sources like
> beacon-hints, country-code IEs and hints from other devices on the same
> system. Conversely, a self-managed wiphy does not share its regulatory
> hints with other devices in the system. If a system contains several
> devices, one or more of which are self-managed, there might be
> contradictory regulatory settings between them. Usage of flag is
> generally discouraged. Only use it if the FW/driver is incompatible
> with non-locally originated hints.
> 
> A new API lets the driver send a complete regdomain, to be applied on
> its wiphy only.
> 
> After a wiphy-specific regdomain change takes place, usermode will get
> a new type of change notification. The regulatory core also takes care
> enforce regulatory restrictions, in case some interfaces are on
> forbidden channels.
> 
> Signed-off-by: Jonathan Doron 
> Signed-off-by: Arik Nemtsov 

Reviewed-by: Luis R. Rodriguez 

  Luis
--
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 v3 1/3] cfg80211: leave invalid channels on regdomain change

[Luis R. Rodriguez]

On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote:
> When the regulatory settings change, some channels might become invalid.
> Disconnect interfaces acting on these channels, after giving userspace
> code a grace period to leave them.
> 
> This mode is currently opt-in, and not all interface operating modes are
> supported for regulatory-enforcement checks. A wiphy that wishes to use
> the new enforcement code must specify an appropriate regulatory flag,
> and all its supported interface modes must be supported by the chekcing
> code.

This is all looking beter now, since I had a few requests for the last patch
I'll ask for some other things here without asking  to negage the flag purpose
as I originally wanted.

> Signed-off-by: Arik Nemtsov 
> ---
>  include/net/regulatory.h |   6 +++
>  net/wireless/core.c  |  13 ++
>  net/wireless/reg.c   | 106 
> ++-
>  3 files changed, 124 insertions(+), 1 deletion(-)
> 
> diff --git a/include/net/regulatory.h b/include/net/regulatory.h
> index dad7ab2..701177c 100644
> --- a/include/net/regulatory.h
> +++ b/include/net/regulatory.h
> @@ -136,6 +136,11 @@ struct regulatory_request {
>   *  otherwise initiating radiation is not allowed. This will enable the
>   *  relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration
>   *  option
> + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all
> + *   interfaces on this wiphy reside on allowed channels. Upon a regdomain
> + *   change, the interfaces are given a grace period to disconnect or move
> + *   to an allowed channels. Interfaces on forbidden channels are forcibly
> + *   disconnected.

Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add
some information about the amount current of grace period used,
and types of interfaces supported. Since this is a regulatory flag
this information will help folks decide whether to enable or not.
Also encourage its use, and mention that once all supported devices
get support for this will be enabled by default. In the meantime
I'd prefer if this feature was enabled by default if the supported
interface types of a dveice match the white list of supported
interfaces.

  Luis
--
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 3/4] brcmsmac: extend hardware info shown in debugfs

[John W. Linville]

On Tue, Nov 25, 2014 at 08:16:17PM +0100, Arend van Spriel wrote:
> On 11/25/14 20:05, John W. Linville wrote:
> >On Tue, Nov 25, 2014 at 01:49:45PM -0500, John W. Linville wrote:
> >>On Tue, Nov 25, 2014 at 01:12:34PM +0100, Arend van Spriel wrote:
> >>>On 11/24/14 22:50, John W. Linville wrote:
> Hmmm...I'm not sure why, but this is causing problems for me...
> 
> ERROR: "brcmu_boardrev_str" 
> [drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!
> >>>
> >>>I am confused as well. I did not have such an issue. The function is
> >>>provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and added it
> >>>to the include file. Missing something? Also I don't see this issue over
> >>>here. I will do a clean build on the wireless-next tree and see if I can
> >>>reproduce this.
> >>
> >>I did a clean build after applying the patches in question, and I
> >>still got the same issue at link time.  I'll attach my .config for
> >>you to try.
> >
> >I think that was too big...trying the compressed version...
> 
> I received both. I assume he commit mentioned below is without the patches.
> 
> Regards,
> Arend
> 
> >>FWIW, I am building wireless-testing at commit
> >>733ea24c8c98d99c747b89710e520ac6e9f3951b.
> >
> >John

That commit includes all 4 patches.  I reverted the last three later
in the wireless-testing history.

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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 3/4] brcmsmac: extend hardware info shown in debugfs

[Arend van Spriel]

On 11/25/14 20:23, Arend van Spriel wrote:

On 11/25/14 20:16, Arend van Spriel wrote:

On 11/25/14 20:05, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:49:45PM -0500, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:12:34PM +0100, Arend van Spriel wrote:

On 11/24/14 22:50, John W. Linville wrote:

Hmmm...I'm not sure why, but this is causing problems for me...

ERROR: "brcmu_boardrev_str"
[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!


I am confused as well. I did not have such an issue. The function is
provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and
added it
to the include file. Missing something? Also I don't see this issue
over
here. I will do a clean build on the wireless-next tree and see if I
can
reproduce this.


I did a clean build after applying the patches in question, and I
still got the same issue at link time. I'll attach my .config for
you to try.


I think that was too big...trying the compressed version...


I received both. I assume he commit mentioned below is without the
patches.


Nevermind. Just saw that commit is before the reverts.


Crap. I unintentionally put the function in #ifdef section. Will fix 
that and send a v2 patch.


Regards,
Arend


Thanks,
Arend


Regards,
Arend


FWIW, I am building wireless-testing at commit
733ea24c8c98d99c747b89710e520ac6e9f3951b.


John


--
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


--
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


--
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 3/4] brcmsmac: extend hardware info shown in debugfs

[Arend van Spriel]

On 11/25/14 20:16, Arend van Spriel wrote:

On 11/25/14 20:05, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:49:45PM -0500, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:12:34PM +0100, Arend van Spriel wrote:

On 11/24/14 22:50, John W. Linville wrote:

Hmmm...I'm not sure why, but this is causing problems for me...

ERROR: "brcmu_boardrev_str"
[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!


I am confused as well. I did not have such an issue. The function is
provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and
added it
to the include file. Missing something? Also I don't see this issue
over
here. I will do a clean build on the wireless-next tree and see if I
can
reproduce this.


I did a clean build after applying the patches in question, and I
still got the same issue at link time. I'll attach my .config for
you to try.


I think that was too big...trying the compressed version...


I received both. I assume he commit mentioned below is without the patches.


Nevermind. Just saw that commit is before the reverts.

Thanks,
Arend


Regards,
Arend


FWIW, I am building wireless-testing at commit
733ea24c8c98d99c747b89710e520ac6e9f3951b.


John


--
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


--
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 3/4] brcmsmac: extend hardware info shown in debugfs

[Arend van Spriel]

On 11/25/14 20:05, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:49:45PM -0500, John W. Linville wrote:

On Tue, Nov 25, 2014 at 01:12:34PM +0100, Arend van Spriel wrote:

On 11/24/14 22:50, John W. Linville wrote:

Hmmm...I'm not sure why, but this is causing problems for me...

ERROR: "brcmu_boardrev_str" 
[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!


I am confused as well. I did not have such an issue. The function is
provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and added it
to the include file. Missing something? Also I don't see this issue over
here. I will do a clean build on the wireless-next tree and see if I can
reproduce this.


I did a clean build after applying the patches in question, and I
still got the same issue at link time.  I'll attach my .config for
you to try.


I think that was too big...trying the compressed version...


I received both. I assume he commit mentioned below is without the patches.

Regards,
Arend


FWIW, I am building wireless-testing at commit
733ea24c8c98d99c747b89710e520ac6e9f3951b.


John


--
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 3/4] brcmsmac: extend hardware info shown in debugfs

[John W. Linville]

On Tue, Nov 25, 2014 at 01:49:45PM -0500, John W. Linville wrote:
> On Tue, Nov 25, 2014 at 01:12:34PM +0100, Arend van Spriel wrote:
> > On 11/24/14 22:50, John W. Linville wrote:
> > >Hmmm...I'm not sure why, but this is causing problems for me...
> > >
> > >ERROR: "brcmu_boardrev_str" 
> > >[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!
> > 
> > I am confused as well. I did not have such an issue. The function is
> > provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and added it
> > to the include file. Missing something? Also I don't see this issue over
> > here. I will do a clean build on the wireless-next tree and see if I can
> > reproduce this.
> 
> I did a clean build after applying the patches in question, and I
> still got the same issue at link time.  I'll attach my .config for
> you to try.

I think that was too big...trying the compressed version...

> FWIW, I am building wireless-testing at commit
> 733ea24c8c98d99c747b89710e520ac6e9f3951b.

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.


wireless-testing.config.bz2
Description: BZip2 compressed data

Re: [PATCH 3/4] brcmsmac: extend hardware info shown in debugfs

[John W. Linville]

On Tue, Nov 25, 2014 at 02:00:38PM +0100, Arend van Spriel wrote:
> On 11/25/14 13:12, Arend van Spriel wrote:
> >On 11/24/14 22:50, John W. Linville wrote:
> >>Hmmm...I'm not sure why, but this is causing problems for me...
> >>
> >>ERROR: "brcmu_boardrev_str"
> >>[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!
> >
> >I am confused as well. I did not have such an issue. The function is
> >provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and added
> >it to the include file. Missing something? Also I don't see this issue
> >over here. I will do a clean build on the wireless-next tree and see if
> >I can reproduce this.
> 
> So I did a fresh checkout of wireless-next/master and applied patch 2 and 3.
> Here is my build output:
> 
> $ make M=drivers/net/wireless/brcm80211 modules
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/ampdu.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/antsel.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/channel.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/main.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/pmu.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/rate.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/stf.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/aiutils.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/dma.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmsmac/debug.o
>   LD [M]  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmutil/utils.o
>   CC [M]  drivers/net/wireless/brcm80211/brcmutil/d11.o
>   LD [M]  drivers/net/wireless/brcm80211/brcmutil/brcmutil.o
>   Building modules, stage 2.
>   MODPOST 2 modules
>   CC  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.mod.o
>   LD [M]  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
>   CC  drivers/net/wireless/brcm80211/brcmutil/brcmutil.mod.o
>   LD [M]  drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko
> 
> Anything else I should try over here?

/home/linville/git/wireless-testing
[linville-x1.hq.tuxdriver.com]:> make M=drivers/net/wireless/brcm80211 modules
  Building modules, stage 2.
  MODPOST 3 modules
WARNING: "brcmu_boardrev_str" 
[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!
  CC  drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.mod.o
  LD [M]  drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko
  CC  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.mod.o
  LD [M]  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
  CC  drivers/net/wireless/brcm80211/brcmutil/brcmutil.mod.o
  LD [M]  drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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 2/4] brcmutil: add helper function to format board revision

[John W. Linville]

On Tue, Nov 25, 2014 at 11:01:47AM +0100, Arend van Spriel wrote:
> On 11/24/14 22:53, John W. Linville wrote:
> >I am holding patches 2-4 until we resolve the brcmu_boardrev_str
> >build thing...
> 
> Actually, only patch 2 and 3 are related to the build thing. If that is what
> this is.
 
OK, I won't hold-up #4...

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem

[John W. Linville]

On Tue, Nov 25, 2014 at 10:32:06AM -0600, Larry Finger wrote:
> The changes associated with moving this driver from staging to the regular
> tree missed one section setting the allowable rates for the 5GHz band.
> 
> This patch is needed to fix the regression reported in Bug #88811
> (https://bugzilla.kernel.org/show_bug.cgi?id=88811).
> 
> Reported-by: Valerio Passini 
> Tested-by: Valerio Passini 
> Signed-off-by: Larry Finger 
> Cc: Valerio Passini 
> ---
>  drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c 
> b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> index 310d316..18f34f7 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> @@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct 
> ieee80211_hw *hw,
>   mac->opmode == NL80211_IFTYPE_ADHOC)
>   macid = sta->aid + 1;
>   if (wirelessmode == WIRELESS_MODE_N_5G ||
> - wirelessmode == WIRELESS_MODE_AC_5G)
> - ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
> + wirelessmode == WIRELESS_MODE_AC_5G ||
> + wirelessmode == WIRELESS_MODE_A)
> + ratr_bitmap = (sta->supp_rates[NL80211_BAND_5GHZ])<<4;

The parenthesis seem superfluous.  How about this line instead?

+   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ] << 4;

>   else
>   ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];
>  
> -- 
> 2.1.2
> 
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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

Setting WLAN RF Sensitivity value

[Mohammad Ali Ma Abu Shattal]

Dear Sir/Madam,

I'm working on a project in which we need to set and get RF sensitivity of WLAN 
device. I tried to set other settings such as operation mode, txpower and 
frequency using Linux commands : "ioctl" and "iwconfig" and it works fine. 
Manufacturer of my device is Broadcom. It seems that either the hardware or the 
driver doesn't support setting and getting sensitivity. I need to know if there 
exists a device and/or device driver that support this feature. details of my 
current hardware and device driver are posted in the askubuntu question:
http://askubuntu.com/questions/553286/wlan-sensitivity-setting-is-not-supported
kindly send me your recommendation for such device or device driver.

best regards,
Mohammad
 
Mohammad Abu Shattal
Ph.D Student
Department of Electrical & Computer Engineering
Western Michigan University
Kalamazoo, MI 49008
--
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 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem

[Larry Finger]

The changes associated with moving this driver from staging to the regular
tree missed one section setting the allowable rates for the 5GHz band.

This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).

Reported-by: Valerio Passini 
Tested-by: Valerio Passini 
Signed-off-by: Larry Finger 
Cc: Valerio Passini 
---
 drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
index 310d316..18f34f7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
@@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct 
ieee80211_hw *hw,
mac->opmode == NL80211_IFTYPE_ADHOC)
macid = sta->aid + 1;
if (wirelessmode == WIRELESS_MODE_N_5G ||
-   wirelessmode == WIRELESS_MODE_AC_5G)
-   ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
+   wirelessmode == WIRELESS_MODE_AC_5G ||
+   wirelessmode == WIRELESS_MODE_A)
+   ratr_bitmap = (sta->supp_rates[NL80211_BAND_5GHZ])<<4;
else
ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];
 
-- 
2.1.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 2/2 3.18] rtlwifi: Change order in device startup

[Larry Finger]

The existing order of steps when starting the PCI devices works for
2.4G devices, but fails to initialize the 5G section of the RTL8821AE
hardware.

This patch is needed to fix the regression reported in Bug #88811
(https://bugzilla.kernel.org/show_bug.cgi?id=88811).

Reported-by: Valerio Passini 
Tested-by: Valerio Passini 
Signed-off-by: Larry Finger 
Cc: Valerio Passini 
---
 drivers/net/wireless/rtlwifi/pci.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/pci.c 
b/drivers/net/wireless/rtlwifi/pci.c
index 61f5d36..846a2e6 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -2249,6 +2249,16 @@ int rtl_pci_probe(struct pci_dev *pdev,
/*like read eeprom and so on */
rtlpriv->cfg->ops->read_eeprom_info(hw);
 
+   if (rtlpriv->cfg->ops->init_sw_vars(hw)) {
+   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Can't init_sw_vars\n");
+   err = -ENODEV;
+   goto fail3;
+   }
+   rtlpriv->cfg->ops->init_sw_leds(hw);
+
+   /*aspm */
+   rtl_pci_init_aspm(hw);
+
/* Init mac80211 sw */
err = rtl_init_core(hw);
if (err) {
@@ -2264,16 +2274,6 @@ int rtl_pci_probe(struct pci_dev *pdev,
goto fail3;
}
 
-   if (rtlpriv->cfg->ops->init_sw_vars(hw)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Can't init_sw_vars\n");
-   err = -ENODEV;
-   goto fail3;
-   }
-   rtlpriv->cfg->ops->init_sw_leds(hw);
-
-   /*aspm */
-   rtl_pci_init_aspm(hw);
-
err = ieee80211_register_hw(hw);
if (err) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-- 
2.1.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 0/2 3.18] Fixes for Bug #88811

[Larry Finger]

These two patches are needed to fix a regression introduced when
driver rtl8821ae was moved from staging to the regular wireless tree.

I am sorry that these fixes are so late in the 3.18 cycle.

Larry


Larry Finger (2):
  rtlwifi: rtl8821ae: Fix 5G detection problem
  rtlwifi: Change order in device startup

 drivers/net/wireless/rtlwifi/pci.c  | 20 ++--
 drivers/net/wireless/rtlwifi/rtl8821ae/hw.c |  5 +++--
 2 files changed, 13 insertions(+), 12 deletions(-)

-- 
2.1.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

Re: [PATCH 1/2] ath10k: move create-ht-cap methods above set-antenna.

[Ben Greear]

On 11/25/2014 12:08 AM, Kalle Valo wrote:
> gree...@candelatech.com writes:
> 
>> From: Ben Greear 
>>
>> We will need to use these in set-antenna, so move them
>> so that we do not have to define the method signatures.
>>
>> Signed-off-by: Ben Greear 
> 
> I'm dropping these two patches. Please resend once we figure out how to
> handle the band updated.

It might be a while...I'm working on some other tasks these days
and don't have time to respin ath10k patches at the moment.

If someone else wants to work on getting them upstream, please be
my guest.

Per Felix's comment, maybe my patches were actually OK as they are

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: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[Johannes Berg]

> Agree with you that it need a bigger discussion about whether
> advertise VHT is the suitable/best
> way to support the  VHT at 2.4G feature.
> 
> We are considered this ways as it is already be used by some vendor
> like BRCM or Qualcomm Atheros
> in there full mac product, and there will be IOT issue if there are
> kinds of different implementation.

There's no forum that defines it and tests IOP though...

johannes

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

Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[Arend van Spriel]

On 11/25/14 15:18, Johannes Berg wrote:

On Tue, 2014-11-25 at 22:13 +0800, YanBo wrote:


But is all of that really the right way? I'm not completely convinced.


Except set the flag, the HW itself should support this feature, or
else it also doesn't work, I'd
send the patch in soon for public review.


Yeah, but is it really the right way to advertise VHT? In the spec, VHT
means you also have 80 MHz support - do you really think you can/will do
80 MHz on 2.4 GHz? Seems like all of this will cause more corner cases.


For brcmfmac, the 80 MHz requirement in the spec was exactly the reason 
to *not* advertise VHT in 2.4G.




I guess we can make this check conditional for 5GHz when the VHT support
lands and is discussed.


That is sounds good if it only check for 5GHz for what I know CMIIW.


Even on 2.4 GHz it technically isn't enough though - there's enough
spectrum in 2.4 GHz for a single 80 MHz channel; how long until somebody
wants to do *that* for some reason? But the rest of us really doesn't
think that's applicable ...


To get "friendly" with your neighbors :-p

Regards,
Arend


Anyway, it probably needs mac80211 patches anyway since mlme.c already
disables VHT if you can't do 80 MHz, so I think you should post those as
part of a bigger discussion about how we want to support it and what it
really means etc.

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


--
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] rt2800: calculate tx power temperature compensation on selected chips

[Stanislaw Gruszka]

Currently implemented temperature compensation is only valid on some of
supported chips. Other chips do not need temperature compensation or
need different way to do this (not yet implemented in the rt2800
driver). Trying to do run rt2800_get_gain_calibration_delta() when this
is not appropriate on particular chip gives bogus result of TX power
and can make connection unstable.

This is follow up to commit 8c8d2017ba25c510ddf093419048460db1109bc4
"rt2800: fix RT5390 & RT3290 TX power settings regression". On that
commit we avoid setting BBP_R1 register, but the real problem is wrong
temperature compensation calculation.

Reported-and-tested-by: Ronald Wahl 
Debugged-by: Ronald Wahl 
Cc: Mike Romberg 
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/rt2x00/rt2800lib.c | 45 +++--
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c 
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 9f57a2d..81ee481 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -4119,7 +4119,20 @@ static void rt2800_config_txpower_rt28xx(struct 
rt2x00_dev *rt2x00dev,
 * expected. We adjust it, based on TSSI reference and boundaries values
 * provided in EEPROM.
 */
-   delta += rt2800_get_gain_calibration_delta(rt2x00dev);
+   switch (rt2x00dev->chip.rt) {
+   case RT2860:
+   case RT2872:
+   case RT2883:
+   case RT3070:
+   case RT3071:
+   case RT3090:
+   case RT3572:
+   delta += rt2800_get_gain_calibration_delta(rt2x00dev);
+   break;
+   default:
+   /* TODO: temperature compensation code for other chips. */
+   break;
+   }
 
/*
 * Decrease power according to user settings, on devices with unknown
@@ -4136,25 +4149,19 @@ static void rt2800_config_txpower_rt28xx(struct 
rt2x00_dev *rt2x00dev,
 * TODO: we do not use +6 dBm option to do not increase power beyond
 * regulatory limit, however this could be utilized for devices with
 * CAPABILITY_POWER_LIMIT.
-*
-* TODO: add different temperature compensation code for RT3290 & RT5390
-* to allow to use BBP_R1 for those chips.
-*/
-   if (!rt2x00_rt(rt2x00dev, RT3290) &&
-   !rt2x00_rt(rt2x00dev, RT5390)) {
-   rt2800_bbp_read(rt2x00dev, 1, &r1);
-   if (delta <= -12) {
-   power_ctrl = 2;
-   delta += 12;
-   } else if (delta <= -6) {
-   power_ctrl = 1;
-   delta += 6;
-   } else {
-   power_ctrl = 0;
-   }
-   rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, power_ctrl);
-   rt2800_bbp_write(rt2x00dev, 1, r1);
+*/
+   if (delta <= -12) {
+   power_ctrl = 2;
+   delta += 12;
+   } else if (delta <= -6) {
+   power_ctrl = 1;
+   delta += 6;
+   } else {
+   power_ctrl = 0;
}
+   rt2800_bbp_read(rt2x00dev, 1, &r1);
+   rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, power_ctrl);
+   rt2800_bbp_write(rt2x00dev, 1, r1);
 
offset = TX_PWR_CFG_0;
 
-- 
1.8.3.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] mac80211: check if channels allow 80 MHz for VHT probe requests

[YanBo]

On Tue, Nov 25, 2014 at 10:18 PM, Johannes Berg
 wrote:
> On Tue, 2014-11-25 at 22:13 +0800, YanBo wrote:
>
>> > But is all of that really the right way? I'm not completely convinced.
>>
>> Except set the flag, the HW itself should support this feature, or
>> else it also doesn't work, I'd
>> send the patch in soon for public review.
>
> Yeah, but is it really the right way to advertise VHT? In the spec, VHT
> means you also have 80 MHz support - do you really think you can/will do
> 80 MHz on 2.4 GHz? Seems like all of this will cause more corner cases.
>
>> >

Agree with you that it need a bigger discussion about whether
advertise VHT is the suitable/best
way to support the  VHT at 2.4G feature.

We are considered this ways as it is already be used by some vendor
like BRCM or Qualcomm Atheros
in there full mac product, and there will be IOT issue if there are
kinds of different implementation.

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

[PATCH 4/5] mwifiex: add Tx status support for EAPOL packets

[Amitkumar Karwar]

Firmware notifies the driver through event if EAPOL data packet
has been acked or not. We will inform this status to userspace
listening on a socket.

Signed-off-by: Cathy Luo 
Signed-off-by: Avinash Patil 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/cfg80211.c  |  3 ++
 drivers/net/wireless/mwifiex/decl.h  |  2 ++
 drivers/net/wireless/mwifiex/fw.h| 17 +--
 drivers/net/wireless/mwifiex/init.c  |  3 ++
 drivers/net/wireless/mwifiex/main.c  | 48 
 drivers/net/wireless/mwifiex/main.h  |  7 +
 drivers/net/wireless/mwifiex/sta_event.c |  5 
 drivers/net/wireless/mwifiex/sta_tx.c|  5 
 drivers/net/wireless/mwifiex/txrx.c  | 20 +
 drivers/net/wireless/mwifiex/uap_event.c |  4 +++
 drivers/net/wireless/mwifiex/uap_txrx.c  |  7 -
 drivers/net/wireless/mwifiex/wmm.c   | 10 +++
 12 files changed, 127 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/cfg80211.c 
b/drivers/net/wireless/mwifiex/cfg80211.c
index 17f0ee0..68d5874 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2988,6 +2988,9 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter 
*adapter)
   NL80211_FEATURE_INACTIVITY_TIMER |
   NL80211_FEATURE_NEED_OBSS_SCAN;
 
+   if (adapter->fw_api_ver == MWIFIEX_FW_V15)
+   wiphy->features |= NL80211_FEATURE_SK_TX_STATUS;
+
/* Reserve space for mwifiex specific private data for BSS */
wiphy->bss_priv_size = sizeof(struct mwifiex_bss_priv);
 
diff --git a/drivers/net/wireless/mwifiex/decl.h 
b/drivers/net/wireless/mwifiex/decl.h
index fc0b1ed..9daa88a 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -76,6 +76,7 @@
 #define MWIFIEX_BUF_FLAG_REQUEUED_PKT  BIT(0)
 #define MWIFIEX_BUF_FLAG_BRIDGED_PKT  BIT(1)
 #define MWIFIEX_BUF_FLAG_TDLS_PKT BIT(2)
+#define MWIFIEX_BUF_FLAG_EAPOL_TX_STATUS   BIT(3)
 
 #define MWIFIEX_BRIDGED_PKTS_THR_HIGH  1024
 #define MWIFIEX_BRIDGED_PKTS_THR_LOW128
@@ -159,6 +160,7 @@ struct mwifiex_txinfo {
u8 bss_num;
u8 bss_type;
u32 pkt_len;
+   u8 ack_frame_id;
 };
 
 enum mwifiex_wmm_ac_e {
diff --git a/drivers/net/wireless/mwifiex/fw.h 
b/drivers/net/wireless/mwifiex/fw.h
index e095f37..fb5936e 100644
--- a/drivers/net/wireless/mwifiex/fw.h
+++ b/drivers/net/wireless/mwifiex/fw.h
@@ -494,6 +494,7 @@ enum P2P_MODES {
 #define EVENT_TDLS_GENERIC_EVENT0x0052
 #define EVENT_EXT_SCAN_REPORT   0x0058
 #define EVENT_REMAIN_ON_CHAN_EXPIRED0x005f
+#define EVENT_TX_STATUS_REPORT 0x0074
 
 #define EVENT_ID_MASK   0x
 #define BSS_NUM_MASK0xf
@@ -542,6 +543,7 @@ struct mwifiex_ie_types_data {
 #define MWIFIEX_TxPD_POWER_MGMT_LAST_PACKET 0x08
 #define MWIFIEX_TXPD_FLAGS_TDLS_PACKET  0x10
 #define MWIFIEX_RXPD_FLAGS_TDLS_PACKET  0x01
+#define MWIFIEX_TXPD_FLAGS_REQ_TX_STATUS0x20
 
 struct txpd {
u8 bss_type;
@@ -553,7 +555,9 @@ struct txpd {
u8 priority;
u8 flags;
u8 pkt_delay_2ms;
-   u8 reserved1;
+   u8 reserved1[2];
+   u8 tx_token_id;
+   u8 reserved[2];
 } __packed;
 
 struct rxpd {
@@ -598,8 +602,9 @@ struct uap_txpd {
u8 priority;
u8 flags;
u8 pkt_delay_2ms;
-   u8 reserved1;
-   __le32 reserved2;
+   u8 reserved1[2];
+   u8 tx_token_id;
+   u8 reserved[2];
 };
 
 struct uap_rxpd {
@@ -1224,6 +1229,12 @@ struct mwifiex_event_scan_result {
u8 num_of_set;
 } __packed;
 
+struct tx_status_event {
+   u8 packet_type;
+   u8 tx_token_id;
+   u8 status;
+} __packed;
+
 #define MWIFIEX_USER_SCAN_CHAN_MAX 50
 
 #define MWIFIEX_MAX_SSID_LIST_LENGTH 10
diff --git a/drivers/net/wireless/mwifiex/init.c 
b/drivers/net/wireless/mwifiex/init.c
index cc15ab8..520ad4a 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -473,6 +473,9 @@ int mwifiex_init_lock_list(struct mwifiex_adapter *adapter)
 
spin_lock_init(&priv->tx_ba_stream_tbl_lock);
spin_lock_init(&priv->rx_reorder_tbl_lock);
+
+   spin_lock_init(&priv->ack_status_lock);
+   idr_init(&priv->ack_status_frames);
}
 
return 0;
diff --git a/drivers/net/wireless/mwifiex/main.c 
b/drivers/net/wireless/mwifiex/main.c
index cf07279..cf31d36 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -608,6 +608,44 @@ int mwifiex_queue_tx_pkt(struct mwifiex_private *priv, 
struct sk_buff *skb)
return 0;
 }
 
+static struct sk_buff *
+mwifiex_clone_skb_for_tx_status(struct mwifiex_private *priv,
+   struct sk_buff *skb, u8 flag)
+{
+   struct sk_buff *orig_skb = skb;
+  

[PATCH 5/5] mwifiex: add Tx status support for ACTION frames

[Amitkumar Karwar]

ACK status (0/1) for ACTION frames is informed to cfg80211. We
will extend existing logic used for EAPOL frames. The cfg80211
API is different here. Also, we need to explicitly free cloned
skb.

Signed-off-by: Cathy Luo 
Signed-off-by: Avinash Patil 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/cfg80211.c | 13 ++---
 drivers/net/wireless/mwifiex/decl.h |  2 ++
 drivers/net/wireless/mwifiex/main.c | 10 +++---
 drivers/net/wireless/mwifiex/main.h |  4 
 drivers/net/wireless/mwifiex/sta_tx.c   |  3 ++-
 drivers/net/wireless/mwifiex/txrx.c | 17 ++---
 drivers/net/wireless/mwifiex/uap_txrx.c |  3 ++-
 7 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/cfg80211.c 
b/drivers/net/wireless/mwifiex/cfg80211.c
index 68d5874..f881044 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -194,10 +194,17 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct 
wireless_dev *wdev,
tx_info->pkt_len = pkt_len;
 
mwifiex_form_mgmt_frame(skb, buf, len);
-   mwifiex_queue_tx_pkt(priv, skb);
-
*cookie = prandom_u32() | 1;
-   cfg80211_mgmt_tx_status(wdev, *cookie, buf, len, true, GFP_ATOMIC);
+
+   if (ieee80211_is_action(mgmt->frame_control))
+   skb = mwifiex_clone_skb_for_tx_status(priv,
+ skb,
+   MWIFIEX_BUF_FLAG_ACTION_TX_STATUS, cookie);
+   else
+   cfg80211_mgmt_tx_status(wdev, *cookie, buf, len, true,
+   GFP_ATOMIC);
+
+   mwifiex_queue_tx_pkt(priv, skb);
 
wiphy_dbg(wiphy, "info: management frame transmitted\n");
return 0;
diff --git a/drivers/net/wireless/mwifiex/decl.h 
b/drivers/net/wireless/mwifiex/decl.h
index 9daa88a..2269acf 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -77,6 +77,7 @@
 #define MWIFIEX_BUF_FLAG_BRIDGED_PKT  BIT(1)
 #define MWIFIEX_BUF_FLAG_TDLS_PKT BIT(2)
 #define MWIFIEX_BUF_FLAG_EAPOL_TX_STATUS   BIT(3)
+#define MWIFIEX_BUF_FLAG_ACTION_TX_STATUS  BIT(4)
 
 #define MWIFIEX_BRIDGED_PKTS_THR_HIGH  1024
 #define MWIFIEX_BRIDGED_PKTS_THR_LOW128
@@ -161,6 +162,7 @@ struct mwifiex_txinfo {
u8 bss_type;
u32 pkt_len;
u8 ack_frame_id;
+   u64 cookie;
 };
 
 enum mwifiex_wmm_ac_e {
diff --git a/drivers/net/wireless/mwifiex/main.c 
b/drivers/net/wireless/mwifiex/main.c
index cf31d36..d4d2223 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -608,9 +608,9 @@ int mwifiex_queue_tx_pkt(struct mwifiex_private *priv, 
struct sk_buff *skb)
return 0;
 }
 
-static struct sk_buff *
+struct sk_buff *
 mwifiex_clone_skb_for_tx_status(struct mwifiex_private *priv,
-   struct sk_buff *skb, u8 flag)
+   struct sk_buff *skb, u8 flag, u64 *cookie)
 {
struct sk_buff *orig_skb = skb;
struct mwifiex_txinfo *tx_info, *orig_tx_info;
@@ -632,6 +632,10 @@ mwifiex_clone_skb_for_tx_status(struct mwifiex_private 
*priv,
orig_tx_info = MWIFIEX_SKB_TXCB(orig_skb);
orig_tx_info->ack_frame_id = id;
orig_tx_info->flags |= flag;
+
+   if (flag == MWIFIEX_BUF_FLAG_ACTION_TX_STATUS && cookie)
+   orig_tx_info->cookie = *cookie;
+
} else if (skb_shared(skb)) {
kfree_skb(orig_skb);
} else {
@@ -703,7 +707,7 @@ mwifiex_hard_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
 priv->adapter->fw_api_ver == MWIFIEX_FW_V15))
skb = mwifiex_clone_skb_for_tx_status(priv,
  skb,
-   MWIFIEX_BUF_FLAG_EAPOL_TX_STATUS);
+   MWIFIEX_BUF_FLAG_EAPOL_TX_STATUS, NULL);
 
/* Record the current time the packet was queued; used to
 * determine the amount of time the packet was queued in
diff --git a/drivers/net/wireless/mwifiex/main.h 
b/drivers/net/wireless/mwifiex/main.h
index e19fc2f..bdba37b 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -1342,6 +1342,10 @@ void mwifiex_clean_auto_tdls(struct mwifiex_private 
*priv);
 void mwifiex_parse_tx_status_event(struct mwifiex_private *priv,
   void *event_body);
 
+struct sk_buff *
+mwifiex_clone_skb_for_tx_status(struct mwifiex_private *priv,
+   struct sk_buff *skb, u8 flag, u64 *cookie);
+
 #ifdef CONFIG_DEBUG_FS
 void mwifiex_debugfs_init(void);
 void mwifiex_debugfs_remove(void);
diff --git a/drivers/net/wireless/mwifiex/sta_tx.c 
b/drivers/net/wireless/mwifiex/sta_tx.c
index c69ecbc

[PATCH 2/5] mwifiex: fix scan problem on big endian platforms

[Amitkumar Karwar]

This patch adds missing endian conversion for beacon size while
processing scan response.

Reported-by: Daniel Mosquera 
Tested-by: Daniel Mosquera 
Signed-off-by: Avinash Patil 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mwifiex/scan.c 
b/drivers/net/wireless/mwifiex/scan.c
index 3a17821..984a7a4 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -1623,7 +1623,7 @@ mwifiex_parse_single_response_buf(struct mwifiex_private 
*priv, u8 **bss_info,
 
if (*bytes_left >= sizeof(beacon_size)) {
/* Extract & convert beacon size from command buffer */
-   memcpy(&beacon_size, *bss_info, sizeof(beacon_size));
+   beacon_size = le16_to_cpu(*(__le16 *)(*bss_info));
*bytes_left -= sizeof(beacon_size);
*bss_info += sizeof(beacon_size);
}
-- 
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/5] mwifiex: skip delay main work logic for USB interface.

[Amitkumar Karwar]

We had introduced delay main work logic to avoid processing
interrupts when Rx pending packet count reaches high threshold.
interrupt processing is restarted later when packet count
reduces lower threashold. This helped to reduce unnecessary
overhead and improve throughput for SD and PCIe chipsets.

As there are no interrupts for USB, we will skip this logic for
USB chipsets.

Signed-off-by: Cathy Luo 
Signed-off-by: Avinash Patil 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/main.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/main.c 
b/drivers/net/wireless/mwifiex/main.c
index 0e50120..cf07279 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -149,7 +149,8 @@ static int mwifiex_process_rx(struct mwifiex_adapter 
*adapter)
/* Check for Rx data */
while ((skb = skb_dequeue(&adapter->rx_data_q))) {
atomic_dec(&adapter->rx_pending);
-   if (adapter->delay_main_work &&
+   if ((adapter->delay_main_work ||
+adapter->iface_type == MWIFIEX_USB) &&
(atomic_read(&adapter->rx_pending) < LOW_RX_PENDING)) {
if (adapter->if_ops.submit_rem_rx_urbs)
adapter->if_ops.submit_rem_rx_urbs(adapter);
@@ -202,12 +203,15 @@ process_start:
(adapter->hw_status == MWIFIEX_HW_STATUS_NOT_READY))
break;
 
-   /* If we process interrupts first, it would increase RX pending
-* even further. Avoid this by checking if rx_pending has
-* crossed high threshold and schedule rx work queue
-* and then process interrupts
+   /* For non-USB interfaces, If we process interrupts first, it
+* would increase RX pending even further. Avoid this by
+* checking if rx_pending has crossed high threshold and
+* schedule rx work queue and then process interrupts.
+* For USB interface, there are no interrupts. We already have
+* HIGH_RX_PENDING check in usb.c
 */
-   if (atomic_read(&adapter->rx_pending) >= HIGH_RX_PENDING) {
+   if (atomic_read(&adapter->rx_pending) >= HIGH_RX_PENDING &&
+   adapter->iface_type != MWIFIEX_USB) {
adapter->delay_main_work = true;
if (!adapter->rx_processing)
queue_work(adapter->rx_workqueue,
-- 
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 1/5] mwifiex: fix sparse warning

[Amitkumar Karwar]

This patch fixes following sparse warnings:

drivers/net/wireless/mwifiex/util.c:152:19: warning: cast from restricted __le16
drivers/net/wireless/mwifiex/util.c:152:19: warning: restricted __le16 degrades 
to integer

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mwifiex/util.c 
b/drivers/net/wireless/mwifiex/util.c
index a113ef8..b1768fb 100644
--- a/drivers/net/wireless/mwifiex/util.c
+++ b/drivers/net/wireless/mwifiex/util.c
@@ -149,7 +149,7 @@ mwifiex_parse_mgmt_packet(struct mwifiex_private *priv, u8 
*payload, u16 len,
u8 category, action_code;
struct ieee80211_hdr *ieee_hdr = (void *)payload;
 
-   stype =  (cpu_to_le16(ieee_hdr->frame_control) & IEEE80211_FCTL_STYPE);
+   stype = (le16_to_cpu(ieee_hdr->frame_control) & IEEE80211_FCTL_STYPE);
 
switch (stype) {
case IEEE80211_STYPE_ACTION:
-- 
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 0/5] mwifiex updates

[Amitkumar Karwar]

This patchset includes couple of fixes, delay work queue logic
removal for USB interface and Tx status support work.

Amitkumar Karwar (5):
  mwifiex: fix sparse warning
  mwifiex: fix scan problem on big endian platforms
  mwifiex: skip delay main work logic for USB interface.
  mwifiex: add Tx status support for EAPOL packets
  mwifiex: add Tx status support for ACTION frames

 drivers/net/wireless/mwifiex/cfg80211.c  | 16 ++--
 drivers/net/wireless/mwifiex/decl.h  |  4 ++
 drivers/net/wireless/mwifiex/fw.h| 17 ++--
 drivers/net/wireless/mwifiex/init.c  |  3 ++
 drivers/net/wireless/mwifiex/main.c  | 68 +---
 drivers/net/wireless/mwifiex/main.h  | 11 ++
 drivers/net/wireless/mwifiex/scan.c  |  2 +-
 drivers/net/wireless/mwifiex/sta_event.c |  5 +++
 drivers/net/wireless/mwifiex/sta_tx.c|  6 +++
 drivers/net/wireless/mwifiex/txrx.c  | 31 +++
 drivers/net/wireless/mwifiex/uap_event.c |  4 ++
 drivers/net/wireless/mwifiex/uap_txrx.c  |  8 +++-
 drivers/net/wireless/mwifiex/util.c  |  2 +-
 drivers/net/wireless/mwifiex/wmm.c   | 10 +
 14 files changed, 172 insertions(+), 15 deletions(-)

-- 
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 v2 3/3] ath10k: fix station count enforcement

[Michal Kazior]

The number of peers isn't directly translatable to
the number of stations because ath10k needs to
reserve a few extra peers for special cases like
multi-vif concurrency.

The previous limit was 126 and 15 stations in AP
mode for 10.x and main firmware branches
respectively. The limit is now 128 and 16 which
was the original intention.

Signed-off-by: Michal Kazior 
---

Notes:
v2:
 * move ath10k_core_init_max_sta_count() call to
   ath10k_core_probe_fw() before ath10k_core_stat() [Kalle]

 drivers/net/wireless/ath/ath10k/core.c  | 13 +++
 drivers/net/wireless/ath/ath10k/core.h  |  4 +++
 drivers/net/wireless/ath/ath10k/debug.c |  5 +--
 drivers/net/wireless/ath/ath10k/hw.h| 15 ++---
 drivers/net/wireless/ath/ath10k/mac.c   | 60 ++---
 drivers/net/wireless/ath/ath10k/wmi.c   |  2 +-
 6 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f660553..7762061 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -799,6 +799,17 @@ static void ath10k_core_restart(struct work_struct *work)
mutex_unlock(&ar->conf_mutex);
 }
 
+static void ath10k_core_init_max_sta_count(struct ath10k *ar)
+{
+   if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features)) {
+   ar->max_num_peers = TARGET_10X_NUM_PEERS;
+   ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+   } else {
+   ar->max_num_peers = TARGET_NUM_PEERS;
+   ar->max_num_stations = TARGET_NUM_STATIONS;
+   }
+}
+
 int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
 {
int status;
@@ -1035,6 +1046,8 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
return ret;
}
 
+   ath10k_core_init_max_sta_count(ar);
+
mutex_lock(&ar->conf_mutex);
 
ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL);
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index be7e50b6..ab3b656 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -562,6 +562,10 @@ struct ath10k {
 
/* protected by conf_mutex */
int num_peers;
+   int num_stations;
+
+   int max_num_peers;
+   int max_num_stations;
 
struct work_struct offchan_tx_work;
struct sk_buff_head offchan_tx_queue;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index f10721d..49930e2 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -123,7 +123,7 @@ EXPORT_SYMBOL(ath10k_info);
 
 void ath10k_print_driver_info(struct ath10k *ar)
 {
-   ath10k_info(ar, "%s (0x%08x, 0x%08x) fw %s api %d htt %d.%d wmi 
%d.%d.%d.%d cal %s\n",
+   ath10k_info(ar, "%s (0x%08x, 0x%08x) fw %s api %d htt %d.%d wmi 
%d.%d.%d.%d cal %s max_sta %d\n",
ar->hw_params.name,
ar->target_version,
ar->chip_id,
@@ -135,7 +135,8 @@ void ath10k_print_driver_info(struct ath10k *ar)
ar->fw_version_minor,
ar->fw_version_release,
ar->fw_version_build,
-   ath10k_cal_mode_str(ar->cal_mode));
+   ath10k_cal_mode_str(ar->cal_mode),
+   ar->max_num_stations);
ath10k_info(ar, "debug %d debugfs %d tracing %d dfs %d testmode %d\n",
config_enabled(CONFIG_ATH10K_DEBUG),
config_enabled(CONFIG_ATH10K_DEBUGFS),
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index 392c250..dfedfd0 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -97,11 +97,13 @@ struct ath10k_pktlog_hdr {
 #define TARGET_DMA_BURST_SIZE  0
 #define TARGET_MAC_AGGR_DELIM  0
 #define TARGET_AST_SKID_LIMIT  16
-#define TARGET_NUM_PEERS   16
+#define TARGET_NUM_STATIONS16
+#define TARGET_NUM_PEERS   ((TARGET_NUM_STATIONS) + \
+(TARGET_NUM_VDEVS))
 #define TARGET_NUM_OFFLOAD_PEERS   0
 #define TARGET_NUM_OFFLOAD_REORDER_BUFS 0
 #define TARGET_NUM_PEER_KEYS   2
-#define TARGET_NUM_TIDS(2 * ((TARGET_NUM_PEERS) + 
(TARGET_NUM_VDEVS)))
+#define TARGET_NUM_TIDS((TARGET_NUM_PEERS) * 2)
 #define TARGET_TX_CHAIN_MASK   (BIT(0) | BIT(1) | BIT(2))
 #define TARGET_RX_CHAIN_MASK   (BIT(0) | BIT(1) | BIT(2))
 #define TARGET_RX_TIMEOUT_LO_PRI   100
@@ -132,12 +134,15 @@ struct ath10k_pktlog_hdr {
 #define TARGET_10X_DMA_BURST_SIZE  0
 #define TARGET_10X_MAC_AGGR_DELIM  0
 #de

[PATCH v2 2/3] ath10k: clean up num_peers locking

[Michal Kazior]

The var was supposed to be protected by data_lock
but it wasn't so in all instances. It's actually
not necessary to have a spinlock protected
num_peers so drop it.

All instances of num_peers are already within
conf_mutex sections so use that.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/core.h | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd3..be7e50b6 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -560,7 +560,7 @@ struct ath10k {
struct list_head peers;
wait_queue_head_t peer_mapping_wq;
 
-   /* number of created peers; protected by data_lock */
+   /* protected by conf_mutex */
int num_peers;
 
struct work_struct offchan_tx_work;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 7b5a888..3312e75 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -339,9 +339,8 @@ static int ath10k_peer_create(struct ath10k *ar, u32 
vdev_id, const u8 *addr)
addr, vdev_id, ret);
return ret;
}
-   spin_lock_bh(&ar->data_lock);
+
ar->num_peers++;
-   spin_unlock_bh(&ar->data_lock);
 
return 0;
 }
@@ -432,9 +431,7 @@ static int ath10k_peer_delete(struct ath10k *ar, u32 
vdev_id, const u8 *addr)
if (ret)
return ret;
 
-   spin_lock_bh(&ar->data_lock);
ar->num_peers--;
-   spin_unlock_bh(&ar->data_lock);
 
return 0;
 }
@@ -471,8 +468,9 @@ static void ath10k_peer_cleanup_all(struct ath10k *ar)
list_del(&peer->list);
kfree(peer);
}
-   ar->num_peers = 0;
spin_unlock_bh(&ar->data_lock);
+
+   ar->num_peers = 0;
 }
 
 //
-- 
1.8.5.3

--
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 1/3] ath10k: add missing goto

[Michal Kazior]

This prevents warning spamming if peer creation
fails during sta_state in some cases.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 1245ac8..7b5a888 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3559,9 +3559,11 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
   arvif->vdev_id, sta->addr, ar->num_peers);
 
ret = ath10k_peer_create(ar, arvif->vdev_id, sta->addr);
-   if (ret)
+   if (ret) {
ath10k_warn(ar, "failed to add peer %pM for vdev %d 
when adding a new sta: %i\n",
sta->addr, arvif->vdev_id, ret);
+   goto exit;
+   }
 
if (vif->type == NL80211_IFTYPE_STATION) {
WARN_ON(arvif->is_started);
-- 
1.8.5.3

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

Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[Johannes Berg]

On Tue, 2014-11-25 at 22:13 +0800, YanBo wrote:

> > But is all of that really the right way? I'm not completely convinced.
> 
> Except set the flag, the HW itself should support this feature, or
> else it also doesn't work, I'd
> send the patch in soon for public review.

Yeah, but is it really the right way to advertise VHT? In the spec, VHT
means you also have 80 MHz support - do you really think you can/will do
80 MHz on 2.4 GHz? Seems like all of this will cause more corner cases.

> >
> > I guess we can make this check conditional for 5GHz when the VHT support
> > lands and is discussed.
> >
> That is sounds good if it only check for 5GHz for what I know CMIIW.

Even on 2.4 GHz it technically isn't enough though - there's enough
spectrum in 2.4 GHz for a single 80 MHz channel; how long until somebody
wants to do *that* for some reason? But the rest of us really doesn't
think that's applicable ...

Anyway, it probably needs mac80211 patches anyway since mlme.c already
disables VHT if you can't do 80 MHz, so I think you should post those as
part of a bigger discussion about how we want to support it and what it
really means etc.

johannes

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

Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[YanBo]

On Tue, Nov 25, 2014 at 8:07 PM, Johannes Berg
 wrote:
> On Tue, 2014-11-25 at 19:10 +0800, YanBo wrote:
>
>> We already start the working to support the VHT modulations MCS8 and
>> MCS9 support in 2.4G for ath10k  devices,
>> and it used the band->vht_cap = vht_cap to notification the mac80211,
>> if we band it with 80MHz, it is do need another
>> new advertisement for this as your said.
>
> But is all of that really the right way? I'm not completely convinced.

Except set the flag, the HW itself should support this feature, or
else it also doesn't work, I'd
send the patch in soon for public review.

>
> I guess we can make this check conditional for 5GHz when the VHT support
> lands and is discussed.
>
That is sounds good if it only check for 5GHz for what I know CMIIW.

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

Re: [rt2x00-users] [PATCH] rt2800: fix RT5592 TX power settings regression

[Stanislaw Gruszka]

On Fri, Nov 21, 2014 at 10:39:39AM +0100, Ronald Wahl wrote:
> For me the patch will work but there is a change for RT3290 and RT5390. On
> both chipsets BBP 1 was not written before but with this patch it is going
> to be written now and the value depends on the return of
> rt2800_get_txpower_bw_comp(). It should be checked that the function does
> the correct things for these chips.

I tested the patch on RT5390, it does not make troubles. Going to post
it ...

Stanislaw

--
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 3/4] brcmsmac: extend hardware info shown in debugfs

[Arend van Spriel]

On 11/25/14 13:12, Arend van Spriel wrote:

On 11/24/14 22:50, John W. Linville wrote:

Hmmm...I'm not sure why, but this is causing problems for me...

ERROR: "brcmu_boardrev_str"
[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!


I am confused as well. I did not have such an issue. The function is
provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and added
it to the include file. Missing something? Also I don't see this issue
over here. I will do a clean build on the wireless-next tree and see if
I can reproduce this.


So I did a fresh checkout of wireless-next/master and applied patch 2 
and 3. Here is my build output:


$ make M=drivers/net/wireless/brcm80211 modules
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/ampdu.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/antsel.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/channel.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/main.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/pmu.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/rate.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/stf.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/aiutils.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/dma.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.o
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/debug.o
  LD [M]  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.o
  CC [M]  drivers/net/wireless/brcm80211/brcmutil/utils.o
  CC [M]  drivers/net/wireless/brcm80211/brcmutil/d11.o
  LD [M]  drivers/net/wireless/brcm80211/brcmutil/brcmutil.o
  Building modules, stage 2.
  MODPOST 2 modules
  CC  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.mod.o
  LD [M]  drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
  CC  drivers/net/wireless/brcm80211/brcmutil/brcmutil.mod.o
  LD [M]  drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko

Anything else I should try over here?

Regards,
Arend

Regards,
Arend


On Thu, Nov 20, 2014 at 10:27:01PM +0100, Arend van Spriel wrote:

The hardware info now also include radio and phy information, which
can be helpful in debugging issues.

Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/brcm80211/brcmsmac/debug.c | 40
+
1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/debug.c
b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
index 19740c1..c9a8b93 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/debug.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
@@ -30,6 +30,7 @@
#include "main.h"
#include "debug.h"
#include "brcms_trace_events.h"
+#include "phy/phy_int.h"

static struct dentry *root_folder;

@@ -74,20 +75,33 @@ static
int brcms_debugfs_hardware_read(struct seq_file *s, void *data)
{
struct brcms_pub *drvr = s->private;
+ struct brcms_hardware *hw = drvr->wlc->hw;
+ struct bcma_device *core = hw->d11core;
+ struct bcma_bus *bus = core->bus;
+ char boardrev[10];

- seq_printf(s, "board vendor: %x\n"
- "board type: %x\n"
- "board revision: %x\n"
- "board flags: %x\n"
- "board flags2: %x\n"
- "firmware revision: %x\n",
- drvr->wlc->hw->d11core->bus->boardinfo.vendor,
- drvr->wlc->hw->d11core->bus->boardinfo.type,
- drvr->wlc->hw->boardrev,
- drvr->wlc->hw->boardflags,
- drvr->wlc->hw->boardflags2,
- drvr->wlc->ucode_rev);
-
+ seq_printf(s, "chipnum 0x%x\n"
+ "chiprev 0x%x\n"
+ "chippackage 0x%x\n"
+ "corerev 0x%x\n"
+ "boardid 0x%x\n"
+ "boardvendor 0x%x\n"
+ "boardrev %s\n"
+ "boardflags 0x%x\n"
+ "boardflags2 0x%x\n"
+ "ucoderev 0x%x\n"
+ "radiorev 0x%x\n"
+ "phytype 0x%x\n"
+ "phyrev 0x%x\n"
+ "anarev 0x%x\n"
+ "nvramrev %d\n",
+ bus->chipinfo.id, bus->chipinfo.rev, bus->chipinfo.pkg,
+ core->id.rev, bus->boardinfo.type, bus->boardinfo.vendor,
+ brcmu_boardrev_str(hw->boardrev, boardrev),
+ drvr->wlc->hw->boardflags, drvr->wlc->hw->boardflags2,
+ drvr->wlc->ucode_rev, hw->band->radiorev,
+ hw->band->phytype, hw->band->phyrev, hw->band->pi->ana_rev,
+ hw->sromrev);
return 0;
}

--
1.9.1






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


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel

Re: [PATCH 3/4] brcmsmac: extend hardware info shown in debugfs

[Arend van Spriel]

On 11/24/14 22:50, John W. Linville wrote:

Hmmm...I'm not sure why, but this is causing problems for me...

ERROR: "brcmu_boardrev_str" 
[drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!


I am confused as well. I did not have such an issue. The function is 
provided by brcmutil.ko (patch 2/4) and I did an EXPORT_SYMBOL and added 
it to the include file. Missing something? Also I don't see this issue 
over here. I will do a clean build on the wireless-next tree and see if 
I can reproduce this.


Regards,
Arend


On Thu, Nov 20, 2014 at 10:27:01PM +0100, Arend van Spriel wrote:

The hardware info now also include radio and phy information, which
can be helpful in debugging issues.

Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
  drivers/net/wireless/brcm80211/brcmsmac/debug.c | 40 +
  1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/debug.c 
b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
index 19740c1..c9a8b93 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/debug.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
@@ -30,6 +30,7 @@
  #include "main.h"
  #include "debug.h"
  #include "brcms_trace_events.h"
+#include "phy/phy_int.h"

  static struct dentry *root_folder;

@@ -74,20 +75,33 @@ static
  int brcms_debugfs_hardware_read(struct seq_file *s, void *data)
  {
struct brcms_pub *drvr = s->private;
+   struct brcms_hardware *hw = drvr->wlc->hw;
+   struct bcma_device *core = hw->d11core;
+   struct bcma_bus *bus = core->bus;
+   char boardrev[10];

-   seq_printf(s, "board vendor: %x\n"
-  "board type: %x\n"
-  "board revision: %x\n"
-  "board flags: %x\n"
-  "board flags2: %x\n"
-  "firmware revision: %x\n",
-  drvr->wlc->hw->d11core->bus->boardinfo.vendor,
-  drvr->wlc->hw->d11core->bus->boardinfo.type,
-  drvr->wlc->hw->boardrev,
-  drvr->wlc->hw->boardflags,
-  drvr->wlc->hw->boardflags2,
-  drvr->wlc->ucode_rev);
-
+   seq_printf(s, "chipnum 0x%x\n"
+  "chiprev 0x%x\n"
+  "chippackage 0x%x\n"
+  "corerev 0x%x\n"
+  "boardid 0x%x\n"
+  "boardvendor 0x%x\n"
+  "boardrev %s\n"
+  "boardflags 0x%x\n"
+  "boardflags2 0x%x\n"
+  "ucoderev 0x%x\n"
+  "radiorev 0x%x\n"
+  "phytype 0x%x\n"
+  "phyrev 0x%x\n"
+  "anarev 0x%x\n"
+  "nvramrev %d\n",
+  bus->chipinfo.id, bus->chipinfo.rev, bus->chipinfo.pkg,
+  core->id.rev, bus->boardinfo.type, bus->boardinfo.vendor,
+  brcmu_boardrev_str(hw->boardrev, boardrev),
+  drvr->wlc->hw->boardflags, drvr->wlc->hw->boardflags2,
+  drvr->wlc->ucode_rev, hw->band->radiorev,
+  hw->band->phytype, hw->band->phyrev, hw->band->pi->ana_rev,
+  hw->sromrev);
return 0;
  }

--
1.9.1






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

Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[Johannes Berg]

On Tue, 2014-11-25 at 19:10 +0800, YanBo wrote:

> We already start the working to support the VHT modulations MCS8 and
> MCS9 support in 2.4G for ath10k  devices,
> and it used the band->vht_cap = vht_cap to notification the mac80211,
> if we band it with 80MHz, it is do need another
> new advertisement for this as your said.

But is all of that really the right way? I'm not completely convinced.

I guess we can make this check conditional for 5GHz when the VHT support
lands and is discussed.

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

Question : WMM queue management in AP role

[Cedric VONCKEN]

Hi all,

The AP role can manage several sta.
In case of WMM, each sta have a separate queue or all sta use the same
queue? 

Where can I found any information on the WMM queue management in linux
wireless?

I'm using ath9k driver.

Cedric Voncken

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

Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[YanBo]

On Tue, Nov 25, 2014 at 7:04 PM, Johannes Berg
 wrote:
> On Tue, 2014-11-25 at 19:00 +0800, YanBo wrote:
>> On Tue, Nov 25, 2014 at 6:23 PM, Johannes Berg
>>  wrote:
>> > From: Johannes Berg 
>> >
>> > If there are no channels allowing 80 MHz to be used, then the
>> > station isn't really VHT capable even if the driver and device
>> > support it in general. In this case, exclude the VHT capability
>> > IE from probe request frames.
>> >
>>
>> FYI, there are some new devices could support the VHT even at 20Mhz
>> band 2.4G mode.
>
> So in 2.4 GHz we typically don't have VHT anyway - and realistically you
> can't support real "VHT" there, you can only support the new
> modulations. I think this will require some custom (vendor-specific)
> advertisement though, since VHT advertisement implies 80 MHz support.
>
> IOW, I think at this point this patch isn't a problem. If we really need
> to support VHT modulations in 2.4 GHz (or even have devices that have
> VHT modulation support, but no 80 MHz support in 5 GHz) then some new
> advertisement will have to be done.
>
We already start the working to support the VHT modulations MCS8 and
MCS9 support in 2.4G for ath10k  devices,
and it used the band->vht_cap = vht_cap to notification the mac80211,
if we band it with 80MHz, it is do need another
new advertisement for this as your said.

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

Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[Johannes Berg]

On Tue, 2014-11-25 at 19:00 +0800, YanBo wrote:
> On Tue, Nov 25, 2014 at 6:23 PM, Johannes Berg
>  wrote:
> > From: Johannes Berg 
> >
> > If there are no channels allowing 80 MHz to be used, then the
> > station isn't really VHT capable even if the driver and device
> > support it in general. In this case, exclude the VHT capability
> > IE from probe request frames.
> >
> 
> FYI, there are some new devices could support the VHT even at 20Mhz
> band 2.4G mode.

So in 2.4 GHz we typically don't have VHT anyway - and realistically you
can't support real "VHT" there, you can only support the new
modulations. I think this will require some custom (vendor-specific)
advertisement though, since VHT advertisement implies 80 MHz support.

IOW, I think at this point this patch isn't a problem. If we really need
to support VHT modulations in 2.4 GHz (or even have devices that have
VHT modulation support, but no 80 MHz support in 5 GHz) then some new
advertisement will have to be done.

OTOH, you could argue for that advertisement that on 2.4 GHz you can
never do 80 MHz anyway - but can't you? In theory there's enough
spectrum for exactly one 80 MHz channel ...

johannes

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

Re: [PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[YanBo]

On Tue, Nov 25, 2014 at 6:23 PM, Johannes Berg
 wrote:
> From: Johannes Berg 
>
> If there are no channels allowing 80 MHz to be used, then the
> station isn't really VHT capable even if the driver and device
> support it in general. In this case, exclude the VHT capability
> IE from probe request frames.
>

FYI, there are some new devices could support the VHT even at 20Mhz
band 2.4G mode.

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

[PATCH v3 1/2] ath10k: add register access debugfs interface

[Kalle Valo]

From: Yanbo Li 

Debugfs files reg_addr and reg_val are used for reading and writing to the
firmware (target) registers. reg_addr contains the address to be accessed,
which also needs to be set first, and reg_value is when used for reading and
writing the actual value in ASCII.

To read a value from the firmware register 0x10:

# echo 0x10 > reg_addr
# cat reg_value
0x0010:0x02d3

To write value 0x2400 to address 0x10:

# echo 0x10 > reg_addr
# echo  0x2400 > reg_value
#

Signed-off-by: Yanbo Li 
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/core.h  |1 
 drivers/net/wireless/ath/ath10k/debug.c |  125 +++
 drivers/net/wireless/ath/ath10k/hif.h   |   26 ++
 drivers/net/wireless/ath/ath10k/pci.c   |2 
 4 files changed, 154 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8f86bd34e823..f5f2dcd2b65d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -320,6 +320,7 @@ struct ath10k_debug {
/* protected by conf_mutex */
u32 fw_dbglog_mask;
u32 pktlog_filter;
+   u32 reg_addr;
 
u8 htt_max_amsdu;
u8 htt_max_ampdu;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index f10721da4980..d0397d119862 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -928,6 +928,125 @@ static const struct file_operations fops_fw_crash_dump = {
.llseek = default_llseek,
 };
 
+static ssize_t ath10k_reg_addr_read(struct file *file,
+   char __user *user_buf,
+   size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   u8 buf[32];
+   unsigned int len = 0;
+   u32 reg_addr;
+
+   mutex_lock(&ar->conf_mutex);
+   reg_addr = ar->debug.reg_addr;
+   mutex_unlock(&ar->conf_mutex);
+
+   len += scnprintf(buf + len, sizeof(buf) - len, "0x%x\n", reg_addr);
+
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t ath10k_reg_addr_write(struct file *file,
+const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   u32 reg_addr;
+   int ret;
+
+   ret = kstrtou32_from_user(user_buf, count, 0, ®_addr);
+   if (ret)
+   return ret;
+
+   if (!IS_ALIGNED(reg_addr, 4))
+   return -EFAULT;
+
+   mutex_lock(&ar->conf_mutex);
+   ar->debug.reg_addr = reg_addr;
+   mutex_unlock(&ar->conf_mutex);
+
+   return count;
+}
+
+static const struct file_operations fops_reg_addr = {
+   .read = ath10k_reg_addr_read,
+   .write = ath10k_reg_addr_write,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
+static ssize_t ath10k_reg_value_read(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   u8 buf[48];
+   unsigned int len;
+   u32 reg_addr, reg_val;
+   int ret;
+
+   mutex_lock(&ar->conf_mutex);
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   reg_addr = ar->debug.reg_addr;
+
+   reg_val = ath10k_hif_read32(ar, reg_addr);
+   len = scnprintf(buf, sizeof(buf), "0x%08x:0x%08x\n", reg_addr, reg_val);
+
+   ret = simple_read_from_buffer(user_buf, count, ppos, buf, len);
+
+exit:
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static ssize_t ath10k_reg_value_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   u32 reg_addr, reg_val;
+   int ret;
+
+   mutex_lock(&ar->conf_mutex);
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   reg_addr = ar->debug.reg_addr;
+
+   ret = kstrtou32_from_user(user_buf, count, 0, ®_val);
+   if (ret)
+   goto exit;
+
+   ath10k_hif_write32(ar, reg_addr, reg_val);
+
+   ret = count;
+
+exit:
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static const struct file_operations fops_reg_value = {
+   .read = ath10k_reg_value_read,
+   .write = ath10k_reg_value_write,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 static int ath10k_debug_htt_stats_req(struct ath10k *ar)
 {
u64 cookie;
@@ -1629,6 +1748

[PATCH v3 0/2] ath10k: firmware memory debugfs interface

[Kalle Valo]

Hi,

this is v3 of Yanbo's firmware memory debugfs interface.

Changelog:

v3:

* check ath10k state and return an error if firmware is not running

* switch to use conf_mutex because using ar->state

* fix copy_from_user() error handling

v2:

* split patches into two

* simplify the commit logs

* remove extra #include "hif.h" from debug.c

---

Yanbo Li (2):
  ath10k: add register access debugfs interface
  ath10k: add memory dump debugfs interface


 drivers/net/wireless/ath/ath10k/core.h  |1 
 drivers/net/wireless/ath/ath10k/debug.c |  239 +++
 drivers/net/wireless/ath/ath10k/hif.h   |   37 +
 drivers/net/wireless/ath/ath10k/pci.c   |3 
 4 files changed, 280 insertions(+)

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

[PATCH v3 2/2] ath10k: add memory dump debugfs interface

[Kalle Valo]

From: Yanbo Li 

Add mem_val debugfs file for dumping the firmware (target) memory and also for
writing to the memory. The firmware memory is accessed through one file which
uses position of the file as the firmware memory address. For example, with dd
use skip parameter for the address.

Beucase target memory width is 32 bits it's strongly recommended to use
blocksize divisable with 4 when using this interface. For example, when using
dd use bs=4 to set the block size to 4 and remember to divide both count and
skip values with four.

To read 4 kB chunk from address 0x40:

dd if=mem_value bs=4 count=1024 skip=1048576 | xxd -g1

To write value 0x01020304 to address 0x400400:

echo 0x01020304 | xxd -r | dd of=mem_value bs=4 seek=1048832

To read 4 KB chunk of memory and then write back after edit:

dd if=mem_value of=tmp.bin bs=4 count=1024 skip=1048576
emacs tmp.bin
dd if=tmp.bin of=mem_value bs=4 count=1024 seek=1048576

Signed-off-by: Yanbo Li 
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/debug.c |  114 +++
 drivers/net/wireless/ath/ath10k/hif.h   |   11 +++
 drivers/net/wireless/ath/ath10k/pci.c   |1 
 3 files changed, 126 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index d0397d119862..ff831ca507f7 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1047,6 +1047,117 @@ static const struct file_operations fops_reg_value = {
.llseek = default_llseek,
 };
 
+static ssize_t ath10k_mem_value_read(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   u8 *buf;
+   int ret;
+
+   if (*ppos < 0)
+   return -EINVAL;
+
+   if (!count)
+   return 0;
+
+   mutex_lock(&ar->conf_mutex);
+
+   buf = vmalloc(count);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto exit;
+   }
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   ret = ath10k_hif_diag_read(ar, *ppos, buf, count);
+   if (ret) {
+   ath10k_warn(ar, "failed to read address 0x%08x via diagnose 
window fnrom debugfs: %d\n",
+   (u32)(*ppos), ret);
+   goto exit;
+   }
+
+   ret = copy_to_user(user_buf, buf, count);
+   if (ret) {
+   ret = -EFAULT;
+   goto exit;
+   }
+
+   count -= ret;
+   *ppos += count;
+   ret = count;
+
+exit:
+   vfree(buf);
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static ssize_t ath10k_mem_value_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   u8 *buf;
+   int ret;
+
+   if (*ppos < 0)
+   return -EINVAL;
+
+   if (!count)
+   return 0;
+
+   mutex_lock(&ar->conf_mutex);
+
+   buf = vmalloc(count);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto exit;
+   }
+
+   if (ar->state != ATH10K_STATE_ON &&
+   ar->state != ATH10K_STATE_UTF) {
+   ret = -ENETDOWN;
+   goto exit;
+   }
+
+   ret = copy_from_user(buf, user_buf, count);
+   if (ret) {
+   ret = -EFAULT;
+   goto exit;
+   }
+
+   ret = ath10k_hif_diag_write(ar, *ppos, buf, count);
+   if (ret) {
+   ath10k_warn(ar, "failed to write address 0x%08x via diagnose 
window from debugfs: %d\n",
+   (u32)(*ppos), ret);
+   goto exit;
+   }
+
+   *ppos += count;
+   ret = count;
+
+exit:
+   vfree(buf);
+   mutex_unlock(&ar->conf_mutex);
+
+   return ret;
+}
+
+static const struct file_operations fops_mem_value = {
+   .read = ath10k_mem_value_read,
+   .write = ath10k_mem_value_write,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 static int ath10k_debug_htt_stats_req(struct ath10k *ar)
 {
u64 cookie;
@@ -1754,6 +1865,9 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("reg_value", S_IRUSR | S_IWUSR,
ar->debug.debugfs_phy, ar, &fops_reg_value);
 
+   debugfs_create_file("mem_value", S_IRUSR | S_IWUSR,
+   ar->debug.debugfs_phy, ar, &fops_mem_value);
+
debugfs_create_file("chip_id", S_IRUSR, ar->debug.debugfs_phy,
ar, &fops_chip_id);
 
diff --git a/drivers/net/wireless/ath/ath10k/hif.h 
b/drivers/net/wireless/ath/ath10k/hif.h
index bad071906540..6ac552304546 100644
--- a/drive

[PATCH] mac80211: check if channels allow 80 MHz for VHT probe requests

[Johannes Berg]

From: Johannes Berg 

If there are no channels allowing 80 MHz to be used, then the
station isn't really VHT capable even if the driver and device
support it in general. In this case, exclude the VHT capability
IE from probe request frames.

Signed-off-by: Johannes Berg 
---
 net/mac80211/util.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index bb9664cb8831..974ebe70f5b0 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1339,6 +1339,7 @@ static int ieee80211_build_preq_ies_band(struct 
ieee80211_local *local,
int ext_rates_len;
int shift;
u32 rate_flags;
+   bool have_80mhz = false;
 
*offset = 0;
 
@@ -1467,7 +1468,15 @@ static int ieee80211_build_preq_ies_band(struct 
ieee80211_local *local,
*offset = noffset;
}
 
-   if (sband->vht_cap.vht_supported) {
+   /* Check if any channel in this sband supports at least 80 MHz */
+   for (i = 0; i < sband->n_channels; i++) {
+   if (!(sband->channels[i].flags & IEEE80211_CHAN_NO_80MHZ)) {
+   have_80mhz = true;
+   break;
+   }
+   }
+
+   if (sband->vht_cap.vht_supported && have_80mhz) {
if (end - pos < 2 + sizeof(struct ieee80211_vht_cap))
goto out_err;
pos = ieee80211_ie_build_vht_cap(pos, &sband->vht_cap,
-- 
2.1.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 2/2] ath10k: re-config ht_caps when chainmask is modified.

[Felix Fietkau]

On 2014-11-24 11:53, Kalle Valo wrote:
> Kalle Valo  writes:
> 
>>> @@ -2537,6 +2560,17 @@ static int __ath10k_set_antenna(struct ath10k *ar, 
>>> u32 tx_ant, u32 rx_ant)
>>> ar->cfg_tx_chainmask = tx_ant;
>>> ar->cfg_rx_chainmask = rx_ant;
>>>  
>>> +   ht_cap = ath10k_get_ht_cap(ar, true);
>>> +   vht_cap = ath10k_create_vht_cap(ar, true);
>>> +
>>> +   if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY)
>>> +   ar->mac.sbands[IEEE80211_BAND_2GHZ].ht_cap = ht_cap;
>>> +
>>> +   if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
>>> +   ar->mac.sbands[IEEE80211_BAND_5GHZ].ht_cap = ht_cap;
>>> +   ar->mac.sbands[IEEE80211_BAND_5GHZ].vht_cap = vht_cap;
>>> +   }
>>
>> So this modifies stryct wiphy::bands after we have called
>> ieee80211_register_hw(). Is this something which both cfg80211 and
>> mac80211 support? I didn't find the documentation mentioning anything
>> about this so I got a bit worried.
> 
> Johannes mentioned me that this is not supported so I am reluctant to
> take these. Unless I'm missing something, of course.
FWIW, ath9k has been doing the same for a long time now. Antenna
settings can only be changed while the device is stopped, so it should
be safe.

- 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 2/4] brcmutil: add helper function to format board revision

[Arend van Spriel]

On 11/24/14 22:53, John W. Linville wrote:

I am holding patches 2-4 until we resolve the brcmu_boardrev_str
build thing...


Actually, only patch 2 and 3 are related to the build thing. If that is 
what this is.


Regards,
Arend


On Thu, Nov 20, 2014 at 10:27:00PM +0100, Arend van Spriel wrote:

The board revision that is available in hardware can be translated
so it matches the labelling on the board. This is accomplished by
this helper function.

Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
  drivers/net/wireless/brcm80211/brcmutil/utils.c  | 16 
  drivers/net/wireless/brcm80211/include/brcmu_utils.h |  2 ++
  2 files changed, 18 insertions(+)

diff --git a/drivers/net/wireless/brcm80211/brcmutil/utils.c 
b/drivers/net/wireless/brcm80211/brcmutil/utils.c
index 0f7e1c7..af97f8b 100644
--- a/drivers/net/wireless/brcm80211/brcmutil/utils.c
+++ b/drivers/net/wireless/brcm80211/brcmutil/utils.c
@@ -292,4 +292,20 @@ void brcmu_dbg_hex_dump(const void *data, size_t size, 
const char *fmt, ...)
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, data, size);
  }
  EXPORT_SYMBOL(brcmu_dbg_hex_dump);
+
+/* Produce a human-readable string for boardrev */
+char *brcmu_boardrev_str(u32 brev, char *buf)
+{
+   char c;
+
+   if (brev<  0x100) {
+   snprintf(buf, 8, "%d.%d", (brev&  0xf0)>>  4, brev&  0xf);
+   } else {
+   c = (brev&  0xf000) == 0x1000 ? 'P' : 'A';
+   snprintf(buf, 8, "%c%03x", c, brev&  0xfff);
+   }
+   return buf;
+}
+EXPORT_SYMBOL(brcmu_boardrev_str);
+
  #endif/* defined(DEBUG) */
diff --git a/drivers/net/wireless/brcm80211/include/brcmu_utils.h 
b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
index 8ba445b..a043e29 100644
--- a/drivers/net/wireless/brcm80211/include/brcmu_utils.h
+++ b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
@@ -218,4 +218,6 @@ void brcmu_dbg_hex_dump(const void *data, size_t size, 
const char *fmt, ...)
  }
  #endif

+char *brcmu_boardrev_str(u32 brev, char *buf);
+
  #endif/* _BRCMU_UTILS_H_ */
--
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 3.18] mac80211: copy chandef from AP vif to VLANs

[Johannes Berg]

On Mon, 2014-11-24 at 18:12 +0100, Felix Fietkau wrote:
> Fixes a crash in nl80211_send_chandef, introduced in
> 
> commit c12bc4885f4b3bab0ed779c69d5d7e3223fa5003
> "mac80211: return the vif's chandef in ieee80211_cfg_get_channel()"

I think you should explain this a bit more.

Code looks fine - maybe we can even have a follow-up patch that removes
some special cases for VLAN?

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] ath10k: don't drop corrupted mgmt frames

[Kalle Valo]

Michal Kazior  writes:

> On 25 November 2014 at 10:04, Kalle Valo  wrote:
>> Michal Kazior  writes:
> [...]
>>> @@ -1394,12 +1396,19 @@ static bool ath10k_htt_rx_amsdu_allowed(struct 
>>> ath10k *ar,
>>>   return false;
>>>   }
>>>
>>> + is_mgmt = !!(rxd->attention.flags &
>>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_MGMT_TYPE));
>>> + has_fcs_err = !!(rxd->attention.flags &
>>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_FCS_ERR));
>>
>> I think I asked this before in some other patch, but isn't '!!' operator
>> useless here? is_mgmt is a boolean so the compiler should convert it
>> correctly without '!!' anyway, right?
>
> If I remove `!!` I get:
>
>  warning: incorrect type in assignment (different base types)
> expected bool [unsigned] [usertype] is_mgmt
> got restricted __le32

Oh. Sorry, my bad.

> I could do a temporary `u32 attention` to get rid of the `!!`. You
> want me to update it?

Please don't, this is fine.

-- 
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] ath10k: don't drop corrupted mgmt frames

[Michal Kazior]

On 25 November 2014 at 10:04, Kalle Valo  wrote:
> Michal Kazior  writes:
[...]
>> @@ -1394,12 +1396,19 @@ static bool ath10k_htt_rx_amsdu_allowed(struct 
>> ath10k *ar,
>>   return false;
>>   }
>>
>> + is_mgmt = !!(rxd->attention.flags &
>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_MGMT_TYPE));
>> + has_fcs_err = !!(rxd->attention.flags &
>> +  __cpu_to_le32(RX_ATTENTION_FLAGS_FCS_ERR));
>
> I think I asked this before in some other patch, but isn't '!!' operator
> useless here? is_mgmt is a boolean so the compiler should convert it
> correctly without '!!' anyway, right?

If I remove `!!` I get:

 warning: incorrect type in assignment (different base types)
expected bool [unsigned] [usertype] is_mgmt
got restricted __le32

I could do a temporary `u32 attention` to get rid of the `!!`. You
want me to update it?


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] ath10k: don't drop corrupted mgmt frames

[Kalle Valo]

Michal Kazior  writes:

> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -1381,6 +1381,8 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k 
> *ar,
>  {
>   struct sk_buff *msdu;
>   struct htt_rx_desc *rxd;
> + bool is_mgmt;
> + bool has_fcs_err;
>  
>   msdu = skb_peek(amsdu);
>   rxd = (void *)msdu->data - sizeof(*rxd);
> @@ -1394,12 +1396,19 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k 
> *ar,
>   return false;
>   }
>  
> + is_mgmt = !!(rxd->attention.flags &
> +  __cpu_to_le32(RX_ATTENTION_FLAGS_MGMT_TYPE));
> + has_fcs_err = !!(rxd->attention.flags &
> +  __cpu_to_le32(RX_ATTENTION_FLAGS_FCS_ERR));

I think I asked this before in some other patch, but isn't '!!' operator
useless here? is_mgmt is a boolean so the compiler should convert it
correctly without '!!' anyway, right?

-- 
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 v2 2/2] ath10k: add memory dump debugfs interface

[Michal Kazior]

On 25 November 2014 at 09:41, Kalle Valo  wrote:
> Kalle Valo  writes:
>
>> +static ssize_t ath10k_mem_value_read(struct file *file,
>> +  char __user *user_buf,
>> +  size_t count, loff_t *ppos)
>> +{
[...]
>> +static ssize_t ath10k_mem_value_write(struct file *file,
>> +   const char __user *user_buf,
>> +   size_t count, loff_t *ppos)
[...]
> In these two functions we also need to check ar->state.

It should work but the pci_wake (I've mentioned in the other mail) is
tricky though.


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 v2 1/2] ath10k: add register access debugfs interface

[Michal Kazior]

On 25 November 2014 at 09:39, Kalle Valo  wrote:
> Kalle Valo  writes:
>
>> +static ssize_t ath10k_reg_value_read(struct file *file,
>> +  char __user *user_buf,
>> +  size_t count, loff_t *ppos)
>> +{
>> + struct ath10k *ar = file->private_data;
>> + u8 buf[48];
>> + unsigned int len;
>> + u32 reg_addr, reg_val;
>> +
>> + spin_lock_bh(&ar->data_lock);
>> + reg_addr = ar->debug.reg_addr;
>> + spin_unlock_bh(&ar->data_lock);
>> +
>> + reg_val = ath10k_hif_read32(ar, reg_addr);
>> + len = scnprintf(buf, sizeof(buf), "0x%08x:0x%08x\n", reg_addr, 
>> reg_val);
>> +
>> + return simple_read_from_buffer(user_buf, count, ppos, buf, len);
>> +}
>
> I just realised that we need to check ar->state to make sure that
> firmware is running. Because of that I'll need to change the data_lock
> to conf_mutex as well.

Hmm.. It could actually work without firmware running. It just reads MMIO.

The problem I see now is the target may not be awake (Bartosz recently
fixed suspend bug by moving ath10k_pci_wake/sleep back to
hif_power_up) and accessing target registers without it being fully
awake can lead to host memory corruption. I guess ar->state will do
for now because getting this to work otherwise is going to be a little
tricky.


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 3/3] ath10k: fix station count enforcement

[Kalle Valo]

Michal Kazior  writes:

>>>  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
>>>  {
>>>   int status;
>>> @@ -939,6 +950,8 @@ int ath10k_core_start(struct ath10k *ar, enum 
>>> ath10k_firmware_mode mode)
>>>   else
>>>   ar->free_vdev_map = (1LL << TARGET_NUM_VDEVS) - 1;
>>>
>>> + ath10k_core_init_max_sta_count(ar);
>>
>> I don't see the need to call this during every firmware start as these
>> are not changed afterwards. I think it would be better to call this once
>> just after ath10k_core_fetch_firmware_files() is called.
>
> Hmm.. It makes sense but now that I think about it the max number of
> peers should actually depend on WMI_SERVICE_IRAM_TIDS which is known
> after booting firmware. However since only 10.x was released with the
> service enabled we used fw_features. So..

I think this is good enough for now. We can always improve this later.

> yeah. I can move the function call if you want though.

Please do that. To keep things simple I would like to have the absolute
minimum in start() calls.

-- 
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

[PATCH] cfg80211: remove pointless channel lookup in survey code

[Johannes Berg]

From: Johannes Berg 

We have a channel pointer, and we use its center frequency
to look up a channel pointer - which will thus be exactly
the same as the original pointer.

Remove that pointless lookup and just use the pointer.

Signed-off-by: Johannes Berg 
---
 net/wireless/nl80211.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 6e4177701d86..b5e3c489239d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6562,8 +6562,6 @@ static int nl80211_dump_survey(struct sk_buff *skb,
}
 
while (1) {
-   struct ieee80211_channel *chan;
-
res = rdev_dump_survey(rdev, wdev->netdev, survey_idx, &survey);
if (res == -ENOENT)
break;
@@ -6576,9 +6574,7 @@ static int nl80211_dump_survey(struct sk_buff *skb,
goto out;
}
 
-   chan = ieee80211_get_channel(&rdev->wiphy,
-survey.channel->center_freq);
-   if (!chan || chan->flags & IEEE80211_CHAN_DISABLED) {
+   if (survey.channel->flags & IEEE80211_CHAN_DISABLED) {
survey_idx++;
continue;
}
-- 
2.1.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 v2 2/2] ath10k: add memory dump debugfs interface

[Kalle Valo]

Kalle Valo  writes:

> +static ssize_t ath10k_mem_value_read(struct file *file,
> +  char __user *user_buf,
> +  size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar = file->private_data;
> + u8 *buf;
> + int ret;
> +
> + if (*ppos < 0)
> + return -EINVAL;
> +
> + if (!count)
> + return 0;
> +
> + buf = vmalloc(count);
> + if (!buf)
> + return -ENOMEM;
> +
> + ret = ath10k_hif_diag_read(ar, *ppos, buf, count);
> + if (ret) {
> + ath10k_warn(ar, "failed to read address 0x%08x via diagnose 
> window from debugfs: %d\n",
> + (u32)(*ppos), ret);
> + goto read_err;
> + }
> +

[...]

> +static ssize_t ath10k_mem_value_write(struct file *file,
> +   const char __user *user_buf,
> +   size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar = file->private_data;
> + u8 *buf;
> + int ret;
> +
> + if (*ppos < 0)
> + return -EINVAL;
> +
> + if (!count)
> + return 0;
> +
> + buf = vmalloc(count);
> + if (!buf)
> + return -ENOMEM;
> +
> + ret = copy_from_user(buf, user_buf, count);
> + if (ret)
> + goto err_free_copy;
> +
> + ret = ath10k_hif_diag_write(ar, *ppos, buf, count);
> + if (ret) {
> + ath10k_warn(ar, "failed to write address 0x%08x via diagnose 
> window from debugfs: %d\n",
> + (u32)(*ppos), ret);
> + goto err_free_copy;
> + }

In these two functions we also need to check ar->state.

-- 
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 v2 1/2] ath10k: add register access debugfs interface

[Kalle Valo]

Kalle Valo  writes:

> +static ssize_t ath10k_reg_value_read(struct file *file,
> +  char __user *user_buf,
> +  size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar = file->private_data;
> + u8 buf[48];
> + unsigned int len;
> + u32 reg_addr, reg_val;
> +
> + spin_lock_bh(&ar->data_lock);
> + reg_addr = ar->debug.reg_addr;
> + spin_unlock_bh(&ar->data_lock);
> +
> + reg_val = ath10k_hif_read32(ar, reg_addr);
> + len = scnprintf(buf, sizeof(buf), "0x%08x:0x%08x\n", reg_addr, reg_val);
> +
> + return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> +}

I just realised that we need to check ar->state to make sure that
firmware is running. Because of that I'll need to change the data_lock
to conf_mutex as well.

> +static ssize_t ath10k_reg_value_write(struct file *file,
> +   const char __user *user_buf,
> +   size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar = file->private_data;
> + u32 reg_addr, reg_val;
> + int ret;
> +
> + spin_lock_bh(&ar->data_lock);
> + reg_addr = ar->debug.reg_addr;
> + spin_unlock_bh(&ar->data_lock);
> +
> + ret = kstrtou32_from_user(user_buf, count, 0, ®_val);
> + if (ret)
> + return ret;
> +
> + ath10k_hif_write32(ar, reg_addr, reg_val);
> +
> + return count;
> +}

And same here as well. I'll send v3.

-- 
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 3/3] ath10k: fix station count enforcement

[Michal Kazior]

On 25 November 2014 at 09:01, Kalle Valo  wrote:
> Michal Kazior  writes:
>
>> The number of peers isn't directly translatable to
>> the number of stations because ath10k needs to
>> reserve a few extra peers for special cases like
>> multi-vif concurrency.
>>
>> The previous limit was 126 and 15 stations in AP
>> mode for 10.x and main firmware branches
>> respectively. The limit is now 128 and 16 which
>> was the original intention.
>>
>> Signed-off-by: Michal Kazior 
>
> [...]
>
>> +static void ath10k_core_init_max_sta_count(struct ath10k *ar)
>> +{
>> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features)) {
>> + ar->max_num_peers = TARGET_10X_NUM_PEERS;
>> + ar->max_num_stations = TARGET_10X_NUM_STATIONS;
>> + } else {
>> + ar->max_num_peers = TARGET_NUM_PEERS;
>> + ar->max_num_stations = TARGET_NUM_STATIONS;
>> + }
>> +}
>> +
>>  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
>>  {
>>   int status;
>> @@ -939,6 +950,8 @@ int ath10k_core_start(struct ath10k *ar, enum 
>> ath10k_firmware_mode mode)
>>   else
>>   ar->free_vdev_map = (1LL << TARGET_NUM_VDEVS) - 1;
>>
>> + ath10k_core_init_max_sta_count(ar);
>
> I don't see the need to call this during every firmware start as these
> are not changed afterwards. I think it would be better to call this once
> just after ath10k_core_fetch_firmware_files() is called.

Hmm.. It makes sense but now that I think about it the max number of
peers should actually depend on WMI_SERVICE_IRAM_TIDS which is known
after booting firmware. However since only 10.x was released with the
service enabled we used fw_features. So.. yeah. I can move the
function call if you want though.


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 0/2] add TPC capability for AR9003 based chips

[Thomas Hühn]

Hi Lerenzo,

This series look good to me.

Greetings 
Thomas


> Am 25.11.2014 um 00:21 schrieb Lorenzo Bianconi 
> :
> 
> This patchset adds TPC capability to ath9k for AR9003 based chips. For the 
> time
> being some FCC checks are missing in ar9003_hw_init_txpower_stbc() and CDD 
> mode
> is not supported.
> 
> *[PATCH 1/2]: add TX power per-rate tables to cap TX power in TX descriptor 
> path
> *[PATCH 2/2]: cap per-packet TX power according to TX power per-rate tables
> 
> This pachset is based on Adrian Chadd's hints
> (https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg10396.html)
> 
> Changes since RFC:
> - make the ah->txpower array one-dimensional and store max TX power for the
>  current chainmask only
> 
> Lorenzo Bianconi (2):
>  ath9k: add TX power per-rate tables
>  ath9k: add TPC capability to TX descriptor path
> 
> drivers/net/wireless/ath/ath9k/ar9002_mac.c|   8 +-
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c |  47 +++
> drivers/net/wireless/ath/ath9k/ar9003_mac.c|   8 +-
> drivers/net/wireless/ath/ath9k/ar9003_phy.c| 174 +
> drivers/net/wireless/ath/ath9k/ath9k.h |   1 +
> drivers/net/wireless/ath/ath9k/beacon.c|   5 +-
> drivers/net/wireless/ath/ath9k/hw.h|   6 +
> drivers/net/wireless/ath/ath9k/mac.h   |   2 +-
> drivers/net/wireless/ath/ath9k/reg.h   |   2 +
> drivers/net/wireless/ath/ath9k/xmit.c  |  37 +-
> 10 files changed, 278 insertions(+), 12 deletions(-)
> 
> -- 
> 2.1.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

--
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] ath10k: move create-ht-cap methods above set-antenna.

[Kalle Valo]

gree...@candelatech.com writes:

> From: Ben Greear 
>
> We will need to use these in set-antenna, so move them
> so that we do not have to define the method signatures.
>
> Signed-off-by: Ben Greear 

I'm dropping these two patches. Please resend once we figure out how to
handle the band updated.

-- 
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 3/3] ath10k: fix station count enforcement

[Kalle Valo]

Michal Kazior  writes:

> The number of peers isn't directly translatable to
> the number of stations because ath10k needs to
> reserve a few extra peers for special cases like
> multi-vif concurrency.
>
> The previous limit was 126 and 15 stations in AP
> mode for 10.x and main firmware branches
> respectively. The limit is now 128 and 16 which
> was the original intention.
>
> Signed-off-by: Michal Kazior 

[...]

> +static void ath10k_core_init_max_sta_count(struct ath10k *ar)
> +{
> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features)) {
> + ar->max_num_peers = TARGET_10X_NUM_PEERS;
> + ar->max_num_stations = TARGET_10X_NUM_STATIONS;
> + } else {
> + ar->max_num_peers = TARGET_NUM_PEERS;
> + ar->max_num_stations = TARGET_NUM_STATIONS;
> + }
> +}
> +
>  int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
>  {
>   int status;
> @@ -939,6 +950,8 @@ int ath10k_core_start(struct ath10k *ar, enum 
> ath10k_firmware_mode mode)
>   else
>   ar->free_vdev_map = (1LL << TARGET_NUM_VDEVS) - 1;
>  
> + ath10k_core_init_max_sta_count(ar);

I don't see the need to call this during every firmware start as these
are not changed afterwards. I think it would be better to call this once
just after ath10k_core_fetch_firmware_files() is called.

-- 
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