[PATCH] ath9k_htc: add Altai WA1011N-GU

[Oleksij Rempel]

as reported in:
https://github.com/qca/open-ath9k-htc-firmware/pull/71#issuecomment-361100070

Signed-off-by: Oleksij Rempel <li...@rempel-privat.de>
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 56676eaff24c..cb0eef13af1c 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -24,6 +24,7 @@ static const struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
{ USB_DEVICE(0x0846, 0x9030) }, /* Netgear N150 */
+   { USB_DEVICE(0x07b8, 0x9271) }, /* Altai WA1011N-GU */
{ USB_DEVICE(0x07D1, 0x3A10) }, /* Dlink Wireless 150 */
{ USB_DEVICE(0x13D3, 0x3327) }, /* Azurewave */
{ USB_DEVICE(0x13D3, 0x3328) }, /* Azurewave */
-- 
2.14.1

elce linux conference 2017

[Oleksij Rempel]

Hi all,

are there any one of WiFi devs on ELCE?
Will be good to meet you. For example:
Table 1 - Networking Area, Level LL, Outside Roma.

Please contact me if you are here :)
-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"

[Oleksij Rempel]

Am 18.10.2017 um 16:50 schrieb Ben Greear:



On 10/18/2017 12:33 AM, Johannes Berg wrote:

Hi,


The call to set the rate in the driver comes before the error
check.

if (ieee80211_hw_check(>hw, HAS_RATE_CONTROL)) {
    ret = drv_set_bitrate_mask(local, sdata, mask);
    if (ret) {
    pr_err("%s: drv-set-bitrate-mask had error
return: %d\n",
   sdata->dev->name, ret);
    return ret;
    }
}

/*
 * If active validate the setting and reject it if it doesn't
leave
 * at least one basic rate usable, since we really have to be
able
 * to send something, and if we're an AP we have to be able to
do
 * so at a basic rate so that all clients can receive it.
 */
if (rcu_access_pointer(sdata->vif.chanctx_conf) &&
    sdata->vif.bss_conf.chandef.chan) {
    u32 basic_rates = sdata->vif.bss_conf.basic_rates;
    enum nl80211_band band = sdata-

vif.bss_conf.chandef.chan->band;


    if (!(mask->control[band].legacy & basic_rates)) {
     I changed this code so I could set a
single rate... --Ben
    pr_err("%s:  WARNING: no legacy rates for
band[%d] in set-bitrate-mask.\n",
   sdata->dev->name, band);
    }
}


Heh, that's just dumb. I guess I'll fix that by putting the test first,
no idea how that happened.




So, I think we should relax this check, at least for ath10k.


Well, yes and no. I don't think we should make ath10k special here,
and
this fixes a real problem - namely that you can set up the system
so
that you have no usable rates at all, and then you just get a
WARN_ON
and start using the lowest possible rate...


Well, there are a million ways to set up a broken system,


True, but this one actually happened in practice, for some reason, and
stopping the user from constantly shooting themselves in the foot seems
like a good idea to me. Especially if the user (or application) can't
really even know what they're getting into.

Now, the case in question was _client_ mode, but still.


and setting a single rate has a useful purpose, especially with
ath10k since it has such limited rate-setting capabilities.


You're stretching the definition of "useful purpose" a bit here though,
you're about the only one who's ever going to need to set a single
rate.


People trying to do regulatory testing want this feature, and other people
that are not me also like to test with specific rates.  Still a 
small-ish set

of people, but bigger than just me at least.


Till now i was interviewing different people who was asking for this for 
ath9k-htc. So I would say we have:

- academical researchers
- testers
- R
- exploit and penetration testers
- HAM
- just hackers

As for me, it sounds a s lot.


--
Regards,
Oleksij

Re: Two rtlwifi drivers?

[Oleksij Rempel]

Am 16.10.2017 um 15:07 schrieb Kalle Valo:
> Oleksij Rempel <li...@rempel-privat.de> writes:
> 
>>> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I 
>>>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>>>are developing, the changes will make us hard to integrate. However,
>>>I don't have plan to process the magic numbers in the module phydm,
>>>because the most of BB/RF registers contain many functions. And
>>>it doesn't have a register name but a bit field name instead.
>>>Our BB team guys say the use of enumeration or defined name will
>>>be unreadable, and the name is meaningless for most people.
>>
>> Experience with ath9k driver showed, that development was kind of
>> balanced between two groups, QCA and Community (Other companies,
>> researches, education and so on.). Saying: "you will not understand it
>> any way" is nor really helpful :)
>> Please don't repeat bad experience of Broadcom.
> 
> I agree with Oleksij here, but I want to still point out that there are
> cases when using magic numbers are ok, for example look at
> ar5008_initvals.h from ath9k. So it depends on case by case.

Beside. It is probably offtopic. I assume this initvals related to BB.
Is it possible to force a 802.11n controller to work in 802.11b mode? I
can image, it should be possible by reconfiguring BB. Correct?
-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Two rtlwifi drivers?

[Oleksij Rempel]

Hi
Just my two cents, :)

Am 16.10.2017 um 04:41 schrieb Pkshih:
> 
> 
>> -Original Message-
>> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
>> Sent: Thursday, October 12, 2017 6:35 PM
>> To: Kalle Valo
>> Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick 
>> Joarder;
>> de...@driverdev.osuosl.org; linux-wireless@vger.kernel.org; 
>> kernel-janit...@vger.kernel.org
>> Subject: Re: Two rtlwifi drivers?
>>
>> On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote:
 So what to do?  Any ideas?  What makes your life easier?  You can just
 ignore the staging tree, as it should not affect your portion of the
 kernel at all, right?
>>>
>>> Yes, I automatically ignore anything staging related. But the problem is
>>> that we now have two drivers with the same name and people don't always
>>> remember to prefix the patch with "staging: ". So on a bad day I might
>>> accidentally apply a patch which was meant for your tree. Of course I
>>> immediately revert it as soon as I, or someone else, catches that but
>>> annoying still.
>>
>> It doesn't bother me if you apply staging patches, I can handle the
>> merge issues :)
>>
>>> I think we have two options here:
>>>
>>> 1) We set a deadline (like 12 months or something) for the
>>>drivers/staging/rtlwifi and after that you refuse to take any patches
>>>for it. Hopefully this makes it clear for everyone that this fork is
>>>just temporary. I think Larry is trying to do this, which is great.
>>
>> Fine with me, if Larry is ok with it.
>>
>>> 2) We move the whole rtlwifi driver to staging. A very bad option but
>>>still better than forking the drivers.
>>
>> Ick, I don't want that to have to happen, that would not be good for the
>> users of other devices that the "real" rtlwifi driver supports.
>>
> 
> Hi Larry, Kalle and Gerg,
> 
> This is Realtek engineer, PK. I appreciate your support to submit, review 
> and merge patch. Since I'm a Linux newbie, I'll describe the situation of 
> rtlwifi and need your suggestions.
> 
> 
> 1) New modules in rtlwifi
>We add two modules named phydm and halmac, when adding rtl8822be in 
>staging. The phydm is BB/RF related module containing the parameters
>and APIs of BB/RF, and a dynamic mechanism to adapt to different
>field environment. The halmac consists of MAC APIs.
>The two modules are used by many OSs, so '#ifdef', CamelCase and
>so on are existing in original files. Hence, we convert them to Linux 
>form by script, but it's not perfect. Do you have suggestion to deal
>with this problem?
> 
> 
> 2) The rtlwifi in staging
>In staging, the module phydm v13 contains bugs, so I want to upgrade
>to v21 (Realtek internal version number). This upgrade contains a
>big patch that the difference between v13 and v21, and there are 
>40+ patches to support this upgrade. I have three options, and
>I want to know which one is prefer.
> 
> 2.1) apply 40+ patches to both staging and wireless tree, and apply
>  the big patch to staging only. After reviewing, we move the module
>  to wireless tree.
> 
> 2.2) apply 40+ patches to wireless tree, and apply a single bigger 
>  patch containing 40+ patches and the big patch to staging. I think
>  this can be seen as a new driver in staging. After reviewing, 
>  we move the module to wireless tree.
> 
> 2.3) don't apply anything to staging. Just apply 40+ patches and add
>  phydm v21 to wireless.
> 
> 
> 3) Coming drivers -- rtl8723de and rtl8821ce
>We're developing the two drivers, and rtl8723de and rtl8821ce will
>be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
>rtl8822be that in staging now, so the line of code will be fewer.
>The new files will be a new IC folder and IC supported files of 
>three modules that btcoexist, phydm and halmac. Could I submit
>them to wirless tree when they're ready?
> 
> 
> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I 
>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>are developing, the changes will make us hard to integrate. However,
>I don't have plan to process the magic numbers in the module phydm,
>because the most of BB/RF registers contain many functions. And
>it doesn't have a register name but a bit field name instead.
>Our BB team guys say the use of enumeration or defined name will
>be unreadable, and the name is meaningless for most people.

Experience with ath9k driver showed, that development was kind of
balanced between two groups, QCA and Community (Other companies,
researches, education and so on.). Saying: "you will not understand it
any way" is nor really helpful :)
Please don't repeat bad experience of Broadcom.

> Many Linux users ask Larry about the new drivers, and Realtek will
> provide drivers and try to submit them by myself. I hope the Linux
> users can yield the drivers as soon as I 

Re: Atheros TL-721N adapter refuses to enumerate on the USB Bus (ath9k_htc)

[Oleksij Rempel]

Am 11.10.2017 um 20:17 schrieb M D:
> Hi,
> My system details are as follows
> 
> Hardware:
> CPU  :  ARM based platform, imx21
> USB   : USB Host Controller 1.1 Full Speed 
> Mode
> 
> Software:
> Firmware  :  /lib/firmware/htc_9271.fw
> (version 1.3 / version 1.4)
> Device Driver   :  Backports (v3.12.8-1)
> OS:  Linux Kernel 3.0.101, ARM
> Freescale IMX21ADS

Heh... I doubt this configuration can be more exotic :D

> Problem Statement:
> 
> -The WiFi adapter is connected directly to the USB Port and is
> configured in Full Speed mode
> -After it is plugged in, it is enumerated on the Bus (that is,
> executing the instruction lsusb shows the vendor and product
> information)
> -After repeated reboots, after one random reboot the issue
> occurs. (usually 1 out of 5 times) the wlan0 node does not come up
> -When the issue occurs the following details below describe
> the issue at best
> 
> 
> 1)  The adapter is visible on the USB bus (adapter gets enumerated)
> 2)  The required modules are loaded
> 3)  However the wireless networking node, wlan0 does not come up
> 4)  One of the threads created during the init goes into a D state
> 
> root   1024  0.0  0.0  0 0 ?D11:06   0:00
> [firmware/htc_92]
> 
> In the file drivers/net/wireless/ath/ath9k/hif_usb.c
> [
> 
> hif_usb.c
> ...
> 
> ret = request_firmware_nowait(THIS_MODULE, true, hif_dev->fw_name,
>   _dev->udev->dev, GFP_KERNEL,
>   hif_dev, ath9k_hif_usb_firmware_cb);
> 
> 
> compat_firmware_class.c
> ...
> task = kthread_run(request_firmware_work_func, fw_work,
> "firmware/%s", name);
> ]
> 
> 
> 5) This is recoverable only after manually unplugging out the Adapter.
> 
> ROOT CAUSE OF THE ISSUE:
> 6) The underlying cause is due to the wifi adapter being configured in
> FULL SPEED mode. Due to this the endpoints 3 and 4 get configured as
> BULK and not INT.
> 
> 
> After some investigation, I made the following changes which helps to
> recover the adapter when the issue occurs,
> 
> --- 
> ../original-backports/backports-3.12.8-1/drivers/net/wireless/ath/ath9k/hif_usb.c
>   2017-10-11 10:50:05.043241000 -0700
> +++ drivers/net/wireless/ath/ath9k/hif_usb.c2017-10-11
> 10:50:03.154255000 -0700
> @@ -24,6 +24,8 @@
>  MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
>  MODULE_FIRMWARE(FIRMWARE_AR9271);
> 
> +static void ath9k_hif_usb_reboot(struct usb_device *udev);
> +
> 
> @@ -1189,7 +1193,12 @@
>  {
> struct usb_device *udev = interface_to_usbdev(interface);
> struct hif_device_usb *hif_dev;
> -   int ret = 0;
> +
> +struct usb_host_interface *alt ;
> +struct usb_endpoint_descriptor *endp;
> +
> +   int ret;
> +   int idx, EP = 0;
> 
> if (id->driver_info == STORAGE_DEVICE)
> return send_eject_command(interface);
> @@ -1212,6 +1221,44 @@
> 
> init_completion(_dev->fw_done);
> 
> +   alt = _dev->interface->altsetting[0];
> +
> +
> +   for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) {
> +endp = >endpoint[idx].desc;
> +EP = idx + 1;
> +printk (KERN_ALERT "EndPoint %d is conf as %d\n", EP,
> (endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK));
> +   /* First FIX EP3. EP3 should never show up as BULK.
> +  If it does we have a serious problem.
> +   */
> +
> +   if (endp->bEndpointAddress==0x83){
> +  if ((endp->bmAttributes &
> USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
> +   endp->bmAttributes |= USB_ENDPOINT_XFER_INT;
> +   endp->bInterval = 1;
> +   ath9k_hif_usb_reboot(hif_dev->udev);
> +   mdelay(1000);
> +   ret = usb_reset_device(hif_dev->udev);
> +   mdelay(1000);
> +if (ret)
> +   return ret;
> +   }
> +   }
> +
> +if (endp->bEndpointAddress==0x04){
> +   if ((endp->bmAttributes &
> USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
> +endp->bmAttributes |= USB_ENDPOINT_XFER_INT;
> +endp->bInterval = 1;
> +   ath9k_hif_usb_reboot(hif_dev->udev);
> +   mdelay(1000);
> +   ret = usb_reset_device(hif_dev->udev);
> +   mdelay(1000);
> +   if (ret)
> +   return ret;
> +  }
> +   }
> +   }
> +
> /* Find out which firmware to load */
> 
> if (IS_AR7010_DEVICE(id->driver_info))
> 
> 
> 
> I see the following output in dmesg
> 
> EndPoint 1 is conf as 2
> EndPoint 2 is conf as 2
> EndPoint 3 is conf 

Re: What makes USB WiFi so difficult in Linux and may I help out?

[Oleksij Rempel]

Hi,

it is not related to your HW, but may help:
https://github.com/qca/open-ath9k-htc-firmware/wiki/Troubleshooting-and-bug-reporting
https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues

Am 15.09.2017 um 10:48 schrieb Ernst Wegner:
> Dear list!
> 
> I recently suffer from attempts to use some USB WiFi sticks to connect
> to a wireless network using Linux. I tried that with a number of
> distros, but found that there seem to be kind of the same problems all
> the way from Linux 2.6.x to 4.x. Most USB WiFi sticks don't work
> reliably.
> 
> As I am a developer also (and very interested in these things) I would
> be willing to help debugging drivers and possibly fix them. But I
> don't really know where to start searching. So some hints would be
> very welcome.
> 
> Currently I try to get this one here to work:
> 
> Bus 001 Device 006: ID 148f:5370 Ralink Technology, Corp. RT5370
> Wireless Adapter
> 
> I am on Debian 9 with a pretty recent kernel:
> 
> Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
> x86_64 GNU/Linux
> 
> I was able to get this stick to work kind of. Actually, it drops the
> connection every couple of minutes, without any error messages in
> dmesg or syslog, actually. But I was able to reach that state only
> after applying some tweaks like disabling hardware encrypt, i.e.
> 
> options rt2800usb nohwcrypt=y
> 
> and
> 
> [device]
> wifi.scan-rand-mac-address=no
> 
> So any pointers would be welcome.
> 
> I am not afraid to dig into the code of the driver and recompile.
> 
> I could also possibly add or enable some debugging code so I will get
> some more debugging output to see what actually happens when I loose
> the connection, i.e. if this is an external event, a special kind of
> package, overload, ...
> 
> And finally: This isn't the only USB Wifi stick which has serious
> problems with Linux. The Internet is full of this including drivers
> for some sticks which don't work at all and don't go anywhere for
> month. Obviously it's not the sticks to blame, as they all work fine
> on Windows. So what's the underlying story here which I am missing?
> 
> Regards,
> Torsten
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: atheros ath9k_htc - EP4 Issue / BOGUS urb xfer, pipe 1 != type 3

[Oleksij Rempel]

Am 27.08.2017 um 01:31 schrieb M D:
> Hi,
> I am using the TPLink TL721N on an ARM MX21 platform, Linux Kernel 3.0

are there any reason to use such old kernel?

> I am facing the following issue when the adapter is connected directly
> to the USB Hub.
> 
> 1) ifconfig -a does not show the wlan node
> 2) the adapter is detected on the USB bus
> 3) The ath9k_htc modules are loaded
> 

...

> AFTER A REBOOT
> Once the above issue occurs, a software reboot renders the adapter not
> to be enumerated/detected on the USB. That is a lsusb does not display
> the model/serial of the adapter.

If repluging help you. You can try to implement USB link reinit after FW
was uploaded. Theoretically it is a proper way to init FW.

I can imagine following scenario:
- USB adabter is starting internal bootloader and inialize some USB Caps
- FW is uploaded with different USB Cups which a re expected by host driver.
- USB Host Controller has idea about changes because USB link should be
reinited to populate them.

To implement this FW should be patched to reset usb line after start and
driver should recognize some how a reseted FW (different USB id or what
ever)
However as I tried to implement it, the result was not the same on
different hosts. In some cases host turned the power off on device reset
and FW was lost, so driver tried to upload it again. May be I did some
thing wrong.


> dmesg log:
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: new full speed USB device number 5 using imx21-hcd
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: device descriptor read/64, error -110
> hub 1-0:1.0: unable to enumerate USB device on port 2
> 
> 
> I referred to the instructions as mentioned here and ensured that
> https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues#bogus-urb-xfer-pipe-1--type-3
> 
> 1) the driver has the patch
> 2) the firmware being used is 1.4
> 
> However the device is being configured in Full Speed mode.
> usb 1-2: new full speed USB device number 2 using imx21-hcd

May be you will need just backport imx21-hcd patches too ;)

> Could someone offer some suggestions if there are some workarounds in
> the software? Is there anything more that I can try out or any areas I
> can investigate to try and fix this issue? I am presently reading
> through the device driver to see if I can fix it there, but am not
> making much progress.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Madwifi porting to Ath9k

[Oleksij Rempel]

Am 24.07.2017 um 08:08 schrieb Arul jothi:
> Hi Oleksij,
> 
>Thanks for your reply. I am new to the linux wireless.
> Does ath9k has support for PCF implementation ? I couldn't find any
> reference about PCF in ath9k.
> 
> Do you mean porting madwifi code to ath9k is straight forward ?.
> Please give some link or guideliness.

- Isolate PCF code in Madwifi
- port it to the ath9k if possible
- do lots of testing
- send patches for review.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Madwifi porting to Ath9k

[Oleksij Rempel]

Am 23.07.2017 um 15:54 schrieb Arul jothi:
> Hi,
> 
>   I have AR7161 based board which is using customized madwifi driver
> with PCF implementation.
> I need to port the driver to new board based on AR9344.
> What should be the approach I should take
> 
> 1.   Build Madwifi with current AR9344 Openwrt build
> 
> 2.   Implement PCF with current Ath9k driver.
> 
> 
> Please advise which approach I should take. Can someone help me with
> some clue on that.
> Thanks in advance.

In long term it is preferable to extend upstream version of the driver
(ath9k) aaand upstream you patches as well.

ath9k has big developer community and good testing coverage.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

[Oleksij Rempel]

Am 08.06.2017 um 00:39 schrieb Tobias Diedrich:
> Oleksij Rempel wrote:
>> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich:
>>> Oleksij Rempel wrote:
>>>> Yes, this is "normal" problem. The firmware has no error handler for PCI
>>>> bus related exceptions. So if we filed to read PCI bus first time, we
>>>> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot
>>>> and provide an kernel "firmware panic!" message.
>>>> Every one who can or will to fix this, is welcome.
>>>>
>>>>> *
>>>>> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic!
>>>>> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038.
>>> [...]
>>>
>>>> memdmp 50ae78 50ae88
>>>
>>> 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940  l...j..@
>>>
>>> [...copy to bin...]
>>> $ bin/objdump -b binary -m xtensa  -D /tmp/memdump.bin 
>>> [..]
>>>0:   6c1004  entry   a1, 32
>>>3:   126aa2  l32ra2, 0xfffdaa8c
>>>6:   0c0200  memw
>>>9:   8820l32i.n  a8, a2, 0  <--Exception cause 
>>> PC still points at load
>>>b:   c020movi.n  a2, 0
>>>d:   081940  extui   a9, a8, 1, 1
>>>
>>> Judging from that it should be fairly simple to at least implement
>>> some sort of retry, possible after triggering a PCIe link retrain?
>>
>> I assume, yes.
>>
>>> There are some related PCIe root complex registers that may point to
>>> what exactly failed if they were dumped.
>>>
>>> The root complex registers live at 0x0004 and I think match the
>>> registers described for the root complex in the AR9344 datasheet.
>>
>> Suddenly I don't have ar7010 docs to tell..
>>
>>> PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR:
>>> "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in
>>> the hierarchy reports any of the following errors and the associated
>>> enable bit is set in the Root Control register: ERR_COR, ERR_FATAL,
>>> ERR_NONFATAL."
>>>
>>> AFAICS link retrain can be done by setting bit3 (INIT_RST,
>>> "Application request to initiate a training reset") in
>>> PCIE_APP (0x4).
>>>
>>> See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which
>>> flips some bits in the RC to enable the PCIe bus for reading the
>>> EEPROM).
>>>
>>> The root complex pci configuration space is at 0x2 which could
>>> have further error details:
>>>> memdmp 2 20200
>>>
>>> 02: a02a 168c 0010 0006  0001 0001   .*..
>>> 020010:          
>>> 020020:          
>>> 020030:    0040    01ff  ...@
>>> 020040: 5bc3 5001        [.P.
>>> 020050: 0080 7005        ..p.
>>> 020060:          
>>> 020070: 0042 0010  8701  2010 0013 4411  .BD.
>>> 020080: 3011    00c0 03c0    0...
>>> 020090:    0010      
>>> 0200a0:          
>>> 0200b0:          
>>> 0200c0:          
>>> 0200d0:          
>>> 0200e0:          
>>> 0200f0:          
>>> 020100: 1401 0001     0006 2030  ...0
>>> 020110:    2000  00a0    
>>> 020120:          
>>> 020130:          
>>> 020140: 0001 0002        
>>> 020150:   8000 00ff      
>>> 020160:          
>>> 020170:          
>>> 020180:          
>>> 02

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

[Oleksij Rempel]

Am 07.06.2017 um 02:12 schrieb Tobias Diedrich:
> Oleksij Rempel wrote:
>> Yes, this is "normal" problem. The firmware has no error handler for PCI
>> bus related exceptions. So if we filed to read PCI bus first time, we
>> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot
>> and provide an kernel "firmware panic!" message.
>> Every one who can or will to fix this, is welcome.
>>
>>> *
>>> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic!
>>> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038.
> [...]
> 
>> memdmp 50ae78 50ae88
> 
> 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940  l...j..@
> 
> [...copy to bin...]
> $ bin/objdump -b binary -m xtensa  -D /tmp/memdump.bin 
> [..]
>0:   6c1004  entry   a1, 32
>3:   126aa2  l32ra2, 0xfffdaa8c
>6:   0c0200  memw
>9:   8820l32i.n  a8, a2, 0  <--Exception cause PC 
> still points at load
>b:   c020movi.n  a2, 0
>d:   081940  extui   a9, a8, 1, 1
> 
> Judging from that it should be fairly simple to at least implement
> some sort of retry, possible after triggering a PCIe link retrain?

I assume, yes.

> There are some related PCIe root complex registers that may point to
> what exactly failed if they were dumped.
> 
> The root complex registers live at 0x0004 and I think match the
> registers described for the root complex in the AR9344 datasheet.

Suddenly I don't have ar7010 docs to tell..

> PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR:
> "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in
> the hierarchy reports any of the following errors and the associated
> enable bit is set in the Root Control register: ERR_COR, ERR_FATAL,
> ERR_NONFATAL."
> 
> AFAICS link retrain can be done by setting bit3 (INIT_RST,
> "Application request to initiate a training reset") in
> PCIE_APP (0x4).
> 
> See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which
> flips some bits in the RC to enable the PCIe bus for reading the
> EEPROM).
> 
> The root complex pci configuration space is at 0x2 which could
> have further error details:
>> memdmp 2 20200
> 
> 02: a02a 168c 0010 0006  0001 0001   .*..
> 020010:          
> 020020:          
> 020030:    0040    01ff  ...@
> 020040: 5bc3 5001        [.P.
> 020050: 0080 7005        ..p.
> 020060:          
> 020070: 0042 0010  8701  2010 0013 4411  .BD.
> 020080: 3011    00c0 03c0    0...
> 020090:    0010      
> 0200a0:          
> 0200b0:          
> 0200c0:          
> 0200d0:          
> 0200e0:          
> 0200f0:          
> 020100: 1401 0001     0006 2030  ...0
> 020110:    2000  00a0    
> 020120:          
> 020130:          
> 020140: 0001 0002        
> 020150:   8000 00ff      
> 020160:          
> 020170:          
> 020180:          
> 020190:          
> 0201a0:          
> 0201b0:          
> 0201c0:          
> 0201d0:          
> 0201e0:          
> 0201f0:          
> 
> Transformed into something suitable for feeding into lspci -F:
> 
> 00:00.0 Description filled in by lspci
> 00: 8c 16 2a a0 06 00 10 00 01 00 00 00 00 00 01 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 0

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

[Oleksij Rempel]

Hi,

Am 03.06.2017 um 00:02 schrieb Nathan Royce:
> ODroid XU4
> 
> $ uname -a
> Linux computer 4.12.0-rc3-dirty #1 SMP Wed May 31 15:02:05 CDT 2017
> armv7l GNU/Linux
> 
> $ lsusb
> ...
> Bus 001 Device 002: ID 2109:2813 VIA Labs, Inc.
> Bus 001 Device 010: ID 0cf3:7015 Qualcomm Atheros Communications
> TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]
> ...
> 
> *
> Jun 02 16:20:11 computer hostapd[14954]: vwlan0: interface state
> COUNTRY_UPDATE->HT_SCAN
> Jun 02 16:20:17 computer hostapd[14954]: 20/40 MHz operation not
> permitted on channel pri=7 sec=3 based on overlapping BSSes
> Jun 02 16:20:18 computer kernel: Division by zero in kernel.
> Jun 02 16:20:18 computer kernel: CPU: 1 PID: 14507 Comm: kworker/u16:2
> Tainted: GW   4.12.0-rc3-dirty #1
> Jun 02 16:20:18 computer kernel: Hardware name: SAMSUNG EXYNOS
> (Flattened Device Tree)
> Jun 02 16:20:18 computer kernel: Workqueue: phy5 ieee80211_scan_work 
> [mac80211]
> Jun 02 16:20:18 computer kernel: [] (unwind_backtrace) from
> [] (show_stack+0x10/0x14)
> Jun 02 16:20:18 computer kernel: [] (show_stack) from
> [] (dump_stack+0x88/0x9c)
> Jun 02 16:20:18 computer kernel: [] (dump_stack) from
> [] (Ldiv0_64+0x8/0x18)
> Jun 02 16:20:18 computer kernel: [] (Ldiv0_64) from
> [] (ath9k_get_next_tbtt+0x58/0x5c [ath9k_common])

Hm... this function and file:
linux/drivers/net/wireless/ath/ath9k/common-beacon.c
didn't changed since 2015. So, it should be some thing different.
Can you run
git bisect to find exact patch caused this regression?

> Jun 02 16:20:18 computer kernel: [] (ath9k_get_next_tbtt
> [ath9k_common]) from [] (ath9k_cmn_beacon_config
> Jun 02 16:20:18 computer kernel: []
> (ath9k_cmn_beacon_config_ap [ath9k_common]) from []
> (ath9k_htc_beacon
> Jun 02 16:20:18 computer kernel: []
> (ath9k_htc_beacon_config_ap [ath9k_htc]) from []
> (ath9k_htc_vif_recon
> Jun 02 16:20:18 computer kernel: [] (ath9k_htc_vif_reconfig
> [ath9k_htc]) from [] (ath9k_htc_sw_scan_compl
> Jun 02 16:20:18 computer kernel: []
> (ath9k_htc_sw_scan_complete [ath9k_htc]) from []
> (__ieee80211_scan_co
> Jun 02 16:20:18 computer kernel: []
> (__ieee80211_scan_completed [mac80211]) from []
> (ieee80211_scan_work+
> Jun 02 16:20:18 computer kernel: [] (ieee80211_scan_work
> [mac80211]) from [] (process_one_work+0x1d8/0x40
> Jun 02 16:20:18 computer kernel: [] (process_one_work) from
> [] (worker_thread+0x4c/0x564)
> Jun 02 16:20:18 computer kernel: [] (worker_thread) from
> [] (kthread+0x14c/0x154)
> Jun 02 16:20:18 computer kernel: [] (kthread) from
> [] (ret_from_fork+0x14/0x3c)
> Jun 02 16:20:18 computer hostapd[14954]: Using interface wlan0 with
> hwaddr  and ssid ""
> Jun 02 16:20:18 computer kernel: IPv6: ADDRCONF(NETDEV_CHANGE):
> vwlan0: link becomes ready
> *
> This is a new one on me.
> 
> The "normal" problem (search shows to be a very old issue) I
> consistently (daily or multiple times/day) encounter is:

Yes, this is "normal" problem. The firmware has no error handler for PCI
bus related exceptions. So if we filed to read PCI bus first time, we
have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot
and provide an kernel "firmware panic!" message.
Every one who can or will to fix this, is welcome.

> *
> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic!
> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038.
> Jun 02 14:55:30 computer kernel: usb 1-1.1: USB disconnect, device number 9
> Jun 02 14:55:30 computer systemd-networkd[11959]: vwlan0: Lost carrier
> Jun 02 14:55:30 computer kernel: br0: port 2(vwlan0) entered disabled state
> Jun 02 14:55:30 computer kernel: wlan0: deauthenticating from
>  by local choice (Reason: 3=DEAUTH_LEAVING)
> Jun 02 14:55:30 computer kernel: ath: phy4: Failed to wakeup in 500us
> Jun 02 14:55:30 computer kernel: ath: phy4: Failed to wakeup in 500us
> Jun 02 14:55:30 computer kernel: ath: phy4: Failed to wakeup in 500us
> Jun 02 14:55:30 computer kernel: ath: phy4: Failed to wakeup in 500us
> Jun 02 14:55:30 computer systemd-networkd[11959]: wlan0: Lost carrier
> Jun 02 14:55:30 computer systemd[1]: Stopping A simple WPA encrypted
> wireless connection using a static IP...
> -- Subject: Unit netctl@wlan0.service has begun shutting down
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit netctl@wlan0.service has begun shutting down.
> Jun 02 14:55:30 computer kernel: device vwlan0 left promiscuous mode
> Jun 02 14:55:30 computer kernel: br0: port 2(vwlan0) entered disabled state
> Jun 02 14:55:30 computer audit: ANOM_PROMISCUOUS dev=vwlan0 prom=0
> old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295
> Jun 02 14:55:30 computer hostapd[13218]: vwlan0: AP-STA-DISCONNECTED 
> 
> Jun 02 14:55:30 computer hostapd[13218]: Failed to set beacon parameters
> Jun 02 14:55:30 computer hostapd[13218]: vwlan0: INTERFACE-DISABLED
> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath9k_htc: USB layer 

Search for devices with Xtensa cores

[Oleksij Rempel]

Hallo all,

short version:
I'm looking for devices which use Xtensa and GCC/binutils patches used
to provide support for this devices.

long version:
this year started with inclusion of open-ath9k-htc-firmware to debian
*main* repository. As first we started to getting advantage of regular
compile tests. See results here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/open-ath9k-htc-firmware.html

Most of the problems which we currently get, are related to gcc xtensa
compiler.
In details: device specific patch set is used to provide our own
gcc/binutils version because Xtensa don't really have defined CPU cores.
As result, upstream compiler developers will never notice if some thing
will brake this patch set.

My hope is to provide upstream gcc support for commonly used by linux
community Xtensa cores.

So far i know about:
- Atheros ar9271 is identical with ar7010, LX2.1.0
- Atheros AR6002 Xtensa LX??
- Atheros AR6003 Xtensa LX??
- Atheros AR6103 Xtensa LX??
- Espressif ESP8266 Xtensa LX106

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Hostapd driver issues in orange pi Zero

[Oleksij Rempel]

Hi

Am 05.03.2017 um 08:38 schrieb ravin goyal:
> Hi all,
> 
> I am running hostapd 2.5 on orange pi zero running debian jessie and
> my wireless driver is xradio_wlan.

if i see it correctly, your wifi controller is Allwiner XR819. It looks
like SDIO device with own ram and firmware loaded to it. I don't have
specs for it, but i assume there is not enough RAM to work with more
then 9 devices.

> First it was running fine when I was testing without bridge settings
> in hostapd.conf.
> 
> But when I set bridge=br0 in  hostapd.conf and restart the process, as
> the number of STA's are getting connected to the hostapd access point.
> 
> I noticed driver error allover in syslog and dmesg, I am sharing few
> logs from dmesg as below:
> 
> [Sun Mar  5 07:46:46 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 07:46:52 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:47:48 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:48:16 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 07:49:56 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:51:14 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 07:51:57 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:52:07 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:52:14 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:52:18 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 07:53:30 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:56:09 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 07:59:00 2017] [BH_WRN] miss interrupt!
> [Sun Mar  5 08:00:00 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 08:00:38 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:01:16 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:01:48 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 08:02:21 2017] [STA_WRN] Inactivity Event Recieved for link_id 1
> [Sun Mar  5 08:02:21 2017] [STA_WRN]  Inactivity Deauth Frame sent for
> MAC SA 88:79:7e:13:5e:ce  and DA dc:44:6d:6b:43:18
> [Sun Mar  5 08:02:31 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 08:03:09 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:03:56 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:04:52 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:04:54 2017] [STA_WRN] Inactivity Event Recieved for link_id 3
> [Sun Mar  5 08:04:54 2017] [STA_WRN]  Inactivity Deauth Frame sent for
> MAC SA 88:79:7e:13:5e:ce  and DA dc:44:6d:6b:43:18
> [Sun Mar  5 08:04:59 2017] [AP_WRN] Multicast delivery timeout.
> [Sun Mar  5 08:05:44 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:06:50 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:07:11 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:07:26 2017] [BH_WRN] miss interrupt!
> [Sun Mar  5 08:08:02 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:08:16 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:08:48 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:10:04 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:10:26 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:11:22 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:12:31 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:17:18 2017] [BH_WRN] miss interrupt!
> [Sun Mar  5 08:18:52 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:21:28 2017] [STA_WRN] Inactivity Event Recieved for link_id 4
> [Sun Mar  5 08:21:28 2017] [STA_WRN]  Inactivity Deauth Frame sent for
> MAC SA 88:79:7e:13:5e:ce  and DA dc:44:6d:6b:43:18
> [Sun Mar  5 08:22:30 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:23:22 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:24:00 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:24:14 2017] [WSM_ERR] wsm_flush_tx:No pengding, but
> hw_bufs_used=1
> [Sun Mar  5 08:24:23 2017] [BH_WRN] miss interrupt!
> 
> Internet is working fine on the connected devices but these errors are
> keep coming in syslog which are hard to ignore.
> Any idea about this ?
> 
> Moreover One more thing I noticed is that I can connect atmost 9-10
> clients( I get to know this by running hostapd_cli all_sta) afterwards
> it just keeps showing status connecting... when a new clients try to
> connect until unless one or more clients that are already connected
> gets disconnected.
> I even has set 

Re: Question: Packet drop criterion

[Oleksij Rempel]

Am 22.12.2016 um 13:34 schrieb Ferran Quer i Guerrero:
> Hello everyone,
> 
> I would like to modify the retry threshold for dropping a packet using
> mesh mode. I tried with iw
> 
> iw phy  set retry [short ] [long ]
> 
> with short and long limits equal to 10 first and later 5, but I couldn't
> tell any effect. I'm checking by adding a printk in `status.c` and
> manually shutting down (ifdown) the mesh-peered interface to cause
> packet retries. It turns out that the tx report only appears when
> `retry_count` is 28 (after many continued drops, it also appears at 23,
> 24, 25 or retries). 
> 
> void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
> {
> /* ... */
> if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> ieee80211_handle_filtered_frame(local, sta, skb);
> rcu_read_unlock();
> return;
> } else {
> if (!acked)
> sta->tx_retry_failed++;
> sta->tx_retry_count += retry_count;
> /* Dirty debugging */
> printk("Packet dropped. Retry count: %d",
> retry_count);
> }
> 
> rate_control_tx_status(local, sband, sta, skb);
> if (ieee80211_vif_is_mesh(>sdata->vif))
> ieee80211s_update_metric(local, sta, skb);
> /* ... */
> }
> 
> I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
> mesh point mode.

are you talking about usb dongles? If yes, then it is not ath9k


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ath9k_htc: don't use HZ for usb msg timeouts

[Oleksij Rempel]

Am 29.11.2016 um 10:45 schrieb Anthony Romano:
> Hi Oleksij,
> 
> I put 4 ar9271's on a 4 port hub into monitor mode for you and all
> interfaces are simultaneously collecting packets. My cheap USB power
> meter reads 4.37v@650mA between the hub and the host, so it's pushing
> the limit but appears stable.

Great work, thank you!

> On Mon, Nov 28, 2016 at 7:34 AM, Oleksij Rempel <fis...@gmx.net> wrote:
>> Hi Anthony,
>>
>> Am 28.11.2016 um 05:27 schrieb Anthony Romano:
>>> The usb_*_msg() functions expect a timeout in msecs but are given HZ,
>>> which is ticks per second. If HZ=100, firmware download often times out
>>> when there is modest USB utilization and the device fails to initialize.
>>
>>> Replaces HZ in usb_*_msg timeouts with 1000 msec since HZ is one second
>>> for timeouts in jiffies.
>>
>> wow..
>> This fix allow you use 4 adapter at same time?
>>> Signed-off-by: Anthony Romano <anthony.ro...@coreos.com>

Acked-by: Oleksij Rempel <li...@rempel-privat.de>



-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device

[Oleksij Rempel]

Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:
> On 11/28/2016 08:33 PM, Oleksij Rempel wrote:
>> Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:
>>> Am 28.11.2016 um 17:34 schrieb Kyle McMartin:
>>>> On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
>>>> <igor.mitsyanko...@quantenna.com> wrote:
>>>>> Hi Ben, Kyle,
>>>>> could you please share what is the position of linux-firmware
>>>>> regarding
>>>>> firmware binaries that include GPL components? Does it require
>>>>> entire GPL
>>>>> components codebase be present in linux-firmware tree, or maybe
>>>>> having this
>>>>> clause in license file is enough:
>>>>> +Open Source Software. The Software may include components that are
>>>>> licensed
>>>>> +pursuant to open source software (“Open Source Components”).
>>>>> Information
>>>>> +regarding the Open Source Components included with the Software is
>>>>> available
>>>>> +upon request to osle...@quantenna.com. To the extent such Open Source
>>>>> +Components are required to be licensed to you under the terms of a
>>>>> separate
>>>>> +license (such as an open source license) then such other terms
>>>>> shall apply,
>>>>> and
>>>>> +nothing herein shall be deemed or interpreted to limit any rights
>>>>> you may
>>>>> have
>>>>> +under any such applicable license.
>>>>>
>>>>>  From technical perspective, size of the codebase used to build
>>>>> Quantenna
>>>>> firmware is a few hundred MBs, it seems too much to include into
>>>>> linux-firmware tree.
>>>>>
>>>> I don't have strong feelings one way or another. I'd prefer not having
>>>> several hundred
>>>> MB of source that's unlikely to change included in the linux-firmware
>>>> git tree. I'm also not
>>>> a lawyer, so I can't help you decide what would satisfy the
>>>> distribution clause of the GPLv2.
>>>> We already have one GPL firmware (carl9170fw) which includes the
>>>> source, but just references
>>>> a seperate toolchain for downloading, so it's only approximately 1MB
>>>> in size in the tree.
>>>>
>>>> Is your firmware source really that large, or is it just including the
>>>> entire build toolchain with it?
>>>>
>>>> regards,
>>>> --Kyle
>>> We also have open BSD licensed open-ath9k-htc-firmware. Which is locate
>>> out of source too.
>>> https://github.com/qca/open-ath9k-htc-firmware
>>> and here is location of carl firmware:
>>> https://github.com/chunkeey/carl9170fw
>>>
>>> So, what is actual problem with Quantenna QSR10G FW?
>>> I would be really interesting to take a look on it. Is it somewhere
>>> available? Are there some devices to get hand on?
>> After seeing specs of this device i have strong feeling that "some open
>> source part" is actual linux kernel.
>>
>>
> Oleksij, yes, that's correct, it includes entire Linux environment; the
> reasoning is that it allows to hide all WiFi-related logic inside device
> itself, and emulate simple Ethernet device for external system
> (therefore, freeing external system resources).
> 
> This approach was working really well for us until recently, but now
> that company is expanding, we want to have more flexible and standardize
> interface available for external system to manage wireless connection,
> and FullMAC driver seems to be the best solution here.

you mean, this driver will not use mac80211 framework provided by kernel?

> For the availability of FW sources, QSR10G-based products are still
> under development at this moment (not in the market yet), but many
> products based on previous generation chipset QSR1000 are available. For
> example, Asus has a retail design with QSR1000 chipset, and has all GPL
> sourcecode available on their website (including what Quantenna has
> provided):
> 
> http://www.asus.com/Networking/RTAC87U/HelpDesk_Download/
> Quantenna provided code is in, for example, "GPL of ASUS RT-AC87U for
> firmware 3.0.0.4.378.7410" archive.
> It's basically the same as used for QSR10G.

Will Quantenna provide documentation for at least old chipsats? Playing
fair with OSS developer community has some advantages :)


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device

[Oleksij Rempel]

Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:
> Am 28.11.2016 um 17:34 schrieb Kyle McMartin:
>> On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
>> <igor.mitsyanko...@quantenna.com> wrote:
>>> Hi Ben, Kyle,
>>> could you please share what is the position of linux-firmware regarding
>>> firmware binaries that include GPL components? Does it require entire GPL
>>> components codebase be present in linux-firmware tree, or maybe having this
>>> clause in license file is enough:
>>> +Open Source Software. The Software may include components that are licensed
>>> +pursuant to open source software (“Open Source Components”). Information
>>> +regarding the Open Source Components included with the Software is
>>> available
>>> +upon request to osle...@quantenna.com. To the extent such Open Source
>>> +Components are required to be licensed to you under the terms of a separate
>>> +license (such as an open source license) then such other terms shall apply,
>>> and
>>> +nothing herein shall be deemed or interpreted to limit any rights you may
>>> have
>>> +under any such applicable license.
>>>
>>> From technical perspective, size of the codebase used to build Quantenna
>>> firmware is a few hundred MBs, it seems too much to include into
>>> linux-firmware tree.
>>>
>>
>> I don't have strong feelings one way or another. I'd prefer not having
>> several hundred
>> MB of source that's unlikely to change included in the linux-firmware
>> git tree. I'm also not
>> a lawyer, so I can't help you decide what would satisfy the
>> distribution clause of the GPLv2.
>> We already have one GPL firmware (carl9170fw) which includes the
>> source, but just references
>> a seperate toolchain for downloading, so it's only approximately 1MB
>> in size in the tree.
>>
>> Is your firmware source really that large, or is it just including the
>> entire build toolchain with it?
>>
>> regards,
>> --Kyle
> 
> We also have open BSD licensed open-ath9k-htc-firmware. Which is locate
> out of source too.
> https://github.com/qca/open-ath9k-htc-firmware
> and here is location of carl firmware:
> https://github.com/chunkeey/carl9170fw
> 
> So, what is actual problem with Quantenna QSR10G FW?
> I would be really interesting to take a look on it. Is it somewhere
> available? Are there some devices to get hand on?

After seeing specs of this device i have strong feeling that "some open
source part" is actual linux kernel.


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device

[Oleksij Rempel]

Am 28.11.2016 um 17:34 schrieb Kyle McMartin:
> On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
>  wrote:
>> Hi Ben, Kyle,
>> could you please share what is the position of linux-firmware regarding
>> firmware binaries that include GPL components? Does it require entire GPL
>> components codebase be present in linux-firmware tree, or maybe having this
>> clause in license file is enough:
>> +Open Source Software. The Software may include components that are licensed
>> +pursuant to open source software (“Open Source Components”). Information
>> +regarding the Open Source Components included with the Software is
>> available
>> +upon request to osle...@quantenna.com. To the extent such Open Source
>> +Components are required to be licensed to you under the terms of a separate
>> +license (such as an open source license) then such other terms shall apply,
>> and
>> +nothing herein shall be deemed or interpreted to limit any rights you may
>> have
>> +under any such applicable license.
>>
>> From technical perspective, size of the codebase used to build Quantenna
>> firmware is a few hundred MBs, it seems too much to include into
>> linux-firmware tree.
>>
> 
> I don't have strong feelings one way or another. I'd prefer not having
> several hundred
> MB of source that's unlikely to change included in the linux-firmware
> git tree. I'm also not
> a lawyer, so I can't help you decide what would satisfy the
> distribution clause of the GPLv2.
> We already have one GPL firmware (carl9170fw) which includes the
> source, but just references
> a seperate toolchain for downloading, so it's only approximately 1MB
> in size in the tree.
> 
> Is your firmware source really that large, or is it just including the
> entire build toolchain with it?
> 
> regards,
> --Kyle

We also have open BSD licensed open-ath9k-htc-firmware. Which is locate
out of source too.
https://github.com/qca/open-ath9k-htc-firmware
and here is location of carl firmware:
https://github.com/chunkeey/carl9170fw

So, what is actual problem with Quantenna QSR10G FW?
I would be really interesting to take a look on it. Is it somewhere
available? Are there some devices to get hand on?

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

open-ath9k-htc-firmware as DFSG debian package

[Oleksij Rempel]

Hallo all,

finally we managed to provide debian package for main repository:

https://ftp-master.debian.org/new/open-ath9k-htc-firmware_1.4.0-81-gf206e56+dfsg-1.html

- It is made according Debian Free Software Guideline
- providing debug and source packages
- can be build just in the repository

Have fun by using it :)
Thank to all who helped to make this happening :D

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

Am 22.09.2016 um 05:34 schrieb bruce m beach:
>> We recently updated FW to GCC 6.2 which can detect more problems. So it
>> will be probably interesting for you to pick this patch out.
> 
> Yes I saw the message by Adrian Chadd and tried tried to git clone the link
> he gave but that clearly wasn't what was to be done. Is there a patch that I
> need to apply to the firmware? I do have a local copy.
> 

this patches are now in main repository.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

wifi test automation?

[Oleksij Rempel]

Hallo all,

What kind of WiFi testomation are you using?

Right now i found some links, do some of this used by WiFi devs?
http://avocado-framework.github.io/
https://autotest.github.io/
https://github.com/Wi-FiTestSuite
https://wireless.wiki.kernel.org/en/developers/testing/wifi-test

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

Am 21.09.2016 um 05:43 schrieb bruce m beach:
> Oleksij
> 
> I looked at
> https://unix.stackexchange.com/questions/122050/
>   send-traffic-to-self-over-physical-network-on-ubuntu
> 
> It appearred to too complicated but
> 
> https://unix.stackexchange.com/questions/122050/
> send-traffic-to-self-over-physical-network-on-ubuntu
> with:
> # Create a network namespace and move one of interfaces into it:
>   ip netns add test2
>   ip link set wlan0 netns test2
> # Start a shell in the new namespace:
>ip netns exec test2 bash
> # Then proceed as if you had two machines. When finished exit the shell 
> and
> # delete the namespace:
>ip netns del test2
> Certainly looks interesting but after I got a
>  RTNETLINK answers: Invalid argument
> I lost interest. My heart isn't in it. I'm still working on the firmware.  I
> have started a new tree (tree #3) that consists of a userland firmware 
> uploader
> and until recently the following firmware:
> 
> app_start( void ) {}
> 
> i.e a lable that the code jumps to and nothing else. At this point I have
> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
> since it is available a boot, no matter what) and over the next few
> months I am going to move ->all<- the rom code into ram starting with
> the USB subsystem.
> 
> Bruce
> 


Wow, this sounds interesting :)
We recently updated FW to GCC 6.2 which can detect more problems. So it
will be probably interesting for you to pick this patch out.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

Am 17.09.2016 um 18:14 schrieb Oleksij Rempel:
> Am 17.09.2016 um 17:52 schrieb bruce m beach:
>>>> Hm.. found here one report about bad perfomance on this driver
>>>> https://ubuntuforums.org/showthread.php?t=2312343
>>>>
>>>> affected persons seems to use WEP encryption.
>>>>
>>>> What encryption do are you using?
>>
>> I just wish I could do some testing on a single machine. Every test
>> suite I've seen always involves 2 machines. Why can't I use the wifi
>> chip on the mother board and the ar9271(a usb stick) to test basic
>> communications on the ar9271. The problem is I don't know where to begin.
>>
>> Bruce
>>
> 
> i didn't tried it myself:
> https://unix.stackexchange.com/questions/122050/send-traffic-to-self-over-physical-network-on-ubuntu
> 
> but last suggestion looks interesting.
> 

or this:
https://www.spinics.net/lists/netdev/msg152621.html

please share if you get it work :D

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

Am 17.09.2016 um 17:52 schrieb bruce m beach:
>>> Hm.. found here one report about bad perfomance on this driver
>>> https://ubuntuforums.org/showthread.php?t=2312343
>>>
>>> affected persons seems to use WEP encryption.
>>>
>>> What encryption do are you using?
> 
> I just wish I could do some testing on a single machine. Every test
> suite I've seen always involves 2 machines. Why can't I use the wifi
> chip on the mother board and the ar9271(a usb stick) to test basic
> communications on the ar9271. The problem is I don't know where to begin.
> 
> Bruce
> 

i didn't tried it myself:
https://unix.stackexchange.com/questions/122050/send-traffic-to-self-over-physical-network-on-ubuntu

but last suggestion looks interesting.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding

[Oleksij Rempel]

Am 09.09.2016 um 22:57 schrieb Martin Blumenstingl:
> On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel <li...@rempel-privat.de> wrote:
>>> +Optional properties:
>>> +- reg: Address and length of the register set for the device.
>>> +- qca,clk-25mhz: Defines that a 25MHz clock is used
>>
>> Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
>> case we need to use clock framework any way, so why not in this case too?
>> Provide dummy static clock in DT and connect it with this node?
>>
>> osc25m: oscillator {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> clock-frequency = <2500>;
>> clock-accuracy = <3>;
>> };
>>
>> acc: clock-controller@8004 {
>> compatible = "some-clock-controller";
>> #clock-cells = <1>;
>> clocks = <>;
>> reg = <0x8004 0x204>;
>> };
>>
>>
>>  {
>> ath9k@168c,002d {
>> compatible = "pci168c,002d";
>> reg = <0x7000 0 0 0 0x1000>;
>> clocks = <>;
>> qca,disable-5ghz;
>> };
>> };
>>
>>
>> driver will need to use clk_get and compare frequency instead of
>> of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
>> to define source clock only one time and reuse it by all affected DT
>> nodes. If we have 40MHz clock you will only need to change it in
>> fixed-clock.
> that does sound like a good idea, thanks for that input!
> However, I will remove the property for the first version because I am
> trying to get PCI(e) devices supported. OF support for AHB (WiSoC)
> needs more work (in other places, like ahb.c) anyways.
> But this suggestion should be remembered!
> 
>>> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to 
>>> the
>>> + ath9k wireless chip (in this case the calibration /
>>> + EEPROM data will be loaded from userspace using the
>>> + kernel firmware loader).
>>> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
>>> + 2.4GHz band. Setting this property is only needed
>>> + when the RF circuit does not support the 2.4GHz band
>>> + while it is enabled nevertheless in the EEPROM.
>>> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
>>> + 5GHz band. Setting this property is only needed when
>>> + the RF circuit does not support the 5GHz band while
>>> + it is enabled nevertheless in the EEPROM.
>>
>> This option can be reused for every WiFi controller. Not only for qca.
>> So may be instead of adding vendor specific name, make it reusable for
>> all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
>> disable-5ghz and disable-2ghz?
> I am personally fine with anything that fits best into the grand
> scheme of things.
> There are three scenarios I can think of which may be influenced by
> devicetree configuration:
> a) let the driver decide automatically whether the 2.4GHz and/or 5GHz
> band is/are enabled
> b) explicitly disable either bands (because the driver thinks due to
> whatever reason that a band is supported while in reality it isn't)
> c) explicitly enable a band (for example because the driver cannot
> automagically detect which band should be enabled)
> 
> for ath9k we default to a) but also allow b): the EEPROM (device
> specific calibration data) contains information about which bands are
> enabled (or not). But some manufacturers are shipping devices for
> example with the 5G band enabled, while the actual hardware doesn't
> support it.
> 
> Felix' mt76 driver for example defaults to case a) but allows
> overriding (= forcefully enabling or disabling) a specific band.
> 
> If we decide how this should look like in the devicetree then I can go
> ahead and implement it accordingly.

To avoid possible conflict with other device-tree bindings i would
suggest this kind of naming:
ieee80211-5ghz-enalbe
ieee80211-5ghz-disable
ieee80211-2.4ghz-enalbe
ieee80211-2.4ghz-disable

i assume at some point we would get even more eeprom overrides. For
example disable/enable some modulation and so on.

we would need 80211 specific functions to read this overrides from
device-tree and/or acpi.

any feedback from DT maintainers?
-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding

[Oleksij Rempel]

Hallo all,

if it is not too late i would add my two cents :)


Am 06.09.2016 um 23:46 schrieb Martin Blumenstingl:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 000..77b9202
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,39 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: For PCI and PCIe devices this should be an identifier following
> + the format as defined in "PCI Bus Binding to Open Firmware"
> + Revision 2.1. One of the possible formats is "pci,"
> + where  is the PCI vendor ID and  is PCI device ID.
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
> +- qca,clk-25mhz: Defines that a 25MHz clock is used

Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
case we need to use clock framework any way, so why not in this case too?
Provide dummy static clock in DT and connect it with this node?

osc25m: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2500>;
clock-accuracy = <3>;
};

acc: clock-controller@8004 {
compatible = "some-clock-controller";
#clock-cells = <1>;
clocks = <>;
reg = <0x8004 0x204>;
};


 {
ath9k@168c,002d {
compatible = "pci168c,002d";
reg = <0x7000 0 0 0 0x1000>;
clocks = <>;
qca,disable-5ghz;
};
};


driver will need to use clk_get and compare frequency instead of
of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
to define source clock only one time and reuse it by all affected DT
nodes. If we have 40MHz clock you will only need to change it in
fixed-clock.


> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
> + ath9k wireless chip (in this case the calibration /
> + EEPROM data will be loaded from userspace using the
> + kernel firmware loader).
> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
> + 2.4GHz band. Setting this property is only needed
> + when the RF circuit does not support the 2.4GHz band
> + while it is enabled nevertheless in the EEPROM.
> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
> + 5GHz band. Setting this property is only needed when
> + the RF circuit does not support the 5GHz band while
> + it is enabled nevertheless in the EEPROM.

This option can be reused for every WiFi controller. Not only for qca.
So may be instead of adding vendor specific name, make it reusable for
all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
disable-5ghz and disable-2ghz?


> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +
> +
> +In this example, the node is defined as child node of the PCI controller:
> + {
> + ath9k@168c,002d {
> + compatible = "pci168c,002d";
> + reg = <0x7000 0 0 0 0x1000>;
> + qca,disable-5ghz;
> + };
> +};
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 3/3] ath9k: parse the device configuration from an OF node

[Oleksij Rempel]

Am 10.07.2016 um 02:19 schrieb Bjørn Mork:
> Martin Blumenstingl  writes:
> 
>> +if (of_property_read_bool(np, "qca,clk-25mhz"))
>> +ah->is_clk_25mhz = true;
>> +
>> +if (of_property_read_bool(np, "qca,disable-2ghz"))
>> +ah->disable_2ghz = true;
>> +
>> +if (of_property_read_bool(np, "qca,disable-5ghz"))
>> +ah->disable_5ghz = true;
> 
> This is bike-shedding, but how about
> 
>   ah->is_clk_25mhz = of_property_read_bool(np, "qca,clk-25mhz");
>   ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
>   ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");
> 
> instead?

Hm... i assume each WiFi hw in the world can reuse this settings, may be
it i worth to use generic names?

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k-htc on OHCI -> bogus usb xfer

[Oleksij Rempel]

Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> Hi Oleksij,
> 
> On Tue, 2016-07-05 at 19:23 +0200, Oleksij Rempel wrote:
>> Hi,
>>
>> Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
>>>
>>> Hello,
>>>
>>> Looks like this is another manifestation of already seen problem with 
>>> ath9k-htc
>>> and OHCI controller.
>>>
>>> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
>>> development board (this is Synopsys AXS103) and seeing a picture very 
>>> similar to
>>> what was discussed here 
>>> http://thread.gmane.org/gmane.linux.usb.general/110847
>>>
>>> Below is what I see on insertion of the dongle.
>>> Note I have the most recent ath9k-htc firmware (see 
>>> "ath9k_htc/htc_9271-1.4.0.fw"
>>> in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but 
>>> the same
>>> happens even on 4.4.
>>>
>>> Interesting enough if I simply remove or disable the warning like that
>>> >8---
>>> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
>>> index 3d27477..a317e1e 100644
>>> --- a/drivers/usb/core/urb.c
>>> +++ b/drivers/usb/core/urb.c
>>> @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>>>  * cause problems in HCDs if they get it wrong.
>>>  */
>>>  
>>> -   /* Check that the pipe's type matches the endpoint's type */
>>> -   if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
>>> -   dev_WARN(>dev, "BOGUS urb xfer, pipe %x != type %x\n",
>>> -   usb_pipetype(urb->pipe), pipetypes[xfertype]);
>>> -
>>> /* Check against a simple/standard policy */
>>> allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | 
>>> URB_DIR_MASK |
>>> URB_FREE_BUFFER);
>>> >8---
>>> everything seem to work quite nice.
>>>
>>> Any thoughts are much appreciated.
>>>
>>> That's the log itself:
>>> >8---
>>> usb 1-1: new full-speed USB device number 2 using ohci-platform
>>> usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
>>> usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
>>> usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d1 ]---
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
>>> usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d2 ]---
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
>>> usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d3 ]---
>>>
>>
>> please send content of hif_usb_send_regout() from your source code.
>> It is located in drivers/net/wireless/ath/ath9k/hif_usb.c
> 
> I use vanilla 4.6.3 tree so that's what I have is the same as
> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif_usb.c?h=linu
> x-4.6.y#n99

Interesting.
Can you please send lsusb -v for this adapter? and it will be
interesting to see, which usb endpoint was actualy used.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k-htc on OHCI -> bogus usb xfer

[Oleksij Rempel]

Hi,

Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
> Hello,
> 
> Looks like this is another manifestation of already seen problem with 
> ath9k-htc
> and OHCI controller.
> 
> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
> development board (this is Synopsys AXS103) and seeing a picture very similar 
> to
> what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
> 
> Below is what I see on insertion of the dongle.
> Note I have the most recent ath9k-htc firmware (see 
> "ath9k_htc/htc_9271-1.4.0.fw"
> in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but 
> the same
> happens even on 4.4.
> 
> Interesting enough if I simply remove or disable the warning like that
> >8---
> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> index 3d27477..a317e1e 100644
> --- a/drivers/usb/core/urb.c
> +++ b/drivers/usb/core/urb.c
> @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>  * cause problems in HCDs if they get it wrong.
>  */
>  
> -   /* Check that the pipe's type matches the endpoint's type */
> -   if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
> -   dev_WARN(>dev, "BOGUS urb xfer, pipe %x != type %x\n",
> -   usb_pipetype(urb->pipe), pipetypes[xfertype]);
> -
> /* Check against a simple/standard policy */
> allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
> URB_FREE_BUFFER);
> >8---
> everything seem to work quite nice.
> 
> Any thoughts are much appreciated.
> 
> That's the log itself:
> >8---
> usb 1-1: new full-speed USB device number 2 using ohci-platform
> usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
> usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
> [ cut here ]
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
> usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
> Workqueue: events request_firmware_work_func
> 
> Stack Trace:
>   arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d1 ]---
> [ cut here ]
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
> usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
> Workqueue: events request_firmware_work_func
> 
> Stack Trace:
>   arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d2 ]---
> [ cut here ]
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
> usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
> Workqueue: events request_firmware_work_func
> 
> Stack Trace:
>   arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d3 ]---
> 


please send content of hif_usb_send_regout() from your source code.
It is located in drivers/net/wireless/ath/ath9k/hif_usb.c


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc firmware

[Oleksij Rempel]

Am 04.06.2016 um 21:44 schrieb bruce m beach:
>>> I'm looking for some kind of simple request in the ath9k_htc driver, through
>>> the usb ep0, like a memory read on the card, where a urb is sent with
>>> the resulting chain of events. The simpler the better. The simplest.
> 
>> For EP0 on drivers site:
>> static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
>> {
>> int transfer, err;
>> const void *data = hif_dev->fw_data;
>> size_t len = hif_dev->fw_size;
>> u32 addr = AR9271_FIRMWARE;
>> u8 *buf = kzalloc(4096, GFP_KERNEL);
>> u32 firm_offset;
>> ...
> 
>   What about the code for setting and resetting leds ???
> 
> Bruce

It is EP3/EP4 and it is not working without firmware.
Here is one example how you can add new command to firmware:
https://github.com/olerem/open-ath9k-htc-firmware/commit/c73c159303e30a28e2d3dc05ba0d2d15504e5fad


And for kernel driver:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8badb50cfab6d433622dbfd5a90b6adf27333107


PS: Grr... today i send message from wrong email. Sorry for the spam



-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Fwd: Re: ath9k_htc firmware

[Oleksij Rempel]

Am 03.06.2016 um 19:26 schrieb bruce m beach:
> Hello All
> 
>  I am still working on cleaning up ath9k_htc firmware build tree for about 6
> months now ( and looks like I'll be doing this for all eternity**2 ) and am
> not clear myself what I'm looking for right now.
> 
> I'm looking for some kind of simple request in the ath9k_htc driver, through
> the usb ep0, like a memory read on the card, where a urb is sent with
> the resulting chain of events. The simpler the better. The simplest.

For EP0 on drivers site:
static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
{
int transfer, err;
const void *data = hif_dev->fw_data;
size_t len = hif_dev->fw_size;
u32 addr = AR9271_FIRMWARE;
u8 *buf = kzalloc(4096, GFP_KERNEL);
u32 firm_offset;

if (!buf)
return -ENOMEM;

while (len) {
transfer = min_t(size_t, len, 4096);
memcpy(buf, data, transfer);

err = usb_control_msg(hif_dev->udev,
  usb_sndctrlpipe(hif_dev->udev, 0),
  FIRMWARE_DOWNLOAD, 0x40 | USB_DIR_OUT,
  addr >> 8, 0, buf, transfer, HZ);

=



On side of pre installed firmware, the code looks like this:
open-ath9k-htc-firmware/sboot/magpie_1_1/sboot/hif/usb/src/usb_api.c
LOCAL void VendorCommand(void)
{
#define cUSB_REQ_DOWNLOAD  0x30
#define cUSB_REQ_DOWNLOAD_COMP 0x31
#define cUSB_REQ_BOOT  0x32
#define cUSB_REQ_RESERVED_10x33
#define cUSB_REQ_RESERVED_20x34

#define cUSB_REQ_FLASH_READ0x35
#define cUSB_REQ_FLASH_READ_COMP   0x36

//#define ZM_FIRMWARE_ADDR   0x20

void (*funcPtr)(void);
uint16_t *text_addr = 0;
uint32_t ep0_data = 0x0;
...







signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc firmware

[Oleksij Rempel]

Am 03.06.2016 um 19:26 schrieb bruce m beach:
> Hello All
> 
>  I am still working on cleaning up ath9k_htc firmware build tree for about 6
> months now ( and looks like I'll be doing this for all eternity**2 ) and am
> not clear myself what I'm looking for right now.
> 
> I'm looking for some kind of simple request in the ath9k_htc driver, through
> the usb ep0, like a memory read on the card, where a urb is sent with
> the resulting chain of events. The simpler the better. The simplest.

For EP0 on drivers site:
static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
{
int transfer, err;
const void *data = hif_dev->fw_data;
size_t len = hif_dev->fw_size;
u32 addr = AR9271_FIRMWARE;
u8 *buf = kzalloc(4096, GFP_KERNEL);
u32 firm_offset;

if (!buf)
return -ENOMEM;

while (len) {
transfer = min_t(size_t, len, 4096);
memcpy(buf, data, transfer);

err = usb_control_msg(hif_dev->udev,
  usb_sndctrlpipe(hif_dev->udev, 0),
  FIRMWARE_DOWNLOAD, 0x40 | USB_DIR_OUT,
  addr >> 8, 0, buf, transfer, HZ);

=



On side of pre installed firmware, the code looks like this:
open-ath9k-htc-firmware/sboot/magpie_1_1/sboot/hif/usb/src/usb_api.c
LOCAL void VendorCommand(void)
{
#define cUSB_REQ_DOWNLOAD  0x30
#define cUSB_REQ_DOWNLOAD_COMP 0x31
#define cUSB_REQ_BOOT  0x32
#define cUSB_REQ_RESERVED_10x33
#define cUSB_REQ_RESERVED_20x34

#define cUSB_REQ_FLASH_READ0x35
#define cUSB_REQ_FLASH_READ_COMP   0x36

//#define ZM_FIRMWARE_ADDR   0x20

void (*funcPtr)(void);
uint16_t *text_addr = 0;
uint32_t ep0_data = 0x0;
...



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ath9k: remove repetitions of mask array size

[Oleksij Rempel]

Thank you!

Kalle should be in CC.

Am 16.04.2016 um 16:54 schrieb Bob Copeland:
> The constant "123", which is the number of elements in
> mask_m / mask_p, is repeated several times in this function.
> 
> Replace memsets with array initialization, and replace a loop
> conditional with ARRAY_SIZE() so that we don't repeat ourselves.
> 
> Signed-off-by: Bob Copeland <m...@bobcopeland.com>

Reviewed-by: Oleksij Rempel <li...@rempel-privat.de>

> ---
>  drivers/net/wireless/ath/ath9k/ar5008_phy.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
> b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
> index 1b271b9..8eea8d2 100644
> --- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
> +++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
> @@ -260,8 +260,8 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>   int cur_bin;
>   int upper, lower, cur_vit_mask;
>   int i;
> - int8_t mask_m[123];
> - int8_t mask_p[123];
> + int8_t mask_m[123] = {0};
> + int8_t mask_p[123] = {0};
>   int8_t mask_amt;
>   int tmp_mask;
>   static const int pilot_mask_reg[4] = {
> @@ -274,9 +274,6 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>   };
>   static const int inc[4] = { 0, 100, 0, 0 };
>  
> - memset(_m, 0, sizeof(int8_t) * 123);
> - memset(_p, 0, sizeof(int8_t) * 123);
> -
>   cur_bin = -6000;
>   upper = bin + 100;
>   lower = bin - 100;
> @@ -302,7 +299,7 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>   upper = bin + 120;
>   lower = bin - 120;
>  
> - for (i = 0; i < 123; i++) {
> + for (i = 0; i < ARRAY_SIZE(mask_m); i++) {
>   if ((cur_vit_mask > lower) && (cur_vit_mask < upper)) {
>   /* workaround for gcc bug #37014 */
>   volatile int tmp_v = abs(cur_vit_mask - bin);
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

[Oleksij Rempel]

Am 15.04.2016 um 22:59 schrieb Bob Copeland:
> On Tue, Apr 12, 2016 at 07:37:44PM +0200, Oleksij Rempel wrote:
>> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
>> mask_m & mask_p initialisation. This coused a performance regression
>> on ar9281.
>>
>> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
>> code in ar9002_hw_spur_mitigate.")
>> Reported-by: Gustav Frederiksen <lkml2...@openmailbox.org>
>> Tested-by: Gustav Frederiksen <lkml2...@openmailbox.org>
>> Signed-off-by: Oleksij Rempel <li...@rempel-privat.de>
>> ---
>>  drivers/net/wireless/ath/ath9k/ar5008_phy.c | 8 +++-
>>  drivers/net/wireless/ath/ath9k/ar9002_phy.c | 5 -
>>  2 files changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
>> b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
>> index 8f87930..1b271b9 100644
>> --- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
>> +++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
>> @@ -274,6 +274,9 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>>  };
>>  static const int inc[4] = { 0, 100, 0, 0 };
>>  
>> +memset(_m, 0, sizeof(int8_t) * 123);
>> +memset(_p, 0, sizeof(int8_t) * 123);
>> +
> 
> For a future patch, "sizeof(mask_m)" or even just:
> 
> u8 mask_m[123] = {0};
> 
> ... would be better here.  I looked at this bit and thought, no way is
> "123" actually correct.  Lo and behold, that is actually the number of
> array elements, whether that has a basis in something real or not :)

If you already on it can you please rework it on top of this patch?
This complete function can be probably reworked.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

[Oleksij Rempel]

Am 13.04.2016 um 11:45 schrieb Kalle Valo:
> Kalle Valo <kv...@codeaurora.org> writes:
> 
>> Oleksij Rempel <li...@rempel-privat.de> writes:
>>
>>> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
>>> mask_m & mask_p initialisation. This coused a performance regression
>>> on ar9281.
>>>
>>> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
>>> code in ar9002_hw_spur_mitigate.")
>>> Reported-by: Gustav Frederiksen <lkml2...@openmailbox.org>
>>> Tested-by: Gustav Frederiksen <lkml2...@openmailbox.org>
>>> Signed-off-by: Oleksij Rempel <li...@rempel-privat.de>
>>
>> If no objections I'm planning to send this to 4.6.
> 
> Should we also CC stable (4.2+)? I can add that before I commit the
> patch.
> 

Yes, please.
Thank you.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

[PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

[Oleksij Rempel]

by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
mask_m & mask_p initialisation. This coused a performance regression
on ar9281.

Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
code in ar9002_hw_spur_mitigate.")
Reported-by: Gustav Frederiksen <lkml2...@openmailbox.org>
Tested-by: Gustav Frederiksen <lkml2...@openmailbox.org>
Signed-off-by: Oleksij Rempel <li...@rempel-privat.de>
---
 drivers/net/wireless/ath/ath9k/ar5008_phy.c | 8 +++-
 drivers/net/wireless/ath/ath9k/ar9002_phy.c | 5 -
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 8f87930..1b271b9 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -274,6 +274,9 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
};
static const int inc[4] = { 0, 100, 0, 0 };
 
+   memset(_m, 0, sizeof(int8_t) * 123);
+   memset(_p, 0, sizeof(int8_t) * 123);
+
cur_bin = -6000;
upper = bin + 100;
lower = bin - 100;
@@ -424,14 +427,9 @@ static void ar5008_hw_spur_mitigate(struct ath_hw *ah,
int tmp, new;
int i;
 
-   int8_t mask_m[123];
-   int8_t mask_p[123];
int cur_bb_spur;
bool is2GHz = IS_CHAN_2GHZ(chan);
 
-   memset(_m, 0, sizeof(int8_t) * 123);
-   memset(_p, 0, sizeof(int8_t) * 123);
-
for (i = 0; i < AR_EEPROM_MODAL_SPURS; i++) {
cur_bb_spur = ah->eep_ops->get_spur_channel(ah, i, is2GHz);
if (AR_NO_SPUR == cur_bb_spur)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index db66245..53d7445 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -178,14 +178,9 @@ static void ar9002_hw_spur_mitigate(struct ath_hw *ah,
int i;
struct chan_centers centers;
 
-   int8_t mask_m[123];
-   int8_t mask_p[123];
int cur_bb_spur;
bool is2GHz = IS_CHAN_2GHZ(chan);
 
-   memset(_m, 0, sizeof(int8_t) * 123);
-   memset(_p, 0, sizeof(int8_t) * 123);
-
ath9k_hw_get_channel_centers(ah, chan, );
freq = centers.synth_center;
 
-- 
2.5.0

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

Re: [PATCH] Revert regression in ath9k on AR9281

[Oleksij Rempel]

Hi Gustav,

thank you for your work.
Can you please test attached patch.

Am 11.04.2016 um 04:28 schrieb Gustav Frederiksen:
> Hi,
> thank you for taking the time to answer my previous email and for
> providing those useful tips.


-- 
Regards,
Oleksij
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 8f87930..1b271b9 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -274,6 +274,9 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
 	};
 	static const int inc[4] = { 0, 100, 0, 0 };
 
+	memset(_m, 0, sizeof(int8_t) * 123);
+	memset(_p, 0, sizeof(int8_t) * 123);
+
 	cur_bin = -6000;
 	upper = bin + 100;
 	lower = bin - 100;
@@ -424,14 +427,9 @@ static void ar5008_hw_spur_mitigate(struct ath_hw *ah,
 	int tmp, new;
 	int i;
 
-	int8_t mask_m[123];
-	int8_t mask_p[123];
 	int cur_bb_spur;
 	bool is2GHz = IS_CHAN_2GHZ(chan);
 
-	memset(_m, 0, sizeof(int8_t) * 123);
-	memset(_p, 0, sizeof(int8_t) * 123);
-
 	for (i = 0; i < AR_EEPROM_MODAL_SPURS; i++) {
 		cur_bb_spur = ah->eep_ops->get_spur_channel(ah, i, is2GHz);
 		if (AR_NO_SPUR == cur_bb_spur)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index db66245..53d7445 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -178,14 +178,9 @@ static void ar9002_hw_spur_mitigate(struct ath_hw *ah,
 	int i;
 	struct chan_centers centers;
 
-	int8_t mask_m[123];
-	int8_t mask_p[123];
 	int cur_bb_spur;
 	bool is2GHz = IS_CHAN_2GHZ(chan);
 
-	memset(_m, 0, sizeof(int8_t) * 123);
-	memset(_p, 0, sizeof(int8_t) * 123);
-
 	ath9k_hw_get_channel_centers(ah, chan, );
 	freq = centers.synth_center;
 


signature.asc
Description: OpenPGP digital signature

Re: test suite for ath9k_htc

[Oleksij Rempel]

Am 25.03.2016 um 18:03 schrieb bruce m beach:
> Hello
> 
>  I have been working on cleaning up ath9k_htc firmware build tree for about 3
> months now( and looks like I'll be doing this for all eternity) and am looking
> for a low-level test-suite that exists or I write myself or a combination of
> both, so I invite comment.

Suddenly I'm not aware of any low-level test-suite.

what are your thoughts about it? What exactly do you wont to test?
-- 
Regards,
Oleksij




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] net-ath9k_htc: Delete an unnecessary variable initialisation in ath9k_hif_usb_rx_stream()

[Oleksij Rempel]

Am 01.01.2016 um 19:23 schrieb SF Markus Elfring:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Fri, 1 Jan 2016 19:00:53 +0100
> 
> Omit explicit initialisation at the beginning for one local variable
> that is redefined before its first use.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
> b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 165dd20..51bd61b 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -525,7 +525,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb 
> *hif_dev,
>   struct sk_buff *skb)
>  {
>   struct sk_buff *nskb, *skb_pool[MAX_PKT_NUM_IN_TRANSFER];
> - int index = 0, i = 0, len = skb->len;
> + int index = 0, i, len = skb->len;
>   int rx_remain_len, rx_pkt_len;
>   u16 pool_index = 0;
>   u8 *ptr;
> 


Reviewed-by: Oleksij Rempel <li...@rempel-privat.de>

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel()

[Oleksij Rempel]

Am 01.01.2016 um 19:25 schrieb SF Markus Elfring:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Fri, 1 Jan 2016 19:09:32 +0100
> 
> Replace an explicit initialisation for one local variable at the beginning
> by a conditional assignment.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/net/wireless/ath/ath9k/htc_drv_main.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c 
> b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> index a680a97..30bd59e 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> @@ -246,7 +246,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv 
> *priv,
>   struct ieee80211_conf *conf = >hw->conf;
>   bool fastcc;
>   struct ieee80211_channel *channel = hw->conf.chandef.chan;
> - struct ath9k_hw_cal_data *caldata = NULL;
> + struct ath9k_hw_cal_data *caldata;
>   enum htc_phymode mode;
>   __be16 htc_mode;
>   u8 cmd_rsp;
> @@ -274,10 +274,7 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv 
> *priv,
>   priv->ah->curchan->channel,
>   channel->center_freq, conf_is_ht(conf), conf_is_ht40(conf),
>   fastcc);
> -
> - if (!fastcc)
> - caldata = >caldata;
> -
> + caldata = fastcc ? NULL : >caldata;
>   ret = ath9k_hw_reset(ah, hchan, caldata, fastcc);
>   if (ret) {
>   ath_err(common,
> 

Reviewed-by: Oleksij Rempel <li...@rempel-privat.de>

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k driver broken since kernel v4.2

[Oleksij Rempel]

Hi Bart

Am 24.12.2015 um 08:34 schrieb Bart Van Assche:
> Hello,
> 
> The ath9k driver drops more than 90% of all packets with Linux kernel
> v4.4-rc6 on my laptop. This behavior also occurs with kernel v4.2.
> However, with Linux kernel versions v4.1.5 and v3.19.3 the ath9k driver
> works fine on the same laptop. Is this report sufficient for one of the
> ath9k drivers to look further into this or do you perhaps expect me to
> run a bisect ?

Many people using this driver. For example it works fine on my laptop.
Since no body knows why your HW is affected try to use git bisect.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ath9k_htc: use ether_addr_copy() instead of memcpy()

[Oleksij Rempel]

Am 23.09.2015 um 15:16 schrieb Sujith Manoharan:
> Oleksij Rempel wrote:
>> Signed-off-by: Oleksij Rempel <li...@rempel-privat.de>
>> ---
>>  drivers/net/wireless/ath/ath9k/htc_drv_init.c |  2 +-
>>  drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 
>>  2 files changed, 13 insertions(+), 13 deletions(-)
> 
> Both the arguments for ether_addr_copy() need to be
> aligned. Is this the case for all the replacements in
> this patch ?
> 
> Sujith
> 

hm... you right. Kvalo, please drop this patch.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

[PATCH] ath9k_htc: use ether_addr_copy() instead of memcpy()

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel <li...@rempel-privat.de>
---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |  2 +-
 drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 1e84882..254a1e4 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -587,7 +587,7 @@ static void ath9k_init_misc(struct ath9k_htc_priv *priv)
 {
struct ath_common *common = ath9k_hw_common(priv->ah);
 
-   memcpy(common->bssidmask, ath_bcast_mac, ETH_ALEN);
+   ether_addr_copy(common->bssidmask, ath_bcast_mac);
 
common->last_rssi = ATH_RSSI_DUMMY_MARKER;
priv->ah->opmode = NL80211_IFTYPE_STATION;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 172a9ff..e6b13ed 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -159,10 +159,10 @@ static void ath9k_htc_set_mac_bssid_mask(struct 
ath9k_htc_priv *priv,
priv->hw, IEEE80211_IFACE_ITER_RESUME_ALL,
ath9k_htc_bssid_iter, _data);
 
-   memcpy(common->bssidmask, iter_data.mask, ETH_ALEN);
+   ether_addr_copy(common->bssidmask, iter_data.mask);
 
if (iter_data.hw_macaddr)
-   memcpy(common->macaddr, iter_data.hw_macaddr, ETH_ALEN);
+   ether_addr_copy(common->macaddr, iter_data.hw_macaddr);
 
ath_hw_setbssidmask(common);
 }
@@ -338,7 +338,7 @@ static void __ath9k_htc_remove_monitor_interface(struct 
ath9k_htc_priv *priv)
u8 cmd_rsp;
 
memset(, 0, sizeof(struct ath9k_htc_target_vif));
-   memcpy(, common->macaddr, ETH_ALEN);
+   ether_addr_copy(hvif.myaddr, common->macaddr);
hvif.index = priv->mon_vif_idx;
WMI_CMD_BUF(WMI_VAP_REMOVE_CMDID, );
if (ret) {
@@ -374,7 +374,7 @@ static int ath9k_htc_add_monitor_interface(struct 
ath9k_htc_priv *priv)
 * Add an interface.
 */
memset(, 0, sizeof(struct ath9k_htc_target_vif));
-   memcpy(, common->macaddr, ETH_ALEN);
+   ether_addr_copy(hvif.myaddr, common->macaddr);
 
hvif.opmode = HTC_M_MONITOR;
hvif.index = ffz(priv->vif_slot);
@@ -404,7 +404,7 @@ static int ath9k_htc_add_monitor_interface(struct 
ath9k_htc_priv *priv)
 */
memset(, 0, sizeof(struct ath9k_htc_target_sta));
 
-   memcpy(, common->macaddr, ETH_ALEN);
+   ether_addr_copy(tsta.macaddr, common->macaddr);
 
tsta.is_vif_sta = 1;
tsta.sta_index = sta_idx;
@@ -489,15 +489,15 @@ static int ath9k_htc_add_station(struct ath9k_htc_priv 
*priv,
 
if (sta) {
ista = (struct ath9k_htc_sta *) sta->drv_priv;
-   memcpy(, sta->addr, ETH_ALEN);
-   memcpy(, common->curbssid, ETH_ALEN);
+   ether_addr_copy(tsta.macaddr, sta->addr);
+   ether_addr_copy(tsta.bssid, common->curbssid);
ista->index = sta_idx;
tsta.is_vif_sta = 0;
maxampdu = 1 << (IEEE80211_HT_MAX_AMPDU_FACTOR +
 sta->ht_cap.ampdu_factor);
tsta.maxampdu = cpu_to_be16(maxampdu);
} else {
-   memcpy(, vif->addr, ETH_ALEN);
+   ether_addr_copy(tsta.macaddr, vif->addr);
tsta.is_vif_sta = 1;
tsta.maxampdu = cpu_to_be16(0x);
}
@@ -1048,7 +1048,7 @@ static int ath9k_htc_add_interface(struct ieee80211_hw 
*hw,
 
ath9k_htc_ps_wakeup(priv);
memset(, 0, sizeof(struct ath9k_htc_target_vif));
-   memcpy(, vif->addr, ETH_ALEN);
+   ether_addr_copy(hvif.myaddr, vif->addr);
 
switch (vif->type) {
case NL80211_IFTYPE_STATION:
@@ -1131,7 +1131,7 @@ static void ath9k_htc_remove_interface(struct 
ieee80211_hw *hw,
ath9k_htc_ps_wakeup(priv);
 
memset(, 0, sizeof(struct ath9k_htc_target_vif));
-   memcpy(, vif->addr, ETH_ALEN);
+   ether_addr_copy(hvif.myaddr, vif->addr);
hvif.index = avp->index;
WMI_CMD_BUF(WMI_VAP_REMOVE_CMDID, );
if (ret) {
@@ -1493,7 +1493,7 @@ static void ath9k_htc_bss_iter(void *data, u8 *mac, 
struct ieee80211_vif *vif)
if ((vif->type == NL80211_IFTYPE_STATION) && bss_conf->assoc) {
common->curaid = bss_conf->aid;
common->last_rssi = ATH_RSSI_DUMMY_MARKER;
-   memcpy(common->curbssid, bss_conf->bssid, ETH_ALEN);
+   ether_addr_copy(common->curbssid, bss_conf->bssid);
set_bit(ATH_OP_PRIM_STA_VIF, >op_flags);
}
 }
@@ -1543,7 +1543,7 @@ static void ath

Re: [PATCH v4] ath9k_htc: introduce support for different fw versions

[Oleksij Rempel]

Am 18.09.2015 um 09:42 schrieb Kalle Valo:
> Oleksij Rempel <li...@rempel-privat.de> writes:
> 
>> Current kernel support only one fw name with theoretically only one
>> fw version located in “firmware/htc_[9271|7010].fw”. Which is ok so far we
>> have only one fw version (1.3). After we realised new fw 1.4, we faced
>> compatibility problem which was decided to solve by firmware name and
>> location:
>> - new firmware is located now in
>>  firmware/ath9k_htc/htc_[9271|7010]-1.4.0.fw
>> - old version 1.3 should be on old place, so old kernel have no issues
>>  with it.
>> - new kernels including this patch should be able to try different
>>  supported (min..max) fw version.
>> - new kernel should be able to support old fw location too. At least for
>>  now.
>>
>> At same time this patch will add new module option which should allow user
>> to play with development  fw version without replacing stable one. If user
>> will set “ath9k_htc use_dev_fw=1” module will try to find
>> firmware/ath9k_htc/htc_[9271|7010]-1.dev.0.fw first and if it fails, use
>> stable version: for example...1.4.0.fw.
>>
>> Signed-off-by: Oleksij Rempel <li...@rempel-privat.de>
> 
> Thanks, applied manually. You forgot to CC linux-wireless and hence
> patchwork didn't see this.
> 
> In the future please add a changelog when sending new versions of a
> patch.
> 

ok,
thank you!

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] ath9k_htc: introduce support for different fw versions

[Oleksij Rempel]

Am 06.09.2015 um 12:55 schrieb Kalle Valo:
> Oleksij Rempel <li...@rempel-privat.de> writes:
> 
>> Current kernel support only one fw name with theoretically only one
>> fw version located in “firmware/htc_[9271|7010].fw”. Which is ok so
>> far we have only one fw version (1.3). After we realised new fw 1.4,
>> we faced compatibility problem which was decided to solve by firmware
>> name and location:
>>
>> - new firmware is located now in firmware/ath9k_htc/htc_[9271|7010]-1.4.0.fw
>> - old version 1.3 should be on old place, so old kernel have no issues with 
>> it.
>> - new kernels including this patch should be able to try different supported 
>> (min..max) fw version.
>> - new kernel should be able to support old fw location too. At least for now.
> 
> Please word wrap the commit log.

ok.

>> At same time this patch will add new module option which should allow
>> user to play with development fw version without replacing stable one.
>> If user will set “ath9k_htc use_dev_fw=1” module will try to find
>> firmware/ath9k_htc/htc_[9271|7010]-1.dev.0.fw first and if it fails,
>> use stable version: for example...1.4.0.fw.
> 
> I'm not really sure if this module parameter makes sense and I haven't
> noticed any other wifi driver having a similar parameter. If user wants
> to test a developemnt firmware he can override a stable firmware version
> with a simple cp operation. So why is the module parameter needed?
> 
Sure, iwl module has CONFIG for this case, so you should recompile it.
The use case which i was thinking is the ability to provide a package
for dev FW, which will not conflict with main FW package.

The package just should provide 3 files, /etc/modules/ath9k_htc_params
and /lib/firmware/bla.fw
If dev package introduces some regressions i still can ask user to
reload module with other parameter.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

[PATCH] ath9k_htc: do ani shortcalibratio if we got -ETIMEDOUT

[Oleksij Rempel]

From: Oleksij Rempel external.oleksij.rem...@de.bosch.com

current code will handle -ETIMEDOUT as success which is probalbly wrong.

According to this comment I assume it is safe to handle -ETIMEDOUT as false:
drivers/net/wireless/ath/ath9k/calib.c
290 /*
291  * We timed out waiting for the noisefloor to load, probably due to 
an
292  * in-progress rx. Simply return here and allow the load plenty of 
time
293  * to complete before the next calibration interval.  We need to 
avoid
294  * trying to load -50 (which happens below) while the previous load 
is
295  * still in progress as this can cause rx deafness. Instead by 
returning
296  * here, the baseband nf cal will just be capped by our present
297  * noisefloor until the next calibration timer.
298  */

Since no other error wariants are present, this patch is checking only
for (ret = 0).

Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Oleksij Rempel external.oleksij.rem...@de.bosch.com
---
 drivers/net/wireless/ath/ath9k/htc_drv_main.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index dab1323..172a9ff 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -794,8 +794,11 @@ void ath9k_htc_ani_work(struct work_struct *work)
common-ani.longcal_timer = timestamp;
}
 
-   /* Short calibration applies only while caldone is false */
-   if (!common-ani.caldone) {
+   /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+   if (common-ani.caldone = 0) {
if ((timestamp - common-ani.shortcal_timer) =
short_cal_interval) {
shortcal = true;
@@ -844,7 +847,11 @@ set_timer:
*/
cal_interval = ATH_LONG_CALINTERVAL;
cal_interval = min(cal_interval, (u32)ATH_ANI_POLLINTERVAL);
-   if (!common-ani.caldone)
+   /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+   if (common-ani.caldone = 0)
cal_interval = min(cal_interval, (u32)short_cal_interval);
 
ieee80211_queue_delayed_work(common-hw, priv-ani_work,
-- 
2.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] ath9k_htc: do ani shortcalibratio if we got -ETIMEDOUT

[Oleksij Rempel]

current code will handle -ETIMEDOUT as success which is probalbly wrong.

According to this comment I assume it is safe to handle -ETIMEDOUT as false:
drivers/net/wireless/ath/ath9k/calib.c
290 /*
291  * We timed out waiting for the noisefloor to load, probably due to 
an
292  * in-progress rx. Simply return here and allow the load plenty of 
time
293  * to complete before the next calibration interval.  We need to 
avoid
294  * trying to load -50 (which happens below) while the previous load 
is
295  * still in progress as this can cause rx deafness. Instead by 
returning
296  * here, the baseband nf cal will just be capped by our present
297  * noisefloor until the next calibration timer.
298  */

Since no other error wariants are present, this patch is checking only
for (ret = 0).

Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/htc_drv_main.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index dab1323..172a9ff 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -794,8 +794,11 @@ void ath9k_htc_ani_work(struct work_struct *work)
common-ani.longcal_timer = timestamp;
}
 
-   /* Short calibration applies only while caldone is false */
-   if (!common-ani.caldone) {
+   /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+   if (common-ani.caldone = 0) {
if ((timestamp - common-ani.shortcal_timer) =
short_cal_interval) {
shortcal = true;
@@ -844,7 +847,11 @@ set_timer:
*/
cal_interval = ATH_LONG_CALINTERVAL;
cal_interval = min(cal_interval, (u32)ATH_ANI_POLLINTERVAL);
-   if (!common-ani.caldone)
+   /*
+* Short calibration applies only while caldone
+* is false or -ETIMEDOUT
+*/
+   if (common-ani.caldone = 0)
cal_interval = min(cal_interval, (u32)short_cal_interval);
 
ieee80211_queue_delayed_work(common-hw, priv-ani_work,
-- 
2.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-devel] [PATCH] ath9k_htc: do ani shortcalibratio if we got -ETIMEDOUT

[Oleksij Rempel]

Opps wrong email address. I'll resend the patch

Am 13.08.2015 um 20:21 schrieb Oleksij Rempel:
 From: Oleksij Rempel external.oleksij.rem...@de.bosch.com
 
 current code will handle -ETIMEDOUT as success which is probalbly wrong.
 
 According to this comment I assume it is safe to handle -ETIMEDOUT as false:
 drivers/net/wireless/ath/ath9k/calib.c
 290 /*
 291  * We timed out waiting for the noisefloor to load, probably due 
 to an
 292  * in-progress rx. Simply return here and allow the load plenty 
 of time
 293  * to complete before the next calibration interval.  We need to 
 avoid
 294  * trying to load -50 (which happens below) while the previous 
 load is
 295  * still in progress as this can cause rx deafness. Instead by 
 returning
 296  * here, the baseband nf cal will just be capped by our present
 297  * noisefloor until the next calibration timer.
 298  */
 
 Since no other error wariants are present, this patch is checking only
 for (ret = 0).
 
 Reported-by: Dan Carpenter dan.carpen...@oracle.com
 Signed-off-by: Oleksij Rempel external.oleksij.rem...@de.bosch.com
 ---
  drivers/net/wireless/ath/ath9k/htc_drv_main.c | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c 
 b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
 index dab1323..172a9ff 100644
 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
 +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
 @@ -794,8 +794,11 @@ void ath9k_htc_ani_work(struct work_struct *work)
   common-ani.longcal_timer = timestamp;
   }
  
 - /* Short calibration applies only while caldone is false */
 - if (!common-ani.caldone) {
 + /*
 +  * Short calibration applies only while caldone
 +  * is false or -ETIMEDOUT
 +  */
 + if (common-ani.caldone = 0) {
   if ((timestamp - common-ani.shortcal_timer) =
   short_cal_interval) {
   shortcal = true;
 @@ -844,7 +847,11 @@ set_timer:
   */
   cal_interval = ATH_LONG_CALINTERVAL;
   cal_interval = min(cal_interval, (u32)ATH_ANI_POLLINTERVAL);
 - if (!common-ani.caldone)
 + /*
 +  * Short calibration applies only while caldone
 +  * is false or -ETIMEDOUT
 +  */
 + if (common-ani.caldone = 0)
   cal_interval = min(cal_interval, (u32)short_cal_interval);
  
   ieee80211_queue_delayed_work(common-hw, priv-ani_work,
 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

[PATCH v3] ath9k_htc: introduce support for different fw versions

[Oleksij Rempel]

Current kernel support only one fw name with theoretically only one
fw version located in “firmware/htc_[9271|7010].fw”. Which is ok so far we have 
only one fw version (1.3). After we realised new fw 1.4, we faced compatibility 
problem which was decided to solve by firmware name and location:
- new firmware is located now in firmware/ath9k_htc/htc_[9271|7010]-1.4.0.fw
- old version 1.3 should be on old place, so old kernel have no issues with it.
- new kernels including this patch should be able to try different supported 
(min..max) fw version.
- new kernel should be able to support old fw location too. At least for now.

At same time this patch will add new module option which should allow user to 
play with development  fw version without replacing stable one. If user will 
set “ath9k_htc use_dev_fw=1” module will try to find 
firmware/ath9k_htc/htc_[9271|7010]-1.dev.0.fw first and if it fails, use stable 
version: for example...1.4.0.fw.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/hif_usb.c  | 106 --
 drivers/net/wireless/ath/ath9k/hif_usb.h  |  21 -
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |   4 +
 3 files changed, 105 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 10c02f5..165dd20 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -17,12 +17,8 @@
 #include asm/unaligned.h
 #include htc.h
 
-/* identify firmware images */
-#define FIRMWARE_AR7010_1_1 htc_7010.fw
-#define FIRMWARE_AR9271 htc_9271.fw
-
-MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
-MODULE_FIRMWARE(FIRMWARE_AR9271);
+MODULE_FIRMWARE(HTC_7010_MODULE_FW);
+MODULE_FIRMWARE(HTC_9271_MODULE_FW);
 
 static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
@@ -1080,12 +1076,88 @@ static void ath9k_hif_usb_firmware_fail(struct 
hif_device_usb *hif_dev)
device_unlock(parent);
 }
 
+static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void 
*context);
+
+/* taken from iwlwifi */
+static int ath9k_hif_request_firmware(struct hif_device_usb *hif_dev,
+ bool first)
+{
+   char index[8], *chip;
+   int ret;
+
+   if (first) {
+   if (htc_use_dev_fw) {
+   hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX + 1;
+   sprintf(index, %s, dev);
+   } else {
+   hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX;
+   sprintf(index, %d, hif_dev-fw_minor_index);
+   }
+   } else {
+   hif_dev-fw_minor_index--;
+   sprintf(index, %d, hif_dev-fw_minor_index);
+   }
+
+   /* test for FW 1.3 */
+   if (MAJOR_VERSION_REQ == 1  hif_dev-fw_minor_index == 3) {
+   const char *filename;
+
+   if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+   filename = FIRMWARE_AR7010_1_1;
+   else
+   filename = FIRMWARE_AR9271;
+
+   /* expected fw locations:
+* - htc_9271.fw   (stable version 1.3, depricated)
+*/
+   snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+%s, filename);
+
+   } else if (hif_dev-fw_minor_index  FIRMWARE_MINOR_IDX_MIN) {
+   dev_err(hif_dev-udev-dev, no suitable firmware found!\n);
+
+   return -ENOENT;
+   } else {
+   if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+   chip = 7010;
+   else
+   chip = 9271;
+
+   /* expected fw locations:
+* - ath9k_htc/htc_9271-1.dev.0.fw (development version)
+* - ath9k_htc/htc_9271-1.4.0.fw   (stable version)
+*/
+   snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+%s/htc_%s-%d.%s.0.fw, HTC_FW_PATH,
+chip, MAJOR_VERSION_REQ, index);
+   }
+
+   ret = request_firmware_nowait(THIS_MODULE, true, hif_dev-fw_name,
+ hif_dev-udev-dev, GFP_KERNEL,
+ hif_dev, ath9k_hif_usb_firmware_cb);
+   if (ret) {
+   dev_err(hif_dev-udev-dev,
+   ath9k_htc: Async request for firmware %s failed\n,
+   hif_dev-fw_name);
+   return ret;
+   }
+
+   dev_info(hif_dev-udev-dev, ath9k_htc: Firmware %s requested\n,
+hif_dev-fw_name);
+
+   return ret;
+}
+
 static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
 {
struct hif_device_usb *hif_dev = context;
int ret;
 
if (!fw) {
+   ret = ath9k_hif_request_firmware(hif_dev

Re: [PATCH 2/2] ath9k: export HW random number generator

[Oleksij Rempel]

Am 27.07.2015 um 08:50 schrieb Pan, Miaoqing:
  “fips_run_rng_test”  is legacy code, recommend to disable 'FIPS 140-2' test 
 if to use 'rngd-tools’.

Ok, lets try simple compression. will it find enough pattern to do
compression?
Here what i get on my system:
output from /dev/random
-rw-rw-r-- 1 lex lex 2501678 Jul 27 12:01 random.out
-rw-rw-r-- 1 lex lex 2512892 Jul 27 12:01 random.out.bz2

after compression we got bigger file. i would expect it since we need to
store bzip header somewhere.

output from /dev/hwrng
-rw-rw-r-- 1 lex lex 2564096 Jul 27 11:36 hwrng.out
-rw-rw-r-- 1 lex lex 2468394 Jul 27 11:36 hwrng.out.bz2

Do i understand it correctly, in case of hwrng bzip was able to find
enough pattern to compressed the data? Even with format overhead?

I'm no an expert, help of an expert would be welcome, added some more
people to CC

 -Miaoqing
 
 -Original Message-
 From: Oleksij Rempel [mailto:li...@rempel-privat.de] 
 Sent: Sunday, July 26, 2015 3:41 PM
 To: Pan, Miaoqing; linvi...@tuxdriver.com
 Cc: linux-wireless@vger.kernel.org; ath9k-devel
 Subject: Re: [PATCH 2/2] ath9k: export HW random number generator
 
 Hi all,
 
 i did rngtest on top of this patch. The results are incredibly bad, right now 
 it is more a pattern generator not random number generator. Is it possible to 
 fix it?
 
 /home/lex# cat /dev/hwrng | rngtest -c 1000 rngtest 5 Copyright (c) 2004 by 
 Henrique de Moraes Holschuh This is free software; see the source for copying 
 conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS 
 FOR A PARTICULAR PURPOSE.
 
 rngtest: starting FIPS tests...
 rngtest: bits received from input: 2032
 rngtest: FIPS 140-2 successes: 0
 rngtest: FIPS 140-2 failures: 1000
 rngtest: FIPS 140-2(2001-10-10) Monobit: 27
 rngtest: FIPS 140-2(2001-10-10) Poker: 1000
 rngtest: FIPS 140-2(2001-10-10) Runs: 1000
 rngtest: FIPS 140-2(2001-10-10) Long run: 2
 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
 rngtest: input channel speed: (min=1.879; avg=871.897; 
 max=19531250.000)Kibits/s
 rngtest: FIPS tests speed: (min=19.443; avg=48.374; max=70.123)Mibits/s
 rngtest: Program run time: 23423736 microseconds
 
 
 
 Am 15.07.2015 um 09:54 schrieb miaoq...@qti.qualcomm.com:
 From: Miaoqing Pan miaoq...@qca.qualcomm.com

 We measured the FFT-based entropy in 3 ways, Shannon entropy, 
 collision entropy, and directly measured min-entropy. Just to be 
 conservative, we recommend the estimated min-Entropy to be
 10 bits per 16-bit value.

 Analysis was done by Jacobson,David(djaco...@qti.qualcomm.com).

 Signed-off-by: Miaoqing Pan miaoq...@qca.qualcomm.com
 ---
  drivers/net/wireless/ath/ath9k/Kconfig  |  7 +++  
 drivers/net/wireless/ath/ath9k/Makefile |  1 +  
 drivers/net/wireless/ath/ath9k/ath9k.h  | 23 ++
  drivers/net/wireless/ath/ath9k/main.c   |  4 ++
  drivers/net/wireless/ath/ath9k/rng.c| 75 
 +
  5 files changed, 110 insertions(+)
  create mode 100644 drivers/net/wireless/ath/ath9k/rng.c

 diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
 b/drivers/net/wireless/ath/ath9k/Kconfig
 index fee0cad..bde62ec9 100644
 --- a/drivers/net/wireless/ath/ath9k/Kconfig
 +++ b/drivers/net/wireless/ath/ath9k/Kconfig
 @@ -176,3 +176,10 @@ config ATH9K_HTC_DEBUGFS
  depends on ATH9K_HTC  DEBUG_FS
  ---help---
Say Y, if you need access to ath9k_htc's statistics.
 +
 +config ATH9K_HWRNG
 +bool Random number generator support
 +depends on ATH9K  (HW_RANDOM = y || HW_RANDOM = ATH9K)
 +default y
 +---help---
 +  Provides a hardware random number generator to the kernel.
 diff --git a/drivers/net/wireless/ath/ath9k/Makefile 
 b/drivers/net/wireless/ath/ath9k/Makefile
 index ecda613..76f9dc3 100644
 --- a/drivers/net/wireless/ath/ath9k/Makefile
 +++ b/drivers/net/wireless/ath/ath9k/Makefile
 @@ -15,6 +15,7 @@ ath9k-$(CONFIG_ATH9K_DFS_DEBUGFS) += dfs_debug.o
  ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o
  ath9k-$(CONFIG_ATH9K_TX99) += tx99.o
  ath9k-$(CONFIG_ATH9K_WOW) += wow.o
 +ath9k-$(CONFIG_ATH9K_HWRNG) += rng.o
  
  ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
  
 diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
 b/drivers/net/wireless/ath/ath9k/ath9k.h
 index a7a81b3..45596e5 100644
 --- a/drivers/net/wireless/ath/ath9k/ath9k.h
 +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
 @@ -23,6 +23,7 @@
  #include linux/leds.h
  #include linux/completion.h
  #include linux/time.h
 +#include linux/hw_random.h
  
  #include common.h
  #include debug.h
 @@ -1041,6 +1042,12 @@ struct ath_softc {
  u32 wow_intr_before_sleep;
  bool force_wow;
  #endif
 +
 +#ifdef CONFIG_ATH9K_HWRNG
 +struct hwrng rng;
 +bool rng_initialized;
 +u32 rng_last;
 +#endif
  };
  
  //
 @@ -1063,6 +1070,22 @@ static inline int ath9k_tx99_send(struct 
 ath_softc *sc,  }  #endif /* CONFIG_ATH9K_TX99 */
  
 +/***/
 +/* Random Number Generator */
 +/***/
 +#ifdef

Re: [PATCH 2/2] ath9k: export HW random number generator

[Oleksij Rempel]

Hi all,

i did rngtest on top of this patch. The results are incredibly bad,
right now it is more a pattern generator not random number generator. Is
it possible to fix it?

/home/lex# cat /dev/hwrng | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 2032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 1000
rngtest: FIPS 140-2(2001-10-10) Monobit: 27
rngtest: FIPS 140-2(2001-10-10) Poker: 1000
rngtest: FIPS 140-2(2001-10-10) Runs: 1000
rngtest: FIPS 140-2(2001-10-10) Long run: 2
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.879; avg=871.897;
max=19531250.000)Kibits/s
rngtest: FIPS tests speed: (min=19.443; avg=48.374; max=70.123)Mibits/s
rngtest: Program run time: 23423736 microseconds



Am 15.07.2015 um 09:54 schrieb miaoq...@qti.qualcomm.com:
 From: Miaoqing Pan miaoq...@qca.qualcomm.com
 
 We measured the FFT-based entropy in 3 ways, Shannon entropy,
 collision entropy, and directly measured min-entropy. Just to
 be conservative, we recommend the estimated min-Entropy to be
 10 bits per 16-bit value.
 
 Analysis was done by Jacobson,David(djaco...@qti.qualcomm.com).
 
 Signed-off-by: Miaoqing Pan miaoq...@qca.qualcomm.com
 ---
  drivers/net/wireless/ath/ath9k/Kconfig  |  7 +++
  drivers/net/wireless/ath/ath9k/Makefile |  1 +
  drivers/net/wireless/ath/ath9k/ath9k.h  | 23 ++
  drivers/net/wireless/ath/ath9k/main.c   |  4 ++
  drivers/net/wireless/ath/ath9k/rng.c| 75 
 +
  5 files changed, 110 insertions(+)
  create mode 100644 drivers/net/wireless/ath/ath9k/rng.c
 
 diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
 b/drivers/net/wireless/ath/ath9k/Kconfig
 index fee0cad..bde62ec9 100644
 --- a/drivers/net/wireless/ath/ath9k/Kconfig
 +++ b/drivers/net/wireless/ath/ath9k/Kconfig
 @@ -176,3 +176,10 @@ config ATH9K_HTC_DEBUGFS
   depends on ATH9K_HTC  DEBUG_FS
   ---help---
 Say Y, if you need access to ath9k_htc's statistics.
 +
 +config ATH9K_HWRNG
 + bool Random number generator support
 + depends on ATH9K  (HW_RANDOM = y || HW_RANDOM = ATH9K)
 + default y
 + ---help---
 +   Provides a hardware random number generator to the kernel.
 diff --git a/drivers/net/wireless/ath/ath9k/Makefile 
 b/drivers/net/wireless/ath/ath9k/Makefile
 index ecda613..76f9dc3 100644
 --- a/drivers/net/wireless/ath/ath9k/Makefile
 +++ b/drivers/net/wireless/ath/ath9k/Makefile
 @@ -15,6 +15,7 @@ ath9k-$(CONFIG_ATH9K_DFS_DEBUGFS) += dfs_debug.o
  ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o
  ath9k-$(CONFIG_ATH9K_TX99) += tx99.o
  ath9k-$(CONFIG_ATH9K_WOW) += wow.o
 +ath9k-$(CONFIG_ATH9K_HWRNG) += rng.o
  
  ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
  
 diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
 b/drivers/net/wireless/ath/ath9k/ath9k.h
 index a7a81b3..45596e5 100644
 --- a/drivers/net/wireless/ath/ath9k/ath9k.h
 +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
 @@ -23,6 +23,7 @@
  #include linux/leds.h
  #include linux/completion.h
  #include linux/time.h
 +#include linux/hw_random.h
  
  #include common.h
  #include debug.h
 @@ -1041,6 +1042,12 @@ struct ath_softc {
   u32 wow_intr_before_sleep;
   bool force_wow;
  #endif
 +
 +#ifdef CONFIG_ATH9K_HWRNG
 + struct hwrng rng;
 + bool rng_initialized;
 + u32 rng_last;
 +#endif
  };
  
  //
 @@ -1063,6 +1070,22 @@ static inline int ath9k_tx99_send(struct ath_softc *sc,
  }
  #endif /* CONFIG_ATH9K_TX99 */
  
 +/***/
 +/* Random Number Generator */
 +/***/
 +#ifdef CONFIG_ATH9K_HWRNG
 +void ath9k_rng_register(struct ath_softc *sc);
 +void ath9k_rng_unregister(struct ath_softc *sc);
 +#else
 +static inline void ath9k_rng_register(struct ath_softc *sc)
 +{
 +}
 +
 +static inline void ath9k_rng_unregister(struct ath_softc *sc)
 +{
 +}
 +#endif
 +
  static inline void ath_read_cachesize(struct ath_common *common, int *csz)
  {
   common-bus_ops-read_cachesize(common, csz);
 diff --git a/drivers/net/wireless/ath/ath9k/main.c 
 b/drivers/net/wireless/ath/ath9k/main.c
 index cfd45cb..5916ab2 100644
 --- a/drivers/net/wireless/ath/ath9k/main.c
 +++ b/drivers/net/wireless/ath/ath9k/main.c
 @@ -739,6 +739,8 @@ static int ath9k_start(struct ieee80211_hw *hw)
  
   ath9k_ps_restore(sc);
  
 + ath9k_rng_register(sc);
 +
   return 0;
  }
  
 @@ -828,6 +830,8 @@ static void ath9k_stop(struct ieee80211_hw *hw)
  
   ath9k_deinit_channel_context(sc);
  
 + ath9k_rng_unregister(sc);
 +
   mutex_lock(sc-mutex);
  
   ath_cancel_work(sc);
 diff --git a/drivers/net/wireless/ath/ath9k/rng.c 
 b/drivers/net/wireless/ath/ath9k/rng.c
 new file mode 100644
 index 000..d8fa7a5
 --- /dev/null
 +++ 

Re: ath9k_htc: virtual interfaces, AP connection drop kernel warning

[Oleksij Rempel]

Am 23.07.2015 um 10:08 schrieb wim torfs:
 
 
 On 07/22/2015 07:16 PM, Oleksij Rempel wrote:
 Am 22.07.2015 um 18:37 schrieb Rolf Anderegg:

 On 16/07/15 13:54, Oleksij Rempel wrote:
 Am 13.07.2015 um 13:52 schrieb Rolf Anderegg:

 I suspect that there are bandwidth/speed issues when dealing with USB
 adapters, but that does not inherently mean that the connection is
 prone
 to drop, right? Doesn't that mean that I am leaking packages somewhere
 along the way? What else could I be looking for?

 The packages can drop if you will do channel scan. STA mode need some
 seconds to complete channel scan. It means AP will be all the time
 unavailable.

 Ok, that may be. Then again why am I not experiencing the same
 connection drop on my ath5k setup? Because the channel scan is more
 likely to be completed in due time?

 Yes, channel scantime on usb device is match longer then on pci.

 
 May I ask for the reason it takes a longer time to complete the scanning
 on a USB device compared to a PCI device? I assume the internals of an
 ath9k PCI device is similar as that of an ath9k_htc USB device, so is it
 purely the bus speed that affects this time? Or is the USB device a
 smaller version of the chipset on the PCI device and therefore with a
 lower speed due to power concerns?
 
 If it is due to the bus speed, would it be possible to decouple the
 scanning process from the bus, that is, I assume that the hardware
 performs all the necessary channel switching and channel sensing, so why
 not allow the hardware to gather such information and transfer the
 results in a single burst to the host over the USB bus? Or is the
 channel switching controlled by the host and it takes a lot of time due
 to the duration of transmitting the channel switching commands to the
 USB device?

Well, it is about development time vs scan time: do as match as possible
with one code base or develop two different code bases.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc: virtual interfaces, AP connection drop kernel warning

[Oleksij Rempel]

Am 13.07.2015 um 13:52 schrieb Rolf Anderegg:
 
 First of all, you are using ancient kernel and firmware. Please update
 it. Firmware should be at leas 1.4 and kernel probably 4.1 or later. i'm
 not sure which include patch with support of RMW command introduced by
 new FW.

 Then you can try to disable LED blinking which is stealing your usb
 bandwidth.
 
 Thanks for your suggestions.
 You say ancient, I was thinking longterm stable. For various reasons I
 require a RT patched kernel, alas this is not yet available for 4.1
 kernels. Aside from that I have updated the kernel and firmware as you
 propose. Also I have set ath9k_htc's blink=0. The kernel warnings are no
 longer occuring, however the AP's connection (which requires several
 attempts) is still dropped after a few seconds.
 I suspect that there are bandwidth/speed issues when dealing with USB
 adapters, but that does not inherently mean that the connection is prone
 to drop, right? Doesn't that mean that I am leaking packages somewhere
 along the way? What else could I be looking for?

The packages can drop if you will do channel scan. STA mode need some
seconds to complete channel scan. It means AP will be all the time
unavailable.

 Regards,
 Rolf Anderegg
 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc: virtual interfaces, AP connection drop kernel warning

[Oleksij Rempel]

Am 13.07.2015 um 13:52 schrieb Rolf Anderegg:
 
 First of all, you are using ancient kernel and firmware. Please update
 it. Firmware should be at leas 1.4 and kernel probably 4.1 or later. i'm
 not sure which include patch with support of RMW command introduced by
 new FW.

 Then you can try to disable LED blinking which is stealing your usb
 bandwidth.
 
 Thanks for your suggestions.
 You say ancient, I was thinking longterm stable. For various reasons I
 require a RT patched kernel, alas this is not yet available for 4.1
 kernels. Aside from that I have updated the kernel and firmware as you
 propose. Also I have set ath9k_htc's blink=0. The kernel warnings are no
 longer occuring, however the AP's connection (which requires several
 attempts) is still dropped after a few seconds.
 I suspect that there are bandwidth/speed issues when dealing with USB
 adapters, but that does not inherently mean that the connection is prone
 to drop, right? Doesn't that mean that I am leaking packages somewhere
 along the way? What else could I be looking for?

The packages can drop if you will do channel scan. STA mode need some
seconds to complete channel scan. It means AP will be all the time
unavailable.

 Regards,
 Rolf Anderegg
 


-- 
Regards,
Oleksij




signature.asc
Description: OpenPGP digital signature

[PATCH v3] ath9k_htc: introduce support for different fw versions

[Oleksij Rempel]

Current kernel support only one fw name with theoretically only one
fw version located in “firmware/htc_[9271|7010].fw”. Which is ok so far we have 
only one fw version (1.3). After we realised new fw 1.4, we faced compatibility 
problem which was decided to solve by firmware name and location:
- new firmware is located now in firmware/ath9k_htc/htc_[9271|7010]-1.4.0.fw
- old version 1.3 should be on old place, so old kernel have no issues with it.
- new kernels including this patch should be able to try different supported 
(min..max) fw version.
- new kernel should be able to support old fw location too. At least for now.

At same time this patch will add new module option which should allow user to 
play with development  fw version without replacing stable one. If user will 
set “ath9k_htc use_dev_fw=1” module will try to find 
firmware/ath9k_htc/htc_[9271|7010]-1.dev.0.fw first and if it fails, use stable 
version: for example...1.4.0.fw.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/hif_usb.c  | 106 --
 drivers/net/wireless/ath/ath9k/hif_usb.h  |  21 -
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |   4 +
 3 files changed, 105 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 10c02f5..165dd20 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -17,12 +17,8 @@
 #include asm/unaligned.h
 #include htc.h
 
-/* identify firmware images */
-#define FIRMWARE_AR7010_1_1 htc_7010.fw
-#define FIRMWARE_AR9271 htc_9271.fw
-
-MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
-MODULE_FIRMWARE(FIRMWARE_AR9271);
+MODULE_FIRMWARE(HTC_7010_MODULE_FW);
+MODULE_FIRMWARE(HTC_9271_MODULE_FW);
 
 static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
@@ -1080,12 +1076,88 @@ static void ath9k_hif_usb_firmware_fail(struct 
hif_device_usb *hif_dev)
device_unlock(parent);
 }
 
+static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void 
*context);
+
+/* taken from iwlwifi */
+static int ath9k_hif_request_firmware(struct hif_device_usb *hif_dev,
+ bool first)
+{
+   char index[8], *chip;
+   int ret;
+
+   if (first) {
+   if (htc_use_dev_fw) {
+   hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX + 1;
+   sprintf(index, %s, dev);
+   } else {
+   hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX;
+   sprintf(index, %d, hif_dev-fw_minor_index);
+   }
+   } else {
+   hif_dev-fw_minor_index--;
+   sprintf(index, %d, hif_dev-fw_minor_index);
+   }
+
+   /* test for FW 1.3 */
+   if (MAJOR_VERSION_REQ == 1  hif_dev-fw_minor_index == 3) {
+   const char *filename;
+
+   if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+   filename = FIRMWARE_AR7010_1_1;
+   else
+   filename = FIRMWARE_AR9271;
+
+   /* expected fw locations:
+* - htc_9271.fw   (stable version 1.3, depricated)
+*/
+   snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+%s, filename);
+
+   } else if (hif_dev-fw_minor_index  FIRMWARE_MINOR_IDX_MIN) {
+   dev_err(hif_dev-udev-dev, no suitable firmware found!\n);
+
+   return -ENOENT;
+   } else {
+   if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+   chip = 7010;
+   else
+   chip = 9271;
+
+   /* expected fw locations:
+* - ath9k_htc/htc_9271-1.dev.0.fw (development version)
+* - ath9k_htc/htc_9271-1.4.0.fw   (stable version)
+*/
+   snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+%s/htc_%s-%d.%s.0.fw, HTC_FW_PATH,
+chip, MAJOR_VERSION_REQ, index);
+   }
+
+   ret = request_firmware_nowait(THIS_MODULE, true, hif_dev-fw_name,
+ hif_dev-udev-dev, GFP_KERNEL,
+ hif_dev, ath9k_hif_usb_firmware_cb);
+   if (ret) {
+   dev_err(hif_dev-udev-dev,
+   ath9k_htc: Async request for firmware %s failed\n,
+   hif_dev-fw_name);
+   return ret;
+   }
+
+   dev_info(hif_dev-udev-dev, ath9k_htc: Firmware %s requested\n,
+hif_dev-fw_name);
+
+   return ret;
+}
+
 static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
 {
struct hif_device_usb *hif_dev = context;
int ret;
 
if (!fw) {
+   ret = ath9k_hif_request_firmware(hif_dev

Re: ath9k_htc: virtual interfaces, AP connection drop kernel warning

[Oleksij Rempel]

Hi,

Am 08.07.2015 um 17:28 schrieb Rolf Anderegg:
 I am having trouble with the following setup using ath9k_htc (AR9271): I
 would like to setup two virtual interfaces on a TP-Link Wireless USB
 adapter (TL-WN722N).
 
 ath0: AP (access point/master mode) with hostapd [1], on bridge br0
 ath1: STA (station/managed mode) with wpa_supplicant
 
 AP works fine when STA is omitted (or wpa_supplicant is stopped). But
 when I try to operate both simultaneously (on the same channel), while
 the STA is up and stable, the AP can no longer hold a connection for
 longer than a few seconds. The hostapd syslogs either say that
 connection is dropped due to inactivity or failure to authenticate.
 Also, sometimes a slowpath kernel warning is dumped [2].
 Kernel version is 3.12.10-rt15 (more environment info: [3]).
 
 When I try the same setup with a D-Link PCI card (DWL-G520) running with
 ath5k, AP and STA work smoothly side by side. So I'm wondering whether
 there are any known limitations or pitfalls when using virtual
 interfaces with ath9k_htc?
 
 Any hints or ideas would be greatly appreciated.
 Cheers,

First of all, you are using ancient kernel and firmware. Please update
it. Firmware should be at leas 1.4 and kernel probably 4.1 or later. i'm
not sure which include patch with support of RMW command introduced by
new FW.

Then you can try to disable LED blinking which is stealing your usb
bandwidth.

 
 
 [1] hostapd.conf:
 interface=ath0
 bridge=br0
 driver=nl80211
 ssid=MAN301-0099_LAN
 hw_mode=g
 channel=8
 auth_algs=3
 wmm_enabled=1
 wpa=3
 wpa_psk_file=/etc/hostapd.wpa_psk
 wpa_key_mgmt=WPA-PSK
 wpa_pairwise=TKIP CCMP
 
 
 [2] kernel warning:
 [ 4142.857848] [ cut here ]
 [ 4142.857917] WARNING: CPU: 0 PID: 19211 at net/mac80211/agg-tx.c:699 
 ieee80211_start_tx_ba_cb+0xa5/0xf8 [mac80211]()
 [ 4142.857970] Modules linked in: bridge stp llc ipv6 snd_seq_dummy ppdev 
 snd_dice snd_firewire_lib snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm 
 snd_page_alloc snd_seq_oss snd_seq_midi ath9k_htc snd_rawmidi ath9k_common 
 ath9k_hw snd_seq_midi_event ath joydev snd_seq mac80211 microcode 
 snd_seq_device snd_timer cfg80211 rfkill snd serio_raw soundcore lpc_ich 
 mfd_core parport_pc fuse w83627hf hwmon_vid shpchp coretemp lp parport 
 firewire_ohci ata_generic firewire_core pata_acpi r8169 mii
 [ 4142.857977] CPU: 0 PID: 19211 Comm: kworker/u8:0 Tainted: GW
 3.12.10-rt15 #2
 [ 4142.857980] Hardware name:  /D510MO, BIOS 
 MOPNV10N.86A.0516.2011.0331.1730 03/31/2011
 [ 4142.858051] Workqueue: phy0 ieee80211_iface_work [mac80211]
 [ 4142.858063]    f625beb8 c15dba8f  f625bed0 
 c102d255 f95cfb0c
 [ 4142.858073]   f2e62534 f27f3ad0 f625bee0 c102d2e1 0009 
  f625bf00
 [ 4142.858082]  f95cfb0c f3f48c18 f2e62360 f27f3800 f26bfc80 f3f48c00 
 f3fb28c0 f625bf28
 [ 4142.858084] Call Trace:
 [ 4142.858096]  [c15dba8f] dump_stack+0x49/0x80
 [ 4142.858104]  [c102d255] warn_slowpath_common+0x66/0x7d
 [ 4142.858146]  [f95cfb0c] ? ieee80211_start_tx_ba_cb+0xa5/0xf8 [mac80211]
 [ 4142.858152]  [c102d2e1] warn_slowpath_null+0x14/0x18
 [ 4142.858192]  [f95cfb0c] ieee80211_start_tx_ba_cb+0xa5/0xf8 [mac80211]
 [ 4142.858234]  [f95d3183] ieee80211_iface_work+0x99/0x253 [mac80211]
 [ 4142.858243]  [c1040112] process_one_work+0x146/0x253
 [ 4142.858249]  [c10405ab] worker_thread+0x137/0x1d9
 [ 4142.858255]  [c1040474] ? rescuer_thread+0x22f/0x22f
 [ 4142.858260]  [c1044a1e] kthread+0x74/0x79
 [ 4142.858268]  [c15e4e77] ret_from_kernel_thread+0x1b/0x28
 [ 4142.858274]  [c10449aa] ? __kthread_parkme+0x59/0x59
 [ 4142.858289] ---[ end trace 0003 ]---
 
 
 [3] environment summary:
 :~$ uname -srvmpio
 Linux 3.12.10-rt15 #2 SMP PREEMPT RT Tue Jun 9 16:17:55 CEST 2015 i686 i686 
 i686 GNU/Linux
 
 :~$ lsusb -s 1:3
 Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
 
 :~$ wpa_supplicant -v
 wpa_supplicant v2.4
 
 :~$ sudo wpa_cli status
 Selected interface 'ath1'
 bssid=b8:a3:86:14:d3:ee
 freq=2447
 ssid=Kakofon
 id=0
 id_str=ath1
 mode=station
 pairwise_cipher=CCMP
 group_cipher=TKIP
 key_mgmt=WPA2-PSK
 wpa_state=COMPLETED
 ip_address=192.168.1.102
 address=c6:4a:00:1b:c2:98
 
 :~$ hostapd -v
 hostapd v2.4
 
 :~$ sudo hostapd_cli status
 Selected interface 'ath0'
 state=ENABLED
 phy=phy0
 freq=2447
 num_sta_non_erp=0
 num_sta_no_short_slot_time=0
 num_sta_no_short_preamble=0
 olbc=0
 num_sta_ht_no_gf=0
 num_sta_no_ht=0
 num_sta_ht_20_mhz=0
 num_sta_ht40_intolerant=0
 olbc_ht=0
 ht_op_mode=0x0
 cac_time_seconds=0
 cac_time_left_seconds=N/A
 channel=8
 secondary_channel=0
 ieee80211n=0
 ieee80211ac=0
 vht_oper_chwidth=0
 vht_oper_centr_freq_seg0_idx=0
 vht_oper_centr_freq_seg1_idx=0
 bss[0]=ath0
 bssid[0]=c0:4a:00:1b:c2:98
 ssid[0]=MAN301-0099_LAN
 num_sta[0]=0
 
 :~$ cat /sys/module/ath9k_htc/parameters/nohwcrypt
 1
 
 :~$ lsmod | grep ath9k
 ath9k_htc  46002  0
 ath9k_common2153  1 ath9k_htc
 

Re: [PATCH v2] ath9k_htc: introduce support for different fw versions

[Oleksij Rempel]

Am 03.07.2015 um 12:53 schrieb Kalle Valo:
 Oleksij Rempel li...@rempel-privat.de writes:
 
 Any updates here?
 
 What do you mean? If you are asking why the patch isn't applied it's
 because merge window is still open. I'll start applying patches after
 net-next is open again.

Ouch.. i was in my own world :)

Sorry,
-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] ath9k_htc: introduce support for different fw versions

[Oleksij Rempel]

Any updates here?

Am 15.06.2015 um 20:58 schrieb Oleksij Rempel:
 Current kernel support only one fw name with theoretically only one
 fw version. By replacing fw with other version we will break compatibility
 with older kernels.
 
 To avoid this kind of regression this patch will reuse fw version model
 from iwlwifi driver.
 
 Signed-off-by: Oleksij Rempel li...@rempel-privat.de
 ---
  drivers/net/wireless/ath/ath9k/hif_usb.c  | 106 
 --
  drivers/net/wireless/ath/ath9k/hif_usb.h  |  21 -
  drivers/net/wireless/ath/ath9k/htc_drv_init.c |   4 +
  3 files changed, 105 insertions(+), 26 deletions(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
 b/drivers/net/wireless/ath/ath9k/hif_usb.c
 index 10c02f5..165dd20 100644
 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
 +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
 @@ -17,12 +17,8 @@
  #include asm/unaligned.h
  #include htc.h
  
 -/* identify firmware images */
 -#define FIRMWARE_AR7010_1_1 htc_7010.fw
 -#define FIRMWARE_AR9271 htc_9271.fw
 -
 -MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
 -MODULE_FIRMWARE(FIRMWARE_AR9271);
 +MODULE_FIRMWARE(HTC_7010_MODULE_FW);
 +MODULE_FIRMWARE(HTC_9271_MODULE_FW);
  
  static struct usb_device_id ath9k_hif_usb_ids[] = {
   { USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
 @@ -1080,12 +1076,88 @@ static void ath9k_hif_usb_firmware_fail(struct 
 hif_device_usb *hif_dev)
   device_unlock(parent);
  }
  
 +static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void 
 *context);
 +
 +/* taken from iwlwifi */
 +static int ath9k_hif_request_firmware(struct hif_device_usb *hif_dev,
 +   bool first)
 +{
 + char index[8], *chip;
 + int ret;
 +
 + if (first) {
 + if (htc_use_dev_fw) {
 + hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX + 1;
 + sprintf(index, %s, dev);
 + } else {
 + hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX;
 + sprintf(index, %d, hif_dev-fw_minor_index);
 + }
 + } else {
 + hif_dev-fw_minor_index--;
 + sprintf(index, %d, hif_dev-fw_minor_index);
 + }
 +
 + /* test for FW 1.3 */
 + if (MAJOR_VERSION_REQ == 1  hif_dev-fw_minor_index == 3) {
 + const char *filename;
 +
 + if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
 + filename = FIRMWARE_AR7010_1_1;
 + else
 + filename = FIRMWARE_AR9271;
 +
 + /* expected fw locations:
 +  * - htc_9271.fw   (stable version 1.3, depricated)
 +  */
 + snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
 +  %s, filename);
 +
 + } else if (hif_dev-fw_minor_index  FIRMWARE_MINOR_IDX_MIN) {
 + dev_err(hif_dev-udev-dev, no suitable firmware found!\n);
 +
 + return -ENOENT;
 + } else {
 + if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
 + chip = 7010;
 + else
 + chip = 9271;
 +
 + /* expected fw locations:
 +  * - ath9k_htc/htc_9271-1.dev.0.fw (development version)
 +  * - ath9k_htc/htc_9271-1.4.0.fw   (stable version)
 +  */
 + snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
 +  %s/htc_%s-%d.%s.0.fw, HTC_FW_PATH,
 +  chip, MAJOR_VERSION_REQ, index);
 + }
 +
 + ret = request_firmware_nowait(THIS_MODULE, true, hif_dev-fw_name,
 +   hif_dev-udev-dev, GFP_KERNEL,
 +   hif_dev, ath9k_hif_usb_firmware_cb);
 + if (ret) {
 + dev_err(hif_dev-udev-dev,
 + ath9k_htc: Async request for firmware %s failed\n,
 + hif_dev-fw_name);
 + return ret;
 + }
 +
 + dev_info(hif_dev-udev-dev, ath9k_htc: Firmware %s requested\n,
 +  hif_dev-fw_name);
 +
 + return ret;
 +}
 +
  static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void 
 *context)
  {
   struct hif_device_usb *hif_dev = context;
   int ret;
  
   if (!fw) {
 + ret = ath9k_hif_request_firmware(hif_dev, false);
 + if (!ret)
 + return;
 +
   dev_err(hif_dev-udev-dev,
   ath9k_htc: Failed to get firmware %s\n,
   hif_dev-fw_name);
 @@ -1215,27 +1287,11 @@ static int ath9k_hif_usb_probe(struct usb_interface 
 *interface,
  
   init_completion(hif_dev-fw_done);
  
 - /* Find out which firmware to load */
 -
 - if (IS_AR7010_DEVICE(id-driver_info))
 - hif_dev-fw_name = FIRMWARE_AR7010_1_1;
 - else
 - hif_dev-fw_name = FIRMWARE_AR9271;
 -
 - ret = request_firmware_nowait(THIS_MODULE, true, hif_dev-fw_name

[PATCH] ath9k_htc: introduce support for different fw versions

[Oleksij Rempel]

Current kernel support only one fw name with theoretically only one
fw version. By replacing fw with other version we will break compatibility
with older kernels.

To avoid this kind of regression this patch will reuse fw version model
from iwlwifi driver.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/hif_usb.c  | 102 --
 drivers/net/wireless/ath/ath9k/hif_usb.h  |  13 +++-
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |   4 +
 3 files changed, 95 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 10c02f5..18407f2 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -17,10 +17,6 @@
 #include asm/unaligned.h
 #include htc.h
 
-/* identify firmware images */
-#define FIRMWARE_AR7010_1_1 htc_7010.fw
-#define FIRMWARE_AR9271 htc_9271.fw
-
 MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
 MODULE_FIRMWARE(FIRMWARE_AR9271);
 
@@ -1080,12 +1076,88 @@ static void ath9k_hif_usb_firmware_fail(struct 
hif_device_usb *hif_dev)
device_unlock(parent);
 }
 
+static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void 
*context);
+
+/* taken from iwlwifi */
+static int ath9k_hif_request_firmware(struct hif_device_usb *hif_dev,
+ bool first)
+{
+   char index[8], *chip;
+   int ret;
+
+   if (first) {
+   if (htc_use_dev_fw) {
+   hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX + 1;
+   sprintf(index, %s, dev);
+   } else {
+   hif_dev-fw_minor_index = FIRMWARE_MINOR_IDX_MAX;
+   sprintf(index, %d, hif_dev-fw_minor_index);
+   }
+   } else {
+   hif_dev-fw_minor_index--;
+   sprintf(index, %d, hif_dev-fw_minor_index);
+   }
+
+   /* test for FW 1.3 */
+   if (MAJOR_VERSION_REQ == 1  hif_dev-fw_minor_index == 3) {
+   const char *filename;
+
+   if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+   filename = FIRMWARE_AR7010_1_1;
+   else
+   filename = FIRMWARE_AR9271;
+
+   /* expected fw locations:
+* - htc_9271.fw   (stable version 1.3, depricated)
+*/
+   snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+%s, filename);
+
+   } else if (hif_dev-fw_minor_index  FIRMWARE_MINOR_IDX_MIN) {
+   dev_err(hif_dev-udev-dev, no suitable firmware found!\n);
+
+   return -ENOENT;
+   } else {
+   if (IS_AR7010_DEVICE(hif_dev-usb_device_id-driver_info))
+   chip = 7010;
+   else
+   chip = 9271;
+
+   /* expected fw locations:
+* - ath9k_htc/htc_9271-1.dev.0.fw (development version)
+* - ath9k_htc/htc_9271-1.4.0.fw   (stable version)
+*/
+   snprintf(hif_dev-fw_name, sizeof(hif_dev-fw_name),
+ath9k_htc/htc_%s-%d.%s.0.fw,
+chip, MAJOR_VERSION_REQ, index);
+   }
+
+   ret = request_firmware_nowait(THIS_MODULE, true, hif_dev-fw_name,
+ hif_dev-udev-dev, GFP_KERNEL,
+ hif_dev, ath9k_hif_usb_firmware_cb);
+   if (ret) {
+   dev_err(hif_dev-udev-dev,
+   ath9k_htc: Async request for firmware %s failed\n,
+   hif_dev-fw_name);
+   return ret;
+   }
+
+   dev_info(hif_dev-udev-dev, ath9k_htc: Firmware %s requested\n,
+hif_dev-fw_name);
+
+   return ret;
+}
+
 static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
 {
struct hif_device_usb *hif_dev = context;
int ret;
 
if (!fw) {
+   ret = ath9k_hif_request_firmware(hif_dev, false);
+   if (!ret)
+   return;
+
dev_err(hif_dev-udev-dev,
ath9k_htc: Failed to get firmware %s\n,
hif_dev-fw_name);
@@ -1215,27 +1287,11 @@ static int ath9k_hif_usb_probe(struct usb_interface 
*interface,
 
init_completion(hif_dev-fw_done);
 
-   /* Find out which firmware to load */
-
-   if (IS_AR7010_DEVICE(id-driver_info))
-   hif_dev-fw_name = FIRMWARE_AR7010_1_1;
-   else
-   hif_dev-fw_name = FIRMWARE_AR9271;
-
-   ret = request_firmware_nowait(THIS_MODULE, true, hif_dev-fw_name,
- hif_dev-udev-dev, GFP_KERNEL,
- hif_dev, ath9k_hif_usb_firmware_cb);
-   if (ret) {
-   dev_err(hif_dev-udev-dev,
-   ath9k_htc: Async

Re: [PATCH] ath9k_htc: add support of channel switch

[Oleksij Rempel]

Hi,

Thank you for your work.
How can i test this patch?

Am 09.06.2015 um 09:59 schrieb Chun-Yeow Yeoh:
 Add the support of channel switching functionality, similar
 to ath9k support.
 
 Tested with TP-Link TL-WN722N and TL-WN821N.
 
 Signed-off-by: Chun-Yeow Yeoh yeohchuny...@gmail.com
 ---
  drivers/net/wireless/ath/ath9k/htc.h|  2 ++
  drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 19 +++
  drivers/net/wireless/ath/ath9k/htc_drv_init.c   |  3 ++-
  drivers/net/wireless/ath/ath9k/htc_drv_main.c   | 17 +
  4 files changed, 40 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/net/wireless/ath/ath9k/htc.h 
 b/drivers/net/wireless/ath/ath9k/htc.h
 index 5dbc617..16dff4b 100644
 --- a/drivers/net/wireless/ath/ath9k/htc.h
 +++ b/drivers/net/wireless/ath/ath9k/htc.h
 @@ -531,6 +531,7 @@ struct ath9k_htc_priv {
   struct ath9k_debug debug;
  #endif
   struct mutex mutex;
 + struct ieee80211_vif *csa_vif;
  };
  
  static inline void ath_read_cachesize(struct ath_common *common, int *csz)
 @@ -584,6 +585,7 @@ void ath9k_htc_tx_drain(struct ath9k_htc_priv *priv);
  void ath9k_htc_txstatus(struct ath9k_htc_priv *priv, void *wmi_event);
  void ath9k_tx_failed_tasklet(unsigned long data);
  void ath9k_htc_tx_cleanup_timer(unsigned long data);
 +bool ath9k_htc_csa_is_finished(struct ath9k_htc_priv *priv);
  
  int ath9k_rx_init(struct ath9k_htc_priv *priv);
  void ath9k_rx_cleanup(struct ath9k_htc_priv *priv);
 diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c 
 b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
 index e8b6ec3..e6bcb4c 100644
 --- a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
 +++ b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
 @@ -257,6 +257,8 @@ static void ath9k_htc_send_beacon(struct ath9k_htc_priv 
 *priv,
   }
  
   spin_unlock_bh(priv-beacon_lock);
 +
 + ath9k_htc_csa_is_finished(priv);
  }
  
  static int ath9k_htc_choose_bslot(struct ath9k_htc_priv *priv,
 @@ -503,3 +505,20 @@ void ath9k_htc_beacon_reconfig(struct ath9k_htc_priv 
 *priv)
   return;
   }
  }
 +
 +bool ath9k_htc_csa_is_finished(struct ath9k_htc_priv *priv)
 +{
 + struct ieee80211_vif *vif;
 +
 + vif = priv-csa_vif;
 + if (!vif || !vif-csa_active)
 + return false;
 +
 + if (!ieee80211_csa_is_complete(vif))
 + return false;
 +
 + ieee80211_csa_finish(vif);
 +
 + priv-csa_vif = NULL;
 + return true;
 +}
 diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
 b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
 index 7468562..9569010 100644
 --- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
 +++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
 @@ -744,7 +744,8 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv 
 *priv,
   hw-wiphy-flags = ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
  
   hw-wiphy-flags |= WIPHY_FLAG_IBSS_RSN |
 - WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
 + WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
 + WIPHY_FLAG_HAS_CHANNEL_SWITCH;
  
   hw-wiphy-flags |= WIPHY_FLAG_SUPPORTS_TDLS;
  
 diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c 
 b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
 index b71f307..dab1323 100644
 --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
 +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
 @@ -1134,6 +1134,9 @@ static void ath9k_htc_remove_interface(struct 
 ieee80211_hw *hw,
   priv-nvifs--;
   priv-vif_slot = ~(1  avp-index);
  
 + if (priv-csa_vif == vif)
 + priv-csa_vif = NULL;
 +
   ath9k_htc_remove_station(priv, vif, NULL);
  
   DEC_VIF(priv, vif-type);
 @@ -1841,6 +1844,19 @@ static int ath9k_htc_get_antenna(struct ieee80211_hw 
 *hw, u32 *tx_ant,
   return 0;
  }
  
 +static void ath9k_htc_channel_switch_beacon(struct ieee80211_hw *hw,
 + struct ieee80211_vif *vif,
 + struct cfg80211_chan_def *chandef)
 +{
 + struct ath9k_htc_priv *priv = hw-priv;
 +
 + /* mac80211 does not support CSA in multi-if cases (yet) */
 + if (WARN_ON(priv-csa_vif))
 + return;
 +
 + priv-csa_vif = vif;
 +}
 +
  struct ieee80211_ops ath9k_htc_ops = {
   .tx = ath9k_htc_tx,
   .start  = ath9k_htc_start,
 @@ -1867,6 +1883,7 @@ struct ieee80211_ops ath9k_htc_ops = {
   .set_bitrate_mask   = ath9k_htc_set_bitrate_mask,
   .get_stats  = ath9k_htc_get_stats,
   .get_antenna= ath9k_htc_get_antenna,
 + .channel_switch_beacon  = ath9k_htc_channel_switch_beacon,
  
  #ifdef CONFIG_ATH9K_HTC_DEBUGFS
   .get_et_sset_count  = ath9k_htc_get_et_sset_count,
 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Issues with mesh networking path detection

[Oleksij Rempel]

Am 21.05.2015 um 19:11 schrieb Jason Scatena:
 Hello all,
 
 I am attempting to set up a mesh network between 4 computers with
 Atheros 9271 based usb wifi dongles using the ath9k driver.
 
 I followed the guide at: https://github.com/o11s/open80211s/wiki/HOWTO
 
 to set up the network.
 
 When I get all of the computers up and configured they all see each other.
 The command iw dev mesh station dump shows all the nodes in the
 area. However the path selection doesn't seem to work at all. For
 instance the command iw dev mesh mpath dump returns nothing. However
 if I manually add arp entries using the arp command they show up in
 the mpath dump.
 
 I am willing to do whatever to troubleshoot however there is very
 little documentation that I have been able to find on trouble shooting
 these issues. I would also be able to provide a pcap file of the nodes
 coming online.
 
 I'm new to the wireless world but have C coding experience and would
 be willing to put in the time to learn.


Hi,

i don't think there are people who will know the answer without research
and reading the code.

Since you are willing to learn any way, fallow the codepath and find out
what is happening. We would be happy to have more wifi experts :)

Find out what executed in kernel if you start this command: iw dev mesh
mpath dump. I assume it is starting somewhere in linux/net/wireless/mesh.c

Use printk() placed in code or use gdb+openocd+jtag if you use some arm
or mips system.


 Best,
 Jason Scatena
 --
 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
 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ath9k_htc: check seq number instead of cmd id for timeout

[Oleksij Rempel]

Hi Kalle,

can you please apply this patch.

Am 06.04.2015 um 08:33 schrieb Fred Chou:
 Hi all,
 
 May I have an update on the patch status please?
 
 Thanks and regards,
 Fred
 
 On 13/3/2015 4:32 PM, Fred Chou wrote:
 From: Fred Chou fred.chou...@gmail.com

 As the driver may send multiple wmi commands with identical cmd id,
 it is more robust to check seq number for timeout instead.

 Signed-off-by: Fred Chou fred.chou...@gmail.com
 ---
  drivers/net/wireless/ath/ath9k/wmi.c | 12 ++--
  drivers/net/wireless/ath/ath9k/wmi.h |  2 +-
  2 files changed, 7 insertions(+), 7 deletions(-)

 diff --git a/drivers/net/wireless/ath/ath9k/wmi.c 
 b/drivers/net/wireless/ath/ath9k/wmi.c
 index 65c8894..aba909f 100644
 --- a/drivers/net/wireless/ath/ath9k/wmi.c
 +++ b/drivers/net/wireless/ath/ath9k/wmi.c
 @@ -224,7 +224,7 @@ static void ath9k_wmi_ctrl_rx(void *priv, struct sk_buff 
 *skb,
  
  /* Check if there has been a timeout. */
  spin_lock(wmi-wmi_lock);
 -if (cmd_id != wmi-last_cmd_id) {
 +if (be16_to_cpu(hdr-seq_no) != wmi-last_seq_id) {
  spin_unlock(wmi-wmi_lock);
  goto free_skb;
  }
 @@ -272,11 +272,16 @@ static int ath9k_wmi_cmd_issue(struct wmi *wmi,
 enum wmi_cmd_id cmd, u16 len)
  {
  struct wmi_cmd_hdr *hdr;
 +unsigned long flags;
  
  hdr = (struct wmi_cmd_hdr *) skb_push(skb, sizeof(struct wmi_cmd_hdr));
  hdr-command_id = cpu_to_be16(cmd);
  hdr-seq_no = cpu_to_be16(++wmi-tx_seq_id);
  
 +spin_lock_irqsave(wmi-wmi_lock, flags);
 +wmi-last_seq_id = wmi-tx_seq_id;
 +spin_unlock_irqrestore(wmi-wmi_lock, flags);
 +
  return htc_send_epid(wmi-htc, skb, wmi-ctrl_epid);
  }
  
 @@ -292,7 +297,6 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id 
 cmd_id,
  struct sk_buff *skb;
  u8 *data;
  int time_left, ret = 0;
 -unsigned long flags;
  
  if (ah-ah_flags  AH_UNPLUGGED)
  return 0;
 @@ -320,10 +324,6 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id 
 cmd_id,
  wmi-cmd_rsp_buf = rsp_buf;
  wmi-cmd_rsp_len = rsp_len;
  
 -spin_lock_irqsave(wmi-wmi_lock, flags);
 -wmi-last_cmd_id = cmd_id;
 -spin_unlock_irqrestore(wmi-wmi_lock, flags);
 -
  ret = ath9k_wmi_cmd_issue(wmi, skb, cmd_id, cmd_len);
  if (ret)
  goto out;
 diff --git a/drivers/net/wireless/ath/ath9k/wmi.h 
 b/drivers/net/wireless/ath/ath9k/wmi.h
 index 0db37f2..2aad6dc 100644
 --- a/drivers/net/wireless/ath/ath9k/wmi.h
 +++ b/drivers/net/wireless/ath/ath9k/wmi.h
 @@ -143,7 +143,7 @@ struct wmi {
  enum htc_endpoint_id ctrl_epid;
  struct mutex op_mutex;
  struct completion cmd_wait;
 -enum wmi_cmd_id last_cmd_id;
 +u16 last_seq_id;
  struct sk_buff_head wmi_event_queue;
  struct tasklet_struct wmi_event_tasklet;
  u16 tx_seq_id;

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


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 00/18] reduce some of ath9k_htc performance problems

[Oleksij Rempel]

Hello all,
Any updates here?

Am 22.03.2015 um 19:29 schrieb Oleksij Rempel:
 This patchset adds new WMI_RMW handler to reduce some of usb related
 performance problems.
 
 Oleksij Rempel (18):
   ath9k_htc: add new WMI_REG_RMW_CMDID command
   ath9k: ar9271_hw_pa_cal - use defs instead of magin numbers
   ath9k: ar9271_hw_pa_cal: use proper makroses.
   ath9k: ar9271_hw_pa_cal: use RMW buffer
   ath9k: add multi_read to be compatible with ath9k_htc
   ath9k: add new function ath9k_hw_read_array
   ath9k: ar9271_hw_pa_cal: use REG_READ_ARRAY
   ath9k: use one shot read in ath9k_hw_update_mibstats
   ath9k: ath9k_hw_loadnf: use REG_RMW
   ath9k: write buffer related optimisation in ar5008_hw_set_channel_regs
   ath9k: ath9k_hw_set_4k_power_cal_tabl: use rmw buffer
   ath9k: use rmw buffer in ath9k_hw_set_operating_mode and
 ath9k_hw_reset
   ath9k: ath9k_hw_4k_set_board_values: use rmw buffer
   ath9k: ath9k_hw_analog_shift_rmw: use REG_RMW
   ath9k: ath9k_hw_4k_set_board_values: use rmw buffer
   ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_gain
   ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_board_values
   ath9k: use REG_RMW and rmw buffer in ath9k_hw_def_set_gain
 
  drivers/net/wireless/ath/ath.h|   3 +
  drivers/net/wireless/ath/ath9k/ani.c  |  20 +++-
  drivers/net/wireless/ath/ath9k/ar5008_phy.c   |   5 +-
  drivers/net/wireless/ath/ath9k/ar9002_calib.c |  77 +++---
  drivers/net/wireless/ath/ath9k/calib.c|  19 ++--
  drivers/net/wireless/ath/ath9k/eeprom.c   |   7 +-
  drivers/net/wireless/ath/ath9k/eeprom_4k.c|  36 ---
  drivers/net/wireless/ath/ath9k/eeprom_def.c   |  34 +++---
  drivers/net/wireless/ath/ath9k/htc.h  |   5 +
  drivers/net/wireless/ath/ath9k/htc_drv_init.c | 142 
 --
  drivers/net/wireless/ath/ath9k/hw.c   |  34 ++
  drivers/net/wireless/ath/ath9k/hw.h   |  15 +++
  drivers/net/wireless/ath/ath9k/init.c |  11 ++
  drivers/net/wireless/ath/ath9k/wmi.c  |   3 +
  drivers/net/wireless/ath/ath9k/wmi.h  |  16 +++
  15 files changed, 324 insertions(+), 103 deletions(-)
 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

[PATCH v3 09/18] ath9k: ath9k_hw_loadnf: use REG_RMW

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/calib.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c 
b/drivers/net/wireless/ath/ath9k/calib.c
index e200a6e..3e2e24e 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -238,7 +238,6 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
 {
struct ath9k_nfcal_hist *h = NULL;
unsigned i, j;
-   int32_t val;
u8 chainmask = (ah-rxchainmask  3) | ah-rxchainmask;
struct ath_common *common = ath9k_hw_common(ah);
s16 default_nf = ath9k_hw_get_default_nf(ah, chan);
@@ -246,6 +245,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
if (ah-caldata)
h = ah-caldata-nfCalHist;
 
+   ENABLE_REG_RMW_BUFFER(ah);
for (i = 0; i  NUM_NF_READINGS; i++) {
if (chainmask  (1  i)) {
s16 nfval;
@@ -258,10 +258,8 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct 
ath9k_channel *chan)
else
nfval = default_nf;
 
-   val = REG_READ(ah, ah-nf_regs[i]);
-   val = 0xFE00;
-   val |= (((u32) nfval  1)  0x1ff);
-   REG_WRITE(ah, ah-nf_regs[i], val);
+   REG_RMW(ah, ah-nf_regs[i],
+   (((u32) nfval  1)  0x1ff), 0x1ff);
}
}
 
@@ -274,6 +272,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL,
AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
+   REG_RMW_BUFFER_FLUSH(ah);
 
/*
 * Wait for load to complete, should be fast, a few 10s of us.
@@ -309,19 +308,17 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct 
ath9k_channel *chan)
 * by the median we just loaded.  This will be initial (and max) value
 * of next noise floor calibration the baseband does.
 */
-   ENABLE_REGWRITE_BUFFER(ah);
+   ENABLE_REG_RMW_BUFFER(ah);
for (i = 0; i  NUM_NF_READINGS; i++) {
if (chainmask  (1  i)) {
if ((i = AR5416_MAX_CHAINS)  !IS_CHAN_HT40(chan))
continue;
 
-   val = REG_READ(ah, ah-nf_regs[i]);
-   val = 0xFE00;
-   val |= (((u32) (-50)  1)  0x1ff);
-   REG_WRITE(ah, ah-nf_regs[i], val);
+   REG_RMW(ah, ah-nf_regs[i],
+   (((u32) (-50)  1)  0x1ff), 0x1ff);
}
}
-   REGWRITE_BUFFER_FLUSH(ah);
+   REG_RMW_BUFFER_FLUSH(ah);
 
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 v3 17/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_board_values

[Oleksij Rempel]

replace REG_WRITE to REG_RMW and place every thing in one
RMW buffer.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 38dc965..4773da6 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -1037,17 +1037,17 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
}
REG_RMW_BUFFER_FLUSH(ah);
 
-
+   ENABLE_REG_RMW_BUFFER(ah);
REG_RMW_FIELD(ah, AR_PHY_SETTLING, AR_PHY_SETTLING_SWITCH,
  pModal-switchSettling);
REG_RMW_FIELD(ah, AR_PHY_DESIRED_SZ, AR_PHY_DESIRED_SZ_ADC,
  pModal-adcDesiredSize);
 
-   REG_WRITE(ah, AR_PHY_RF_CTL4,
- SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAA_OFF) |
- SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAB_OFF) |
- SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAA_ON)  |
- SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAB_ON));
+   REG_RMW(ah, AR_PHY_RF_CTL4,
+   SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAA_OFF) |
+   SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAB_OFF) |
+   SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAA_ON)  |
+   SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAB_ON), 0);
 
REG_RMW_FIELD(ah, AR_PHY_RF_CTL3, AR_PHY_TX_END_TO_A2_RX_ON,
  pModal-txEndToRxOn);
@@ -1076,6 +1076,8 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
  pModal-swSettleHt40);
}
 
+   REG_RMW_BUFFER_FLUSH(ah);
+
bb_desired_scale = (pModal-bb_scale_smrt_antenna 
EEP_4K_BB_DESIRED_SCALE_MASK);
if ((pBase-txGainType == 0)  (bb_desired_scale != 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 v3 07/18] ath9k: ar9271_hw_pa_cal: use REG_READ_ARRAY

[Oleksij Rempel]

insted of reading each register separatly
and waste 4ms on each operation, we can
use one shot read.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 62a2314..50fcd34 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -440,8 +440,7 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
{ AR9285_AN_RF2G3, 0 },
};
 
-   for (i = 0; i  ARRAY_SIZE(regList); i++)
-   regList[i][1] = REG_READ(ah, regList[i][0]);
+   REG_READ_ARRAY(ah, regList, ARRAY_SIZE(regList));
 
ENABLE_REG_RMW_BUFFER(ah);
/* 7834, b1=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 v3 15/18] ath9k: ath9k_hw_4k_set_board_values: use rmw buffer

[Oleksij Rempel]

it will reduce exution time from 14ms to 2ms on ar9271

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 0600562..291c1d1 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -930,6 +930,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw *ah,
}
}
 
+   ENABLE_REG_RMW_BUFFER(ah);
if (AR_SREV_9271(ah)) {
ath9k_hw_analog_shift_rmw(ah,
  AR9285_AN_RF2G3,
@@ -1034,6 +1035,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
  AR9285_AN_RF2G4_DB2_4_S,
  db2[4]);
}
+   REG_RMW_BUFFER_FLUSH(ah);
 
 
REG_RMW_FIELD(ah, AR_PHY_SETTLING, AR_PHY_SETTLING_SWITCH,
-- 
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 v3 13/18] ath9k: ath9k_hw_4k_set_board_values: use rmw buffer

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index fc54fc7..0600562 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -1082,6 +1082,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
mask = BIT(0)|BIT(5)|BIT(10)|BIT(15)|BIT(20)|BIT(25);
pwrctrl = mask * bb_desired_scale;
clr = mask * 0x1f;
+   ENABLE_REG_RMW_BUFFER(ah);
REG_RMW(ah, AR_PHY_TX_PWRCTRL8, pwrctrl, clr);
REG_RMW(ah, AR_PHY_TX_PWRCTRL10, pwrctrl, clr);
REG_RMW(ah, AR_PHY_CH0_TX_PWRCTRL12, pwrctrl, clr);
@@ -1096,6 +1097,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
clr = mask * 0x1f;
REG_RMW(ah, AR_PHY_CH0_TX_PWRCTRL11, pwrctrl, clr);
REG_RMW(ah, AR_PHY_CH0_TX_PWRCTRL13, pwrctrl, clr);
+   REG_RMW_BUFFER_FLUSH(ah);
}
 }
 
-- 
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 v3 05/18] ath9k: add multi_read to be compatible with ath9k_htc

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/init.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index 6c6e884..041decc 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -141,6 +141,16 @@ static unsigned int ath9k_ioread32(void *hw_priv, u32 
reg_offset)
return val;
 }
 
+static void ath9k_multi_ioread32(void *hw_priv, u32 *addr,
+u32 *val, u16 count)
+{
+   int i;
+
+   for (i = 0; i  count; i++)
+   val[i] = ath9k_ioread32(hw_priv, addr[i]);
+}
+
+
 static unsigned int __ath9k_reg_rmw(struct ath_softc *sc, u32 reg_offset,
u32 set, u32 clr)
 {
@@ -530,6 +540,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
ah-hw = sc-hw;
ah-hw_version.devid = devid;
ah-reg_ops.read = ath9k_ioread32;
+   ah-reg_ops.multi_read = ath9k_multi_ioread32;
ah-reg_ops.write = ath9k_iowrite32;
ah-reg_ops.rmw = ath9k_reg_rmw;
pCap = ah-caps;
-- 
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 v3 01/18] ath9k_htc: add new WMI_REG_RMW_CMDID command

[Oleksij Rempel]

Since usb bus add extra delay on each request, a command
with read + write requests is too expensive. We can dramtically
reduce usb load by moving this command to firmware.

In my tests, this patch will reduce channel scan time
for about 5-10 seconds.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath.h|   3 +
 drivers/net/wireless/ath/ath9k/htc.h  |   5 +
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 142 --
 drivers/net/wireless/ath/ath9k/hw.h   |  12 +++
 drivers/net/wireless/ath/ath9k/wmi.c  |   3 +
 drivers/net/wireless/ath/ath9k/wmi.h  |  16 +++
 6 files changed, 175 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index 1eebe2e..7e94810 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -131,6 +131,9 @@ struct ath_ops {
void (*enable_write_buffer)(void *);
void (*write_flush) (void *);
u32 (*rmw)(void *, u32 reg_offset, u32 set, u32 clr);
+   void (*enable_rmw_buffer)(void *);
+   void (*rmw_flush) (void *);
+
 };
 
 struct ath_common;
diff --git a/drivers/net/wireless/ath/ath9k/htc.h 
b/drivers/net/wireless/ath/ath9k/htc.h
index 300d367..e82a0d4 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -444,6 +444,10 @@ static inline void ath9k_htc_stop_btcoex(struct 
ath9k_htc_priv *priv)
 #define OP_BT_SCAN BIT(4)
 #define OP_TSF_RESET   BIT(6)
 
+enum htc_op_flags {
+   HTC_FWFLAG_NO_RMW,
+};
+
 struct ath9k_htc_priv {
struct device *dev;
struct ieee80211_hw *hw;
@@ -482,6 +486,7 @@ struct ath9k_htc_priv {
bool reconfig_beacon;
unsigned int rxfilter;
unsigned long op_flags;
+   unsigned long fw_flags;
 
struct ath9k_hw_cal_data caldata;
struct ath_spec_scan_priv spec_priv;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index fd22940..d7beefe 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -376,17 +376,139 @@ static void ath9k_regwrite_flush(void *hw_priv)
mutex_unlock(priv-wmi-multi_write_mutex);
 }
 
-static u32 ath9k_reg_rmw(void *hw_priv, u32 reg_offset, u32 set, u32 clr)
+static void ath9k_reg_rmw_buffer(void *hw_priv,
+u32 reg_offset, u32 set, u32 clr)
+{
+   struct ath_hw *ah = (struct ath_hw *) hw_priv;
+   struct ath_common *common = ath9k_hw_common(ah);
+   struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common-priv;
+   u32 rsp_status;
+   int r;
+
+   mutex_lock(priv-wmi-multi_rmw_mutex);
+
+   /* Store the register/value */
+   priv-wmi-multi_rmw[priv-wmi-multi_rmw_idx].reg =
+   cpu_to_be32(reg_offset);
+   priv-wmi-multi_rmw[priv-wmi-multi_rmw_idx].set =
+   cpu_to_be32(set);
+   priv-wmi-multi_rmw[priv-wmi-multi_rmw_idx].clr =
+   cpu_to_be32(clr);
+
+   priv-wmi-multi_rmw_idx++;
+
+   /* If the buffer is full, send it out. */
+   if (priv-wmi-multi_rmw_idx == MAX_RMW_CMD_NUMBER) {
+   r = ath9k_wmi_cmd(priv-wmi, WMI_REG_RMW_CMDID,
+ (u8 *) priv-wmi-multi_rmw,
+ sizeof(struct register_write) * 
priv-wmi-multi_rmw_idx,
+ (u8 *) rsp_status, sizeof(rsp_status),
+ 100);
+   if (unlikely(r)) {
+   ath_dbg(common, WMI,
+   REGISTER RMW FAILED, multi len: %d\n,
+   priv-wmi-multi_rmw_idx);
+   }
+   priv-wmi-multi_rmw_idx = 0;
+   }
+
+   mutex_unlock(priv-wmi-multi_rmw_mutex);
+}
+
+static void ath9k_reg_rmw_flush(void *hw_priv)
 {
-   u32 val;
+   struct ath_hw *ah = (struct ath_hw *) hw_priv;
+   struct ath_common *common = ath9k_hw_common(ah);
+   struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common-priv;
+   u32 rsp_status;
+   int r;
+
+   if (test_bit(HTC_FWFLAG_NO_RMW, priv-fw_flags))
+   return;
+
+   atomic_dec(priv-wmi-m_rmw_cnt);
 
-   val = ath9k_regread(hw_priv, reg_offset);
-   val = ~clr;
-   val |= set;
-   ath9k_regwrite(hw_priv, val, reg_offset);
+   mutex_lock(priv-wmi-multi_rmw_mutex);
+
+   if (priv-wmi-multi_rmw_idx) {
+   r = ath9k_wmi_cmd(priv-wmi, WMI_REG_RMW_CMDID,
+ (u8 *) priv-wmi-multi_rmw,
+ sizeof(struct register_rmw) * 
priv-wmi-multi_rmw_idx,
+ (u8 *) rsp_status, sizeof(rsp_status),
+ 100);
+   if (unlikely(r)) {
+   ath_dbg(common, WMI,
+   REGISTER RMW FAILED, multi len

[PATCH v3 12/18] ath9k: use rmw buffer in ath9k_hw_set_operating_mode and ath9k_hw_reset

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/hw.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 662ef3f..1bae771 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1227,6 +1227,7 @@ static void ath9k_hw_set_operating_mode(struct ath_hw 
*ah, int opmode)
u32 mask = AR_STA_ID1_STA_AP | AR_STA_ID1_ADHOC;
u32 set = AR_STA_ID1_KSRCH_MODE;
 
+   ENABLE_REG_RMW_BUFFER(ah);
switch (opmode) {
case NL80211_IFTYPE_ADHOC:
if (!AR_SREV_9340_13(ah)) {
@@ -1248,6 +1249,7 @@ static void ath9k_hw_set_operating_mode(struct ath_hw 
*ah, int opmode)
break;
}
REG_RMW(ah, AR_STA_ID1, set, mask);
+   REG_RMW_BUFFER_FLUSH(ah);
 }
 
 void ath9k_hw_get_delta_slope_vals(struct ath_hw *ah, u32 coef_scaled,
@@ -1960,6 +1962,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct 
ath9k_channel *chan,
if (!ath9k_hw_mci_is_enabled(ah))
REG_WRITE(ah, AR_OBS, 8);
 
+   ENABLE_REG_RMW_BUFFER(ah);
if (ah-config.rx_intr_mitigation) {
REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_LAST, ah-config.rimt_last);
REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_FIRST, 
ah-config.rimt_first);
@@ -1969,6 +1972,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct 
ath9k_channel *chan,
REG_RMW_FIELD(ah, AR_TIMT, AR_TIMT_LAST, 300);
REG_RMW_FIELD(ah, AR_TIMT, AR_TIMT_FIRST, 750);
}
+   REG_RMW_BUFFER_FLUSH(ah);
 
ath9k_hw_init_bb(ah, chan);
 
-- 
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 v3 18/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_def_set_gain

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_def.c | 34 -
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c 
b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 0980590..056f516 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -466,6 +466,7 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
  struct ar5416_eeprom_def *eep,
  u8 txRxAttenLocal, int regChainOffset, int i)
 {
+   ENABLE_REG_RMW_BUFFER(ah);
if (AR5416_VER_MASK = AR5416_EEP_MINOR_VER_3) {
txRxAttenLocal = pModal-txRxAttenCh[i];
 
@@ -483,16 +484,12 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
  AR_PHY_GAIN_2GHZ_XATTEN2_DB,
  pModal-xatten2Db[i]);
} else {
-   REG_WRITE(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
- (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
-  ~AR_PHY_GAIN_2GHZ_BSW_MARGIN)
- | SM(pModal- bswMargin[i],
-  AR_PHY_GAIN_2GHZ_BSW_MARGIN));
-   REG_WRITE(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
- (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
-  ~AR_PHY_GAIN_2GHZ_BSW_ATTEN)
- | SM(pModal-bswAtten[i],
-  AR_PHY_GAIN_2GHZ_BSW_ATTEN));
+   REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
+   SM(pModal- bswMargin[i], 
AR_PHY_GAIN_2GHZ_BSW_MARGIN),
+   AR_PHY_GAIN_2GHZ_BSW_MARGIN);
+   REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
+   SM(pModal-bswAtten[i], 
AR_PHY_GAIN_2GHZ_BSW_ATTEN),
+   AR_PHY_GAIN_2GHZ_BSW_ATTEN);
}
}
 
@@ -504,17 +501,14 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
  AR_PHY_RXGAIN + regChainOffset,
  AR9280_PHY_RXGAIN_TXRX_MARGIN, pModal-rxTxMarginCh[i]);
} else {
-   REG_WRITE(ah,
- AR_PHY_RXGAIN + regChainOffset,
- (REG_READ(ah, AR_PHY_RXGAIN + regChainOffset) 
-  ~AR_PHY_RXGAIN_TXRX_ATTEN)
- | SM(txRxAttenLocal, AR_PHY_RXGAIN_TXRX_ATTEN));
-   REG_WRITE(ah,
- AR_PHY_GAIN_2GHZ + regChainOffset,
- (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
-  ~AR_PHY_GAIN_2GHZ_RXTX_MARGIN) |
- SM(pModal-rxTxMarginCh[i], 
AR_PHY_GAIN_2GHZ_RXTX_MARGIN));
+   REG_RMW(ah, AR_PHY_RXGAIN + regChainOffset,
+   SM(txRxAttenLocal, AR_PHY_RXGAIN_TXRX_ATTEN),
+   AR_PHY_RXGAIN_TXRX_ATTEN);
+   REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
+   SM(pModal-rxTxMarginCh[i], 
AR_PHY_GAIN_2GHZ_RXTX_MARGIN),
+   AR_PHY_GAIN_2GHZ_RXTX_MARGIN);
}
+   REG_RMW_BUFFER_FLUSH(ah);
 }
 
 static void ath9k_hw_def_set_board_values(struct ath_hw *ah,
-- 
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 v3 04/18] ath9k: ar9271_hw_pa_cal: use RMW buffer

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 8d24a73..62a2314 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -436,13 +436,14 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
{ AR9285_AN_RF2G2, 0 },
{ AR9285_AN_TOP2, 0 },
{ AR9285_AN_RF2G8, 0 },
-   { AR9285_AN_RF2G7, 0 } ,
-   { AR9285_AN_RF2G3, 0 } ,
+   { AR9285_AN_RF2G7, 0 },
+   { AR9285_AN_RF2G3, 0 },
};
 
for (i = 0; i  ARRAY_SIZE(regList); i++)
regList[i][1] = REG_READ(ah, regList[i][0]);
 
+   ENABLE_REG_RMW_BUFFER(ah);
/* 7834, b1=0 */
REG_CLR_BIT(ah, AR9285_AN_RF2G6, 1  0);
/* 9808, b27=1 */
@@ -476,6 +477,7 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PADRVGN2TAB0, 0);
/* 7828, b0-11, ccom=fff */
REG_RMW_FIELD(ah, AR9285_AN_RF2G3, AR9271_AN_RF2G3_CCOMP, 0xfff);
+   REG_RMW_BUFFER_FLUSH(ah);
 
/* Set:
 * localmode=1,bmode=1,bmoderxtx=1,synthon=1,
@@ -514,10 +516,12 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
}
 
 
+   ENABLE_REG_RMW_BUFFER(ah);
/* 7834, b1=1 */
REG_SET_BIT(ah, AR9285_AN_RF2G6, 1  0);
/* 9808, b27=0 */
REG_CLR_BIT(ah, 0x9808, 1  27);
+   REG_RMW_BUFFER_FLUSH(ah);
 
ENABLE_REGWRITE_BUFFER(ah);
for (i = 0; i  ARRAY_SIZE(regList); i++)
-- 
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 v3 03/18] ath9k: ar9271_hw_pa_cal: use proper makroses.

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 43 ---
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 4576b99..8d24a73 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -443,33 +443,30 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
for (i = 0; i  ARRAY_SIZE(regList); i++)
regList[i][1] = REG_READ(ah, regList[i][0]);
 
-   regVal = REG_READ(ah, AR9285_AN_RF2G6);
-   regVal = (~(0x1));
-   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
-   regVal = REG_READ(ah, 0x9808);
-   regVal |= (0x1  27);
-   REG_WRITE(ah, 0x9808, regVal);
-
+   /* 7834, b1=0 */
+   REG_CLR_BIT(ah, AR9285_AN_RF2G6, 1  0);
+   /* 9808, b27=1 */
+   REG_SET_BIT(ah, 0x9808, 1  27);
/* 786c,b23,1, pwddac=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_TOP3, AR9285_AN_TOP3_PWDDAC, 1);
+   REG_SET_BIT(ah, AR9285_AN_TOP3, AR9285_AN_TOP3_PWDDAC);
/* 7854, b5,1, pdrxtxbb=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDRXTXBB1, 1);
+   REG_SET_BIT(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDRXTXBB1);
/* 7854, b7,1, pdv2i=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDV2I, 1);
+   REG_SET_BIT(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDV2I);
/* 7854, b8,1, pddacinterface=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDDACIF, 1);
+   REG_SET_BIT(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDDACIF);
/* 7824,b12,0, offcal=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G2, AR9285_AN_RF2G2_OFFCAL, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G2, AR9285_AN_RF2G2_OFFCAL);
/* 7838, b1,0, pwddb=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PWDDB, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PWDDB);
/* 7820,b11,0, enpacal=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_ENPACAL, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_ENPACAL);
/* 7820,b25,1, pdpadrv1=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1);
/* 7820,b24,0, pdpadrv2=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV2, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV2);
/* 7820,b23,0, pdpaout=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPAOUT, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPAOUT);
/* 783c,b14-16,7, padrvgn2tab_0=7 */
REG_RMW_FIELD(ah, AR9285_AN_RF2G8, AR9285_AN_RF2G8_PADRVGN2TAB0, 7);
/*
@@ -516,15 +513,13 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
ah-pacal_info.prev_offset = regVal;
}
 
-   ENABLE_REGWRITE_BUFFER(ah);
 
-   regVal = REG_READ(ah, AR_AN_RF2G1_CH1);
-   regVal |= 0x1;
-   REG_WRITE(ah, AR_AN_RF2G1_CH1, regVal);
-   regVal = REG_READ(ah, 0x9808);
-   regVal = (~(0x1  27));
-   REG_WRITE(ah, 0x9808, regVal);
+   /* 7834, b1=1 */
+   REG_SET_BIT(ah, AR9285_AN_RF2G6, 1  0);
+   /* 9808, b27=0 */
+   REG_CLR_BIT(ah, 0x9808, 1  27);
 
+   ENABLE_REGWRITE_BUFFER(ah);
for (i = 0; i  ARRAY_SIZE(regList); i++)
REG_WRITE(ah, regList[i][0], regList[i][1]);
 
-- 
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 v3 02/18] ath9k: ar9271_hw_pa_cal - use defs instead of magin numbers

[Oleksij Rempel]

This function uses mixed styles for register names/numbers which
is make harder reading and optimisation.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 42190b6..4576b99 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -430,22 +430,22 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
u32 regVal;
unsigned int i;
u32 regList[][2] = {
-   { 0x786c, 0 },
-   { 0x7854, 0 },
-   { 0x7820, 0 },
-   { 0x7824, 0 },
-   { 0x7868, 0 },
-   { 0x783c, 0 },
-   { 0x7838, 0 } ,
-   { 0x7828, 0 } ,
+   { AR9285_AN_TOP3, 0 },
+   { AR9285_AN_RXTXBB1, 0 },
+   { AR9285_AN_RF2G1, 0 },
+   { AR9285_AN_RF2G2, 0 },
+   { AR9285_AN_TOP2, 0 },
+   { AR9285_AN_RF2G8, 0 },
+   { AR9285_AN_RF2G7, 0 } ,
+   { AR9285_AN_RF2G3, 0 } ,
};
 
for (i = 0; i  ARRAY_SIZE(regList); i++)
regList[i][1] = REG_READ(ah, regList[i][0]);
 
-   regVal = REG_READ(ah, 0x7834);
+   regVal = REG_READ(ah, AR9285_AN_RF2G6);
regVal = (~(0x1));
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
regVal = REG_READ(ah, 0x9808);
regVal |= (0x1  27);
REG_WRITE(ah, 0x9808, regVal);
@@ -477,7 +477,7 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
 * does not matter since we turn it off
 */
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PADRVGN2TAB0, 0);
-
+   /* 7828, b0-11, ccom=fff */
REG_RMW_FIELD(ah, AR9285_AN_RF2G3, AR9271_AN_RF2G3_CCOMP, 0xfff);
 
/* Set:
@@ -490,15 +490,16 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
 
/* find off_6_1; */
for (i = 6; i  0; i--) {
-   regVal = REG_READ(ah, 0x7834);
+   regVal = REG_READ(ah, AR9285_AN_RF2G6);
regVal |= (1  (20 + i));
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
udelay(1);
/* regVal = REG_READ(ah, 0x7834); */
regVal = (~(0x1  (20 + i)));
-   regVal |= (MS(REG_READ(ah, 0x7840), AR9285_AN_RXTXBB1_SPARE9)
+   regVal |= (MS(REG_READ(ah, AR9285_AN_RF2G9),
+ AR9285_AN_RXTXBB1_SPARE9)
 (20 + i));
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
}
 
regVal = (regVal  20)  0x7f;
@@ -517,9 +518,9 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
 
ENABLE_REGWRITE_BUFFER(ah);
 
-   regVal = REG_READ(ah, 0x7834);
+   regVal = REG_READ(ah, AR_AN_RF2G1_CH1);
regVal |= 0x1;
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR_AN_RF2G1_CH1, regVal);
regVal = REG_READ(ah, 0x9808);
regVal = (~(0x1  27));
REG_WRITE(ah, 0x9808, regVal);
-- 
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 v3 11/18] ath9k: ath9k_hw_set_4k_power_cal_tabl: use rmw buffer

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index e5a78d4..fc54fc7 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -389,6 +389,7 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw 
*ah,
}
}
 
+   ENABLE_REG_RMW_BUFFER(ah);
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_NUM_PD_GAIN,
  (numXpdGain - 1)  0x3);
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_PD_GAIN_1,
@@ -396,6 +397,7 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw 
*ah,
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_PD_GAIN_2,
  xpdGainValues[1]);
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_PD_GAIN_3, 0);
+   REG_RMW_BUFFER_FLUSH(ah);
 
for (i = 0; i  AR5416_EEP4K_MAX_CHAINS; i++) {
regChainOffset = i * 0x1000;
-- 
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 v3 16/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_gain

[Oleksij Rempel]

it is possible to reduce time needed for this function
by rplacing REG_WRITE with REG_RMW (plus dummy 0) and putt all commands
in same buffer.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 291c1d1..38dc965 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -772,15 +772,14 @@ static void ath9k_hw_4k_set_gain(struct ath_hw *ah,
 struct ar5416_eeprom_4k *eep,
 u8 txRxAttenLocal)
 {
-   REG_WRITE(ah, AR_PHY_SWITCH_CHAIN_0,
- pModal-antCtrlChain[0]);
+   ENABLE_REG_RMW_BUFFER(ah);
+   REG_RMW(ah, AR_PHY_SWITCH_CHAIN_0,
+   pModal-antCtrlChain[0], 0);
 
-   REG_WRITE(ah, AR_PHY_TIMING_CTRL4(0),
- (REG_READ(ah, AR_PHY_TIMING_CTRL4(0)) 
-  ~(AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF |
-AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF)) |
- SM(pModal-iqCalICh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF) |
- SM(pModal-iqCalQCh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF));
+   REG_RMW(ah, AR_PHY_TIMING_CTRL4(0),
+   SM(pModal-iqCalICh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF) |
+   SM(pModal-iqCalQCh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF),
+   AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF | 
AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF);
 
if ((eep-baseEepHeader.version  AR5416_EEP_VER_MINOR_MASK) =
AR5416_EEP_MINOR_VER_3) {
@@ -819,6 +818,7 @@ static void ath9k_hw_4k_set_gain(struct ath_hw *ah,
  AR9280_PHY_RXGAIN_TXRX_ATTEN, txRxAttenLocal);
REG_RMW_FIELD(ah, AR_PHY_RXGAIN + 0x1000,
  AR9280_PHY_RXGAIN_TXRX_MARGIN, pModal-rxTxMarginCh[0]);
+   REG_RMW_BUFFER_FLUSH(ah);
 }
 
 /*
-- 
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 v3 14/18] ath9k: ath9k_hw_analog_shift_rmw: use REG_RMW

[Oleksij Rempel]

use REG_RMW in ath9k_hw_analog_shift_rmw.
It will double execution speed on usb bus.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c 
b/drivers/net/wireless/ath/ath9k/eeprom.c
index 971d770..cc81482 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -27,12 +27,7 @@ void ath9k_hw_analog_shift_regwrite(struct ath_hw *ah, u32 
reg, u32 val)
 void ath9k_hw_analog_shift_rmw(struct ath_hw *ah, u32 reg, u32 mask,
   u32 shift, u32 val)
 {
-   u32 regVal;
-
-   regVal = REG_READ(ah, reg)  ~mask;
-   regVal |= (val  shift)  mask;
-
-   REG_WRITE(ah, reg, regVal);
+   REG_RMW(ah, reg, ((val  shift)  mask), mask);
 
if (ah-config.analog_shiftreg)
udelay(100);
-- 
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 v3 06/18] ath9k: add new function ath9k_hw_read_array

[Oleksij Rempel]

REG_READ generate most overhead on usb bus. It send and read micro packages
and reduce usb bandwidth. To reduce this overhead we should read in batches.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/hw.c | 30 ++
 drivers/net/wireless/ath/ath9k/hw.h |  3 +++
 2 files changed, 33 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 60aa8d7..662ef3f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -121,6 +121,36 @@ void ath9k_hw_write_array(struct ath_hw *ah, const struct 
ar5416IniArray *array,
REGWRITE_BUFFER_FLUSH(ah);
 }
 
+void ath9k_hw_read_array(struct ath_hw *ah, u32 array[][2], int size)
+{
+   u32 *tmp_reg_list, *tmp_data;
+   int i;
+
+   tmp_reg_list = kmalloc(size * sizeof(u32), GFP_KERNEL);
+   if (!tmp_reg_list) {
+   dev_err(ah-dev, %s: tmp_reg_list: alloc filed\n, __func__);
+   return;
+   }
+
+   tmp_data = kmalloc(size * sizeof(u32), GFP_KERNEL);
+   if (!tmp_data) {
+   dev_err(ah-dev, %s tmp_data: alloc filed\n, __func__);
+   goto error_tmp_data;
+   }
+
+   for (i = 0; i  size; i++)
+   tmp_reg_list[i] = array[i][0];
+
+   REG_READ_MULTI(ah, tmp_reg_list, tmp_data, size);
+
+   for (i = 0; i  size; i++)
+   array[i][1] = tmp_data[i];
+
+   kfree(tmp_data);
+error_tmp_data:
+   kfree(tmp_reg_list);
+}
+
 u32 ath9k_hw_reverse_bits(u32 val, u32 n)
 {
u32 retval;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index f1864cc..66aba10 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -138,6 +138,8 @@
 
 #define REG_WRITE_ARRAY(iniarray, column, regWr) \
ath9k_hw_write_array(ah, iniarray, column, (regWr))
+#define REG_READ_ARRAY(ah, array, size) \
+   ath9k_hw_read_array(ah, array, size)
 
 #define AR_GPIO_OUTPUT_MUX_AS_OUTPUT 0
 #define AR_GPIO_OUTPUT_MUX_AS_PCIE_ATTENTION_LED 1
@@ -1020,6 +1022,7 @@ void ath9k_hw_synth_delay(struct ath_hw *ah, struct 
ath9k_channel *chan,
 bool ath9k_hw_wait(struct ath_hw *ah, u32 reg, u32 mask, u32 val, u32 timeout);
 void ath9k_hw_write_array(struct ath_hw *ah, const struct ar5416IniArray 
*array,
  int column, unsigned int *writecnt);
+void ath9k_hw_read_array(struct ath_hw *ah, u32 array[][2], int size);
 u32 ath9k_hw_reverse_bits(u32 val, u32 n);
 u16 ath9k_hw_computetxtime(struct ath_hw *ah,
   u8 phy, int kbps,
-- 
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 v3 08/18] ath9k: use one shot read in ath9k_hw_update_mibstats

[Oleksij Rempel]

this will reduce some overhead on usb bus.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ani.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ani.c 
b/drivers/net/wireless/ath/ath9k/ani.c
index ca01d17..25e45e4 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -107,11 +107,21 @@ static const struct ani_cck_level_entry cck_level_table[] 
= {
 static void ath9k_hw_update_mibstats(struct ath_hw *ah,
 struct ath9k_mib_stats *stats)
 {
-   stats-ackrcv_bad += REG_READ(ah, AR_ACK_FAIL);
-   stats-rts_bad += REG_READ(ah, AR_RTS_FAIL);
-   stats-fcs_bad += REG_READ(ah, AR_FCS_FAIL);
-   stats-rts_good += REG_READ(ah, AR_RTS_OK);
-   stats-beacons += REG_READ(ah, AR_BEACON_CNT);
+   u32 addr[5] = {AR_RTS_OK, AR_RTS_FAIL, AR_ACK_FAIL,
+  AR_FCS_FAIL, AR_BEACON_CNT};
+   u32 data[5];
+
+   REG_READ_MULTI(ah, addr[0], data[0], 5);
+   /* AR_RTS_OK */
+   stats-rts_good += data[0];
+   /* AR_RTS_FAIL */
+   stats-rts_bad += data[1];
+   /* AR_ACK_FAIL */
+   stats-ackrcv_bad += data[2];
+   /* AR_FCS_FAIL */
+   stats-fcs_bad += data[3];
+   /* AR_BEACON_CNT */
+   stats-beacons += data[4];
 }
 
 static void ath9k_ani_restart(struct ath_hw *ah)
-- 
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 v3 00/18] reduce some of ath9k_htc performance problems

[Oleksij Rempel]

This patchset adds new WMI_RMW handler to reduce some of usb related
performance problems.

Oleksij Rempel (18):
  ath9k_htc: add new WMI_REG_RMW_CMDID command
  ath9k: ar9271_hw_pa_cal - use defs instead of magin numbers
  ath9k: ar9271_hw_pa_cal: use proper makroses.
  ath9k: ar9271_hw_pa_cal: use RMW buffer
  ath9k: add multi_read to be compatible with ath9k_htc
  ath9k: add new function ath9k_hw_read_array
  ath9k: ar9271_hw_pa_cal: use REG_READ_ARRAY
  ath9k: use one shot read in ath9k_hw_update_mibstats
  ath9k: ath9k_hw_loadnf: use REG_RMW
  ath9k: write buffer related optimisation in ar5008_hw_set_channel_regs
  ath9k: ath9k_hw_set_4k_power_cal_tabl: use rmw buffer
  ath9k: use rmw buffer in ath9k_hw_set_operating_mode and
ath9k_hw_reset
  ath9k: ath9k_hw_4k_set_board_values: use rmw buffer
  ath9k: ath9k_hw_analog_shift_rmw: use REG_RMW
  ath9k: ath9k_hw_4k_set_board_values: use rmw buffer
  ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_gain
  ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_board_values
  ath9k: use REG_RMW and rmw buffer in ath9k_hw_def_set_gain

 drivers/net/wireless/ath/ath.h|   3 +
 drivers/net/wireless/ath/ath9k/ani.c  |  20 +++-
 drivers/net/wireless/ath/ath9k/ar5008_phy.c   |   5 +-
 drivers/net/wireless/ath/ath9k/ar9002_calib.c |  77 +++---
 drivers/net/wireless/ath/ath9k/calib.c|  19 ++--
 drivers/net/wireless/ath/ath9k/eeprom.c   |   7 +-
 drivers/net/wireless/ath/ath9k/eeprom_4k.c|  36 ---
 drivers/net/wireless/ath/ath9k/eeprom_def.c   |  34 +++---
 drivers/net/wireless/ath/ath9k/htc.h  |   5 +
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 142 --
 drivers/net/wireless/ath/ath9k/hw.c   |  34 ++
 drivers/net/wireless/ath/ath9k/hw.h   |  15 +++
 drivers/net/wireless/ath/ath9k/init.c |  11 ++
 drivers/net/wireless/ath/ath9k/wmi.c  |   3 +
 drivers/net/wireless/ath/ath9k/wmi.h  |  16 +++
 15 files changed, 324 insertions(+), 103 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

[PATCH v2 10/18] ath9k: write buffer related optimisation in ar5008_hw_set_channel_regs

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar5008_phy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index f273427..6c23d27 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -681,12 +681,13 @@ static void ar5008_hw_set_channel_regs(struct ath_hw *ah,
phymode |= AR_PHY_FC_DYN2040_PRI_CH;
 
}
+   ENABLE_REGWRITE_BUFFER(ah);
REG_WRITE(ah, AR_PHY_TURBO, phymode);
 
+   /* This function do only REG_WRITE, so
+* we can include it to REGWRITE_BUFFER. */
ath9k_hw_set11nmac2040(ah, chan);
 
-   ENABLE_REGWRITE_BUFFER(ah);
-
REG_WRITE(ah, AR_GTXTO, 25  AR_GTXTO_TIMEOUT_LIMIT_S);
REG_WRITE(ah, AR_CST, 0xF  AR_CST_TIMEOUT_LIMIT_S);
 
-- 
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 12/18] ath9k: use rmw buffer in ath9k_hw_set_operating_mode and ath9k_hw_reset

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/hw.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 15433c7..523a6a8 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1217,6 +1217,7 @@ static void ath9k_hw_set_operating_mode(struct ath_hw 
*ah, int opmode)
u32 mask = AR_STA_ID1_STA_AP | AR_STA_ID1_ADHOC;
u32 set = AR_STA_ID1_KSRCH_MODE;
 
+   ENABLE_REG_RMW_BUFFER(ah);
switch (opmode) {
case NL80211_IFTYPE_ADHOC:
if (!AR_SREV_9340_13(ah)) {
@@ -1238,6 +1239,7 @@ static void ath9k_hw_set_operating_mode(struct ath_hw 
*ah, int opmode)
break;
}
REG_RMW(ah, AR_STA_ID1, set, mask);
+   REG_RMW_BUFFER_FLUSH(ah);
 }
 
 void ath9k_hw_get_delta_slope_vals(struct ath_hw *ah, u32 coef_scaled,
@@ -1950,6 +1952,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct 
ath9k_channel *chan,
if (!ath9k_hw_mci_is_enabled(ah))
REG_WRITE(ah, AR_OBS, 8);
 
+   ENABLE_REG_RMW_BUFFER(ah);
if (ah-config.rx_intr_mitigation) {
REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_LAST, ah-config.rimt_last);
REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_FIRST, 
ah-config.rimt_first);
@@ -1959,6 +1962,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct 
ath9k_channel *chan,
REG_RMW_FIELD(ah, AR_TIMT, AR_TIMT_LAST, 300);
REG_RMW_FIELD(ah, AR_TIMT, AR_TIMT_FIRST, 750);
}
+   REG_RMW_BUFFER_FLUSH(ah);
 
ath9k_hw_init_bb(ah, chan);
 
-- 
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 02/18] ath9k: ar9271_hw_pa_cal - use defs instead of magin numbers

[Oleksij Rempel]

This function uses mixed styles for register names/numbers which
is make harder reading and optimisation.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 42190b6..4576b99 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -430,22 +430,22 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
u32 regVal;
unsigned int i;
u32 regList[][2] = {
-   { 0x786c, 0 },
-   { 0x7854, 0 },
-   { 0x7820, 0 },
-   { 0x7824, 0 },
-   { 0x7868, 0 },
-   { 0x783c, 0 },
-   { 0x7838, 0 } ,
-   { 0x7828, 0 } ,
+   { AR9285_AN_TOP3, 0 },
+   { AR9285_AN_RXTXBB1, 0 },
+   { AR9285_AN_RF2G1, 0 },
+   { AR9285_AN_RF2G2, 0 },
+   { AR9285_AN_TOP2, 0 },
+   { AR9285_AN_RF2G8, 0 },
+   { AR9285_AN_RF2G7, 0 } ,
+   { AR9285_AN_RF2G3, 0 } ,
};
 
for (i = 0; i  ARRAY_SIZE(regList); i++)
regList[i][1] = REG_READ(ah, regList[i][0]);
 
-   regVal = REG_READ(ah, 0x7834);
+   regVal = REG_READ(ah, AR9285_AN_RF2G6);
regVal = (~(0x1));
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
regVal = REG_READ(ah, 0x9808);
regVal |= (0x1  27);
REG_WRITE(ah, 0x9808, regVal);
@@ -477,7 +477,7 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
 * does not matter since we turn it off
 */
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PADRVGN2TAB0, 0);
-
+   /* 7828, b0-11, ccom=fff */
REG_RMW_FIELD(ah, AR9285_AN_RF2G3, AR9271_AN_RF2G3_CCOMP, 0xfff);
 
/* Set:
@@ -490,15 +490,16 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
 
/* find off_6_1; */
for (i = 6; i  0; i--) {
-   regVal = REG_READ(ah, 0x7834);
+   regVal = REG_READ(ah, AR9285_AN_RF2G6);
regVal |= (1  (20 + i));
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
udelay(1);
/* regVal = REG_READ(ah, 0x7834); */
regVal = (~(0x1  (20 + i)));
-   regVal |= (MS(REG_READ(ah, 0x7840), AR9285_AN_RXTXBB1_SPARE9)
+   regVal |= (MS(REG_READ(ah, AR9285_AN_RF2G9),
+ AR9285_AN_RXTXBB1_SPARE9)
 (20 + i));
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
}
 
regVal = (regVal  20)  0x7f;
@@ -517,9 +518,9 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
 
ENABLE_REGWRITE_BUFFER(ah);
 
-   regVal = REG_READ(ah, 0x7834);
+   regVal = REG_READ(ah, AR_AN_RF2G1_CH1);
regVal |= 0x1;
-   REG_WRITE(ah, 0x7834, regVal);
+   REG_WRITE(ah, AR_AN_RF2G1_CH1, regVal);
regVal = REG_READ(ah, 0x9808);
regVal = (~(0x1  27));
REG_WRITE(ah, 0x9808, regVal);
-- 
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 09/18] ath9k: ath9k_hw_loadnf: use REG_RMW

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/calib.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c 
b/drivers/net/wireless/ath/ath9k/calib.c
index e200a6e..3e2e24e 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -238,7 +238,6 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
 {
struct ath9k_nfcal_hist *h = NULL;
unsigned i, j;
-   int32_t val;
u8 chainmask = (ah-rxchainmask  3) | ah-rxchainmask;
struct ath_common *common = ath9k_hw_common(ah);
s16 default_nf = ath9k_hw_get_default_nf(ah, chan);
@@ -246,6 +245,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
if (ah-caldata)
h = ah-caldata-nfCalHist;
 
+   ENABLE_REG_RMW_BUFFER(ah);
for (i = 0; i  NUM_NF_READINGS; i++) {
if (chainmask  (1  i)) {
s16 nfval;
@@ -258,10 +258,8 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct 
ath9k_channel *chan)
else
nfval = default_nf;
 
-   val = REG_READ(ah, ah-nf_regs[i]);
-   val = 0xFE00;
-   val |= (((u32) nfval  1)  0x1ff);
-   REG_WRITE(ah, ah-nf_regs[i], val);
+   REG_RMW(ah, ah-nf_regs[i],
+   (((u32) nfval  1)  0x1ff), 0x1ff);
}
}
 
@@ -274,6 +272,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL,
AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
+   REG_RMW_BUFFER_FLUSH(ah);
 
/*
 * Wait for load to complete, should be fast, a few 10s of us.
@@ -309,19 +308,17 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct 
ath9k_channel *chan)
 * by the median we just loaded.  This will be initial (and max) value
 * of next noise floor calibration the baseband does.
 */
-   ENABLE_REGWRITE_BUFFER(ah);
+   ENABLE_REG_RMW_BUFFER(ah);
for (i = 0; i  NUM_NF_READINGS; i++) {
if (chainmask  (1  i)) {
if ((i = AR5416_MAX_CHAINS)  !IS_CHAN_HT40(chan))
continue;
 
-   val = REG_READ(ah, ah-nf_regs[i]);
-   val = 0xFE00;
-   val |= (((u32) (-50)  1)  0x1ff);
-   REG_WRITE(ah, ah-nf_regs[i], val);
+   REG_RMW(ah, ah-nf_regs[i],
+   (((u32) (-50)  1)  0x1ff), 0x1ff);
}
}
-   REGWRITE_BUFFER_FLUSH(ah);
+   REG_RMW_BUFFER_FLUSH(ah);
 
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 07/18] ath9k: ar9271_hw_pa_cal: use REG_READ_ARRAY

[Oleksij Rempel]

insted of reading each register separatly
and waste 4ms on each operation, we can
use one shot read.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 62a2314..50fcd34 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -440,8 +440,7 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
{ AR9285_AN_RF2G3, 0 },
};
 
-   for (i = 0; i  ARRAY_SIZE(regList); i++)
-   regList[i][1] = REG_READ(ah, regList[i][0]);
+   REG_READ_ARRAY(ah, regList, ARRAY_SIZE(regList));
 
ENABLE_REG_RMW_BUFFER(ah);
/* 7834, b1=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 04/18] ath9k: ar9271_hw_pa_cal: use RMW buffer

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 8d24a73..62a2314 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -436,13 +436,14 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
{ AR9285_AN_RF2G2, 0 },
{ AR9285_AN_TOP2, 0 },
{ AR9285_AN_RF2G8, 0 },
-   { AR9285_AN_RF2G7, 0 } ,
-   { AR9285_AN_RF2G3, 0 } ,
+   { AR9285_AN_RF2G7, 0 },
+   { AR9285_AN_RF2G3, 0 },
};
 
for (i = 0; i  ARRAY_SIZE(regList); i++)
regList[i][1] = REG_READ(ah, regList[i][0]);
 
+   ENABLE_REG_RMW_BUFFER(ah);
/* 7834, b1=0 */
REG_CLR_BIT(ah, AR9285_AN_RF2G6, 1  0);
/* 9808, b27=1 */
@@ -476,6 +477,7 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PADRVGN2TAB0, 0);
/* 7828, b0-11, ccom=fff */
REG_RMW_FIELD(ah, AR9285_AN_RF2G3, AR9271_AN_RF2G3_CCOMP, 0xfff);
+   REG_RMW_BUFFER_FLUSH(ah);
 
/* Set:
 * localmode=1,bmode=1,bmoderxtx=1,synthon=1,
@@ -514,10 +516,12 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
}
 
 
+   ENABLE_REG_RMW_BUFFER(ah);
/* 7834, b1=1 */
REG_SET_BIT(ah, AR9285_AN_RF2G6, 1  0);
/* 9808, b27=0 */
REG_CLR_BIT(ah, 0x9808, 1  27);
+   REG_RMW_BUFFER_FLUSH(ah);
 
ENABLE_REGWRITE_BUFFER(ah);
for (i = 0; i  ARRAY_SIZE(regList); i++)
-- 
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 03/18] ath9k: ar9271_hw_pa_cal: use proper makroses.

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/ar9002_calib.c | 43 ---
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 4576b99..8d24a73 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -443,33 +443,30 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
for (i = 0; i  ARRAY_SIZE(regList); i++)
regList[i][1] = REG_READ(ah, regList[i][0]);
 
-   regVal = REG_READ(ah, AR9285_AN_RF2G6);
-   regVal = (~(0x1));
-   REG_WRITE(ah, AR9285_AN_RF2G6, regVal);
-   regVal = REG_READ(ah, 0x9808);
-   regVal |= (0x1  27);
-   REG_WRITE(ah, 0x9808, regVal);
-
+   /* 7834, b1=0 */
+   REG_CLR_BIT(ah, AR9285_AN_RF2G6, 1  0);
+   /* 9808, b27=1 */
+   REG_SET_BIT(ah, 0x9808, 1  27);
/* 786c,b23,1, pwddac=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_TOP3, AR9285_AN_TOP3_PWDDAC, 1);
+   REG_SET_BIT(ah, AR9285_AN_TOP3, AR9285_AN_TOP3_PWDDAC);
/* 7854, b5,1, pdrxtxbb=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDRXTXBB1, 1);
+   REG_SET_BIT(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDRXTXBB1);
/* 7854, b7,1, pdv2i=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDV2I, 1);
+   REG_SET_BIT(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDV2I);
/* 7854, b8,1, pddacinterface=1 */
-   REG_RMW_FIELD(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDDACIF, 1);
+   REG_SET_BIT(ah, AR9285_AN_RXTXBB1, AR9285_AN_RXTXBB1_PDDACIF);
/* 7824,b12,0, offcal=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G2, AR9285_AN_RF2G2_OFFCAL, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G2, AR9285_AN_RF2G2_OFFCAL);
/* 7838, b1,0, pwddb=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PWDDB, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PWDDB);
/* 7820,b11,0, enpacal=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_ENPACAL, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_ENPACAL);
/* 7820,b25,1, pdpadrv1=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1);
/* 7820,b24,0, pdpadrv2=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV2, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV2);
/* 7820,b23,0, pdpaout=0 */
-   REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPAOUT, 0);
+   REG_CLR_BIT(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPAOUT);
/* 783c,b14-16,7, padrvgn2tab_0=7 */
REG_RMW_FIELD(ah, AR9285_AN_RF2G8, AR9285_AN_RF2G8_PADRVGN2TAB0, 7);
/*
@@ -516,15 +513,13 @@ static void ar9271_hw_pa_cal(struct ath_hw *ah, bool 
is_reset)
ah-pacal_info.prev_offset = regVal;
}
 
-   ENABLE_REGWRITE_BUFFER(ah);
 
-   regVal = REG_READ(ah, AR_AN_RF2G1_CH1);
-   regVal |= 0x1;
-   REG_WRITE(ah, AR_AN_RF2G1_CH1, regVal);
-   regVal = REG_READ(ah, 0x9808);
-   regVal = (~(0x1  27));
-   REG_WRITE(ah, 0x9808, regVal);
+   /* 7834, b1=1 */
+   REG_SET_BIT(ah, AR9285_AN_RF2G6, 1  0);
+   /* 9808, b27=0 */
+   REG_CLR_BIT(ah, 0x9808, 1  27);
 
+   ENABLE_REGWRITE_BUFFER(ah);
for (i = 0; i  ARRAY_SIZE(regList); i++)
REG_WRITE(ah, regList[i][0], regList[i][1]);
 
-- 
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 15/18] ath9k: ath9k_hw_4k_set_board_values: use rmw buffer

[Oleksij Rempel]

it will reduce exution time from 14ms to 2ms on ar9271

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 0600562..291c1d1 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -930,6 +930,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw *ah,
}
}
 
+   ENABLE_REG_RMW_BUFFER(ah);
if (AR_SREV_9271(ah)) {
ath9k_hw_analog_shift_rmw(ah,
  AR9285_AN_RF2G3,
@@ -1034,6 +1035,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
  AR9285_AN_RF2G4_DB2_4_S,
  db2[4]);
}
+   REG_RMW_BUFFER_FLUSH(ah);
 
 
REG_RMW_FIELD(ah, AR_PHY_SETTLING, AR_PHY_SETTLING_SWITCH,
-- 
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 06/18] ath9k: add new function ath9k_hw_read_array

[Oleksij Rempel]

REG_READ generate most overhead on usb bus. It send and read micro packages
and reduce usb bandwidth. To reduce this overhead we should read in batches.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/hw.c | 20 
 drivers/net/wireless/ath/ath9k/hw.h |  3 +++
 2 files changed, 23 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 60aa8d7..15433c7 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -121,6 +121,26 @@ void ath9k_hw_write_array(struct ath_hw *ah, const struct 
ar5416IniArray *array,
REGWRITE_BUFFER_FLUSH(ah);
 }
 
+void ath9k_hw_read_array(struct ath_hw *ah, u32 array[][2], int size)
+{
+   u32 *tmp_reg_list, *tmp_data;
+   int i;
+
+   tmp_reg_list = kmalloc(size * sizeof(u32), GFP_KERNEL);
+   tmp_data = kmalloc(size * sizeof(u32), GFP_KERNEL);
+
+   for (i = 0; i  size; i++)
+   tmp_reg_list[i] = array[i][0];
+
+   REG_READ_MULTI(ah, tmp_reg_list, tmp_data, size);
+
+   for (i = 0; i  size; i++)
+   array[i][1] = tmp_data[i];
+
+   kfree(tmp_reg_list);
+   kfree(tmp_data);
+}
+
 u32 ath9k_hw_reverse_bits(u32 val, u32 n)
 {
u32 retval;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index f1864cc..66aba10 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -138,6 +138,8 @@
 
 #define REG_WRITE_ARRAY(iniarray, column, regWr) \
ath9k_hw_write_array(ah, iniarray, column, (regWr))
+#define REG_READ_ARRAY(ah, array, size) \
+   ath9k_hw_read_array(ah, array, size)
 
 #define AR_GPIO_OUTPUT_MUX_AS_OUTPUT 0
 #define AR_GPIO_OUTPUT_MUX_AS_PCIE_ATTENTION_LED 1
@@ -1020,6 +1022,7 @@ void ath9k_hw_synth_delay(struct ath_hw *ah, struct 
ath9k_channel *chan,
 bool ath9k_hw_wait(struct ath_hw *ah, u32 reg, u32 mask, u32 val, u32 timeout);
 void ath9k_hw_write_array(struct ath_hw *ah, const struct ar5416IniArray 
*array,
  int column, unsigned int *writecnt);
+void ath9k_hw_read_array(struct ath_hw *ah, u32 array[][2], int size);
 u32 ath9k_hw_reverse_bits(u32 val, u32 n);
 u16 ath9k_hw_computetxtime(struct ath_hw *ah,
   u8 phy, int kbps,
-- 
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 16/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_gain

[Oleksij Rempel]

it is possible to reduce time needed for this function
by rplacing REG_WRITE with REG_RMW (plus dummy 0) and putt all commands
in same buffer.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 291c1d1..38dc965 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -772,15 +772,14 @@ static void ath9k_hw_4k_set_gain(struct ath_hw *ah,
 struct ar5416_eeprom_4k *eep,
 u8 txRxAttenLocal)
 {
-   REG_WRITE(ah, AR_PHY_SWITCH_CHAIN_0,
- pModal-antCtrlChain[0]);
+   ENABLE_REG_RMW_BUFFER(ah);
+   REG_RMW(ah, AR_PHY_SWITCH_CHAIN_0,
+   pModal-antCtrlChain[0], 0);
 
-   REG_WRITE(ah, AR_PHY_TIMING_CTRL4(0),
- (REG_READ(ah, AR_PHY_TIMING_CTRL4(0)) 
-  ~(AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF |
-AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF)) |
- SM(pModal-iqCalICh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF) |
- SM(pModal-iqCalQCh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF));
+   REG_RMW(ah, AR_PHY_TIMING_CTRL4(0),
+   SM(pModal-iqCalICh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF) |
+   SM(pModal-iqCalQCh[0], AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF),
+   AR_PHY_TIMING_CTRL4_IQCORR_Q_Q_COFF | 
AR_PHY_TIMING_CTRL4_IQCORR_Q_I_COFF);
 
if ((eep-baseEepHeader.version  AR5416_EEP_VER_MINOR_MASK) =
AR5416_EEP_MINOR_VER_3) {
@@ -819,6 +818,7 @@ static void ath9k_hw_4k_set_gain(struct ath_hw *ah,
  AR9280_PHY_RXGAIN_TXRX_ATTEN, txRxAttenLocal);
REG_RMW_FIELD(ah, AR_PHY_RXGAIN + 0x1000,
  AR9280_PHY_RXGAIN_TXRX_MARGIN, pModal-rxTxMarginCh[0]);
+   REG_RMW_BUFFER_FLUSH(ah);
 }
 
 /*
-- 
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 01/18] ath9k_htc: add new WMI_REG_RMW_CMDID command

[Oleksij Rempel]

Since usb bus add extra delay on each request, a command
with read + write requests is too expensive. We can dramtically
reduce usb load by moving this command to firmware.

In my tests, this patch will reduce channel scan time
for about 5-10 seconds.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath.h|   3 +
 drivers/net/wireless/ath/ath9k/htc.h  |   5 +
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 142 --
 drivers/net/wireless/ath/ath9k/hw.h   |  12 +++
 drivers/net/wireless/ath/ath9k/wmi.c  |   3 +
 drivers/net/wireless/ath/ath9k/wmi.h  |  16 +++
 6 files changed, 175 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index 1eebe2e..7e94810 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -131,6 +131,9 @@ struct ath_ops {
void (*enable_write_buffer)(void *);
void (*write_flush) (void *);
u32 (*rmw)(void *, u32 reg_offset, u32 set, u32 clr);
+   void (*enable_rmw_buffer)(void *);
+   void (*rmw_flush) (void *);
+
 };
 
 struct ath_common;
diff --git a/drivers/net/wireless/ath/ath9k/htc.h 
b/drivers/net/wireless/ath/ath9k/htc.h
index 300d367..e82a0d4 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -444,6 +444,10 @@ static inline void ath9k_htc_stop_btcoex(struct 
ath9k_htc_priv *priv)
 #define OP_BT_SCAN BIT(4)
 #define OP_TSF_RESET   BIT(6)
 
+enum htc_op_flags {
+   HTC_FWFLAG_NO_RMW,
+};
+
 struct ath9k_htc_priv {
struct device *dev;
struct ieee80211_hw *hw;
@@ -482,6 +486,7 @@ struct ath9k_htc_priv {
bool reconfig_beacon;
unsigned int rxfilter;
unsigned long op_flags;
+   unsigned long fw_flags;
 
struct ath9k_hw_cal_data caldata;
struct ath_spec_scan_priv spec_priv;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index fd22940..d7beefe 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -376,17 +376,139 @@ static void ath9k_regwrite_flush(void *hw_priv)
mutex_unlock(priv-wmi-multi_write_mutex);
 }
 
-static u32 ath9k_reg_rmw(void *hw_priv, u32 reg_offset, u32 set, u32 clr)
+static void ath9k_reg_rmw_buffer(void *hw_priv,
+u32 reg_offset, u32 set, u32 clr)
+{
+   struct ath_hw *ah = (struct ath_hw *) hw_priv;
+   struct ath_common *common = ath9k_hw_common(ah);
+   struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common-priv;
+   u32 rsp_status;
+   int r;
+
+   mutex_lock(priv-wmi-multi_rmw_mutex);
+
+   /* Store the register/value */
+   priv-wmi-multi_rmw[priv-wmi-multi_rmw_idx].reg =
+   cpu_to_be32(reg_offset);
+   priv-wmi-multi_rmw[priv-wmi-multi_rmw_idx].set =
+   cpu_to_be32(set);
+   priv-wmi-multi_rmw[priv-wmi-multi_rmw_idx].clr =
+   cpu_to_be32(clr);
+
+   priv-wmi-multi_rmw_idx++;
+
+   /* If the buffer is full, send it out. */
+   if (priv-wmi-multi_rmw_idx == MAX_RMW_CMD_NUMBER) {
+   r = ath9k_wmi_cmd(priv-wmi, WMI_REG_RMW_CMDID,
+ (u8 *) priv-wmi-multi_rmw,
+ sizeof(struct register_write) * 
priv-wmi-multi_rmw_idx,
+ (u8 *) rsp_status, sizeof(rsp_status),
+ 100);
+   if (unlikely(r)) {
+   ath_dbg(common, WMI,
+   REGISTER RMW FAILED, multi len: %d\n,
+   priv-wmi-multi_rmw_idx);
+   }
+   priv-wmi-multi_rmw_idx = 0;
+   }
+
+   mutex_unlock(priv-wmi-multi_rmw_mutex);
+}
+
+static void ath9k_reg_rmw_flush(void *hw_priv)
 {
-   u32 val;
+   struct ath_hw *ah = (struct ath_hw *) hw_priv;
+   struct ath_common *common = ath9k_hw_common(ah);
+   struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common-priv;
+   u32 rsp_status;
+   int r;
+
+   if (test_bit(HTC_FWFLAG_NO_RMW, priv-fw_flags))
+   return;
+
+   atomic_dec(priv-wmi-m_rmw_cnt);
 
-   val = ath9k_regread(hw_priv, reg_offset);
-   val = ~clr;
-   val |= set;
-   ath9k_regwrite(hw_priv, val, reg_offset);
+   mutex_lock(priv-wmi-multi_rmw_mutex);
+
+   if (priv-wmi-multi_rmw_idx) {
+   r = ath9k_wmi_cmd(priv-wmi, WMI_REG_RMW_CMDID,
+ (u8 *) priv-wmi-multi_rmw,
+ sizeof(struct register_rmw) * 
priv-wmi-multi_rmw_idx,
+ (u8 *) rsp_status, sizeof(rsp_status),
+ 100);
+   if (unlikely(r)) {
+   ath_dbg(common, WMI,
+   REGISTER RMW FAILED, multi len

[PATCH v2 11/18] ath9k: ath9k_hw_set_4k_power_cal_tabl: use rmw buffer

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index e5a78d4..fc54fc7 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -389,6 +389,7 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw 
*ah,
}
}
 
+   ENABLE_REG_RMW_BUFFER(ah);
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_NUM_PD_GAIN,
  (numXpdGain - 1)  0x3);
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_PD_GAIN_1,
@@ -396,6 +397,7 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw 
*ah,
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_PD_GAIN_2,
  xpdGainValues[1]);
REG_RMW_FIELD(ah, AR_PHY_TPCRG1, AR_PHY_TPCRG1_PD_GAIN_3, 0);
+   REG_RMW_BUFFER_FLUSH(ah);
 
for (i = 0; i  AR5416_EEP4K_MAX_CHAINS; i++) {
regChainOffset = i * 0x1000;
-- 
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 18/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_def_set_gain

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_def.c | 34 -
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c 
b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 0980590..056f516 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -466,6 +466,7 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
  struct ar5416_eeprom_def *eep,
  u8 txRxAttenLocal, int regChainOffset, int i)
 {
+   ENABLE_REG_RMW_BUFFER(ah);
if (AR5416_VER_MASK = AR5416_EEP_MINOR_VER_3) {
txRxAttenLocal = pModal-txRxAttenCh[i];
 
@@ -483,16 +484,12 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
  AR_PHY_GAIN_2GHZ_XATTEN2_DB,
  pModal-xatten2Db[i]);
} else {
-   REG_WRITE(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
- (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
-  ~AR_PHY_GAIN_2GHZ_BSW_MARGIN)
- | SM(pModal- bswMargin[i],
-  AR_PHY_GAIN_2GHZ_BSW_MARGIN));
-   REG_WRITE(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
- (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
-  ~AR_PHY_GAIN_2GHZ_BSW_ATTEN)
- | SM(pModal-bswAtten[i],
-  AR_PHY_GAIN_2GHZ_BSW_ATTEN));
+   REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
+   SM(pModal- bswMargin[i], 
AR_PHY_GAIN_2GHZ_BSW_MARGIN),
+   AR_PHY_GAIN_2GHZ_BSW_MARGIN);
+   REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
+   SM(pModal-bswAtten[i], 
AR_PHY_GAIN_2GHZ_BSW_ATTEN),
+   AR_PHY_GAIN_2GHZ_BSW_ATTEN);
}
}
 
@@ -504,17 +501,14 @@ static void ath9k_hw_def_set_gain(struct ath_hw *ah,
  AR_PHY_RXGAIN + regChainOffset,
  AR9280_PHY_RXGAIN_TXRX_MARGIN, pModal-rxTxMarginCh[i]);
} else {
-   REG_WRITE(ah,
- AR_PHY_RXGAIN + regChainOffset,
- (REG_READ(ah, AR_PHY_RXGAIN + regChainOffset) 
-  ~AR_PHY_RXGAIN_TXRX_ATTEN)
- | SM(txRxAttenLocal, AR_PHY_RXGAIN_TXRX_ATTEN));
-   REG_WRITE(ah,
- AR_PHY_GAIN_2GHZ + regChainOffset,
- (REG_READ(ah, AR_PHY_GAIN_2GHZ + regChainOffset) 
-  ~AR_PHY_GAIN_2GHZ_RXTX_MARGIN) |
- SM(pModal-rxTxMarginCh[i], 
AR_PHY_GAIN_2GHZ_RXTX_MARGIN));
+   REG_RMW(ah, AR_PHY_RXGAIN + regChainOffset,
+   SM(txRxAttenLocal, AR_PHY_RXGAIN_TXRX_ATTEN),
+   AR_PHY_RXGAIN_TXRX_ATTEN);
+   REG_RMW(ah, AR_PHY_GAIN_2GHZ + regChainOffset,
+   SM(pModal-rxTxMarginCh[i], 
AR_PHY_GAIN_2GHZ_RXTX_MARGIN),
+   AR_PHY_GAIN_2GHZ_RXTX_MARGIN);
}
+   REG_RMW_BUFFER_FLUSH(ah);
 }
 
 static void ath9k_hw_def_set_board_values(struct ath_hw *ah,
-- 
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 05/18] ath9k: add multi_read to be compatible with ath9k_htc

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/init.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index 6c6e884..041decc 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -141,6 +141,16 @@ static unsigned int ath9k_ioread32(void *hw_priv, u32 
reg_offset)
return val;
 }
 
+static void ath9k_multi_ioread32(void *hw_priv, u32 *addr,
+u32 *val, u16 count)
+{
+   int i;
+
+   for (i = 0; i  count; i++)
+   val[i] = ath9k_ioread32(hw_priv, addr[i]);
+}
+
+
 static unsigned int __ath9k_reg_rmw(struct ath_softc *sc, u32 reg_offset,
u32 set, u32 clr)
 {
@@ -530,6 +540,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
ah-hw = sc-hw;
ah-hw_version.devid = devid;
ah-reg_ops.read = ath9k_ioread32;
+   ah-reg_ops.multi_read = ath9k_multi_ioread32;
ah-reg_ops.write = ath9k_iowrite32;
ah-reg_ops.rmw = ath9k_reg_rmw;
pCap = ah-caps;
-- 
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 13/18] ath9k: ath9k_hw_4k_set_board_values: use rmw buffer

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index fc54fc7..0600562 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -1082,6 +1082,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
mask = BIT(0)|BIT(5)|BIT(10)|BIT(15)|BIT(20)|BIT(25);
pwrctrl = mask * bb_desired_scale;
clr = mask * 0x1f;
+   ENABLE_REG_RMW_BUFFER(ah);
REG_RMW(ah, AR_PHY_TX_PWRCTRL8, pwrctrl, clr);
REG_RMW(ah, AR_PHY_TX_PWRCTRL10, pwrctrl, clr);
REG_RMW(ah, AR_PHY_CH0_TX_PWRCTRL12, pwrctrl, clr);
@@ -1096,6 +1097,7 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
clr = mask * 0x1f;
REG_RMW(ah, AR_PHY_CH0_TX_PWRCTRL11, pwrctrl, clr);
REG_RMW(ah, AR_PHY_CH0_TX_PWRCTRL13, pwrctrl, clr);
+   REG_RMW_BUFFER_FLUSH(ah);
}
 }
 
-- 
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 17/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_board_values

[Oleksij Rempel]

replace REG_WRITE to REG_RMW and place every thing in one
RMW buffer.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom_4k.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c 
b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 38dc965..4773da6 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -1037,17 +1037,17 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
}
REG_RMW_BUFFER_FLUSH(ah);
 
-
+   ENABLE_REG_RMW_BUFFER(ah);
REG_RMW_FIELD(ah, AR_PHY_SETTLING, AR_PHY_SETTLING_SWITCH,
  pModal-switchSettling);
REG_RMW_FIELD(ah, AR_PHY_DESIRED_SZ, AR_PHY_DESIRED_SZ_ADC,
  pModal-adcDesiredSize);
 
-   REG_WRITE(ah, AR_PHY_RF_CTL4,
- SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAA_OFF) |
- SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAB_OFF) |
- SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAA_ON)  |
- SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAB_ON));
+   REG_RMW(ah, AR_PHY_RF_CTL4,
+   SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAA_OFF) |
+   SM(pModal-txEndToXpaOff, AR_PHY_RF_CTL4_TX_END_XPAB_OFF) |
+   SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAA_ON)  |
+   SM(pModal-txFrameToXpaOn, AR_PHY_RF_CTL4_FRAME_XPAB_ON), 0);
 
REG_RMW_FIELD(ah, AR_PHY_RF_CTL3, AR_PHY_TX_END_TO_A2_RX_ON,
  pModal-txEndToRxOn);
@@ -1076,6 +1076,8 @@ static void ath9k_hw_4k_set_board_values(struct ath_hw 
*ah,
  pModal-swSettleHt40);
}
 
+   REG_RMW_BUFFER_FLUSH(ah);
+
bb_desired_scale = (pModal-bb_scale_smrt_antenna 
EEP_4K_BB_DESIRED_SCALE_MASK);
if ((pBase-txGainType == 0)  (bb_desired_scale != 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 14/18] ath9k: ath9k_hw_analog_shift_rmw: use REG_RMW

[Oleksij Rempel]

use REG_RMW in ath9k_hw_analog_shift_rmw.
It will double execution speed on usb bus.

Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
 drivers/net/wireless/ath/ath9k/eeprom.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c 
b/drivers/net/wireless/ath/ath9k/eeprom.c
index 971d770..cc81482 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -27,12 +27,7 @@ void ath9k_hw_analog_shift_regwrite(struct ath_hw *ah, u32 
reg, u32 val)
 void ath9k_hw_analog_shift_rmw(struct ath_hw *ah, u32 reg, u32 mask,
   u32 shift, u32 val)
 {
-   u32 regVal;
-
-   regVal = REG_READ(ah, reg)  ~mask;
-   regVal |= (val  shift)  mask;
-
-   REG_WRITE(ah, reg, regVal);
+   REG_RMW(ah, reg, ((val  shift)  mask), mask);
 
if (ah-config.analog_shiftreg)
udelay(100);
-- 
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