ath10k-firmware: QCA9888 hw2.0: Add Plasma Cloud PA2200 specific BDFs

Hi, The support for this device is currently prepared for OpenWrt. This AP requires three special BDFs to get the Wi-Fi PHYs working (correctly). Now to the questions from the wiki page [1]: * description for what hardware this is: - it is a IPQ4019 based board - one QCA40xx radio is used

ath10k-firmware: QCA4019 hw1.0: Add Plasma Cloud PA1200 specific BDFs

Hi, The support for this device is currently prepared for OpenWrt. This AP requires two special BDFs to get the Wi-Fi PHYs working (correctly). Now to the questions from the wiki page [1]: * description for what hardware this is: - it is a IPQ4019 based board - one QCA40xx radio is used as

ath10k-firmware: QCA4019 hw1.0: Add Plasma Cloud PA2200 specific BDFs

Hi, The support for this device is currently prepared for OpenWrt. This AP requires three special BDFs to get the Wi-Fi PHYs working (correctly). Now to the questions from the wiki page [1]: * description for what hardware this is: - it is a IPQ4019 based board - one QCA40xx radio is used

ath10k: Missing airtime scheduler parts

Hi, I was asked what parts are currently missing for (a better) airtime fairness with ath10k. I know that the AQL were merged and enabled for ath10k (and mt76). But there was also the virtual time-based airtime scheduler [1] which was proposed. I think the development on that one didn't continu

Re: ath10k: Missing airtime scheduler parts

Hi, thanks for the reply. I will forward the information. On Tuesday, 1 December 2020 11:56:57 CET Toke Høiland-Jørgensen wrote: > I did recently rebase that patch to the current mac80211-next, actually. > Sent it off to Felix for some testing, but if you wan to give it a go I > can post it to th

Re: EAP AP/VLAN: multicast not send to client

On Tuesday, 2 February 2021 08:04:56 CET Sebastian Gottschall wrote: > the standard ath10k firmware für qca988x chipsets does filter vlans. Just to be sure that we are talking about the same thing: I am (or actually hostapd is) using NL80211_IFTYPE_AP_VLAN here - not 802.1Q. > the only option fo

Re: EAP AP/VLAN: multicast not send to client

On Tuesday, 2 February 2021 09:58:45 CET Sebastian Gottschall wrote: > > Am 02.02.2021 um 09:23 schrieb Sven Eckelmann: > > On Tuesday, 2 February 2021 08:04:56 CET Sebastian Gottschall wrote: > >> the standard ath10k firmware für qca988x chipsets does filter vlans. > &

Re: EAP AP/VLAN: multicast not send to client

On Tuesday, 2 February 2021 10:12:45 CET Sebastian Gottschall wrote: > mmh. l have a idea > > try the following (this a patch in my tree) and check also the wmi > services for this service flag which might be a difference between these > firmwares > > --- a/drivers/net/wireless/ath/ath10k/mac.c

Re: EAP AP/VLAN: multicast not send to client

On Tuesday, 2 February 2021 14:27:01 CET Ben Greear wrote: > Sven, I can build you a series of firmware if you have interest in bisecting > to see if > this is a regression? If it is ok for you then I can go through various firmware builds. But it could be that I can only start with the bisect a

Re: EAP AP/VLAN: multicast not send to client

On Sunday, 7 February 2021 17:50:11 CET Ben Greear wrote: > Here are the images: > > http://www.candelatech.com/downloads/ath10k-4019-10-4b/bisect/ Thanks, will try to have look at them tomorrow evening. Can you confirm which QCA ath10k version was used as the base for this one? I've read somewh

Re: EAP AP/VLAN: multicast not send to client

On Sunday, 7 February 2021 18:42:42 CET Ben Greear wrote: > Somewhere along the way I fixed up raw transmit in my firmware, so possibly > only then will vlans really have a chance of working. The first step was to disable the check which enables AP_VLAN conditional and just enable it all the time

ath10k: qca4019: FW crash on 5GHz when baseEepHeader.nonLinearTxFir == 1

Hi, I've just wanted to test openwrt-21.02 (with ath10k-firmware-qca4019 + kmod- ath10k) on an Plasma Cloud PA1200 router. While this device worked fine in the past, with this upgrade (to the newest firmware from linux-firmware), the 5GHz radio firmware seems to crash whenever I set it up via `i

Re: ath10k: qca4019: FW crash on 5GHz when baseEepHeader.nonLinearTxFir == 1

On Friday, 17 September 2021 18:25:35 CEST Sven Eckelmann wrote: [...] > Interestingly, the crash disappeared when I've changed > baseEepHeader.nonLinearTxFir (offset 0xc2 in the BDF) from 1 to 0. > > The device itself was using firmware 10.4-3.6-00140 (the version currently in

ath10k-firmware: QCA4019 hw1.0: Update Plasma Cloud PA1200 specific BDFs

Hi, the firmware 10.4-3.6-00140 crashed [1] when the 5GHz of the PA1200 was set up. It was noticed that this is somehow related to the option baseEepHeader.nonLinearTxFir which was set to 1. There was no feedback from QCA and the manufacturer about this problem. So as only known workaround (wit

Re: [PATCH v2 1/5] ath10k: QCA4019 hw1.0: update board-2.bin

On Saturday, 26 February 2022 17:39:23 CET Christian Lamparter wrote: > The current situation is: OpenWrt has those board files (as ~40 separate > files) all lined up in: > > Once the board-2.bin in linux-firmware.git is upd

Re: IBSS mode is now supported by CT firmware.

On Monday 01 December 2014 09:57:50 Ben Greear wrote: > If you have time, can you see if you can get encryption working with > ath9k to ath9k? I could not get that working, and I am not sure if > it is my supplicant setup or if I have some other bugs somewhere... > > Please post config files if y

Re: IBSS support in ath10k - our test results and questions

On Thursday 19 March 2015 14:40:42 Ben Greear wrote: > In case you have a public kernel tree available somewhere with all your > patches, that might help speed up someone's attempt to reproduce this? I have uploaded the patchset of our test setup at git://dev.cloudtrax.com/ath10k-ibss-test.git

Re: missing firmware in debian 9

On Freitag, 16. November 2018 08:38:51 CET Anil Duggirala wrote: > hello, > I am getting this message at boot. > > [ 10.678576] ath10k_pci :03:00.0: firmware: failed to load > ath10k/pre-cal-pci-:03:00.0.bin (-2) > [ 10.678631] ath10k_pci :03:00.0: Direct firmware load for > ath1

ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A62 specific BDFs

Hi, The OpenMesh A62 AP requires three special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s would clash with one of the the IPQ401X AP-DK boards because QCA doesn't provide special IDs for customers and seems to use the AP-DK board-ids in the wifi firmware to change its

ath10k-firmware: QCA9888 hw2.0: Update OpenMesh A62 specific BDFs

Hi, The OpenMesh A62 AP requires three special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s would clash with one of the the IPQ401X AP-DK boards because QCA doesn't provide special IDs for customers and seems to use the AP-DK board-ids in the wifi firmware to change its

ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A42 specific BDFs

Hi, The OpenMesh AA2 AP requires two special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s would clash with one of the the IPQ401X AP-DK boards because QCA doesn't provide special IDs for customers and seems to use the AP-DK board-ids in the wifi firmware to change its be

Re: [PATCH] ath10k: fix incorrect multicast/broadcast rate setting

ested on QCA9984 with firmware 10.4-3.6.1-00827 > > Fixes: cd93b83ad92 ("ath10k: support for multicast rate control") > Co-developed-by: Zhi Chen > Signed-off-by: Zhi Chen > Signed-off-by: Pradeep Kumar Chitrapu Tested-by: Sven Eckelmann Was tested on QCA988X wit

Re: [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote: > From: Sebastian Gottschall > > Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based > chipsets with on chipset connected led's using WMI Firmware API. The LED > device will get available named as "ath10k-phyX" at sysfs

Re: [PATCH] ath10k: fix incorrect multicast/broadcast rate setting

On Monday, 25 February 2019 21:00:38 CET Sven Eckelmann wrote: [...] > Tested-by: Sven Eckelmann > > Was tested on QCA988X with 10.2.4-1.0-00041 I just wanted to test it with 802.11s setup on IPQ4019 with 10.4-3.5.3-00057 and QCA9888 with 10.4-3.5.3-00053 (ath10k-firmware) and 10.4-

[PATCH] ath10k: avoid leaving .bss_info_changed prematurely

From: Sven Eckelmann ath10k_bss_info_changed() handles various events from the upper layers. It parses the changed bitfield and then configures the driver/firmware accordingly. Each detected event is handled in a separate scope which is independent of each other - but in the same function. The

Re: [PATCH v2 0/2] Add xo calibration support for wifi rf clock

On Wednesday, 20 March 2019 05:45:09 CET Govind Singh wrote: > PMIC XO is the clock source for wifi rf clock in integrated wifi > chipset ex: WCN3990. Due to board layout errors XO frequency drifts > can cause wifi rf clock inaccuracy. > XO calibration test tree in Factory Test Mode is used to find

Re: [PATCH] ath10k: fix incorrect multicast/broadcast rate setting

hi Chen > Signed-off-by: Zhi Chen > Signed-off-by: Pradeep Kumar Chitrapu > Tested-by: Sven Eckelmann > Patchwork-Id: 10723033 > Signed-off-by: Kalle Valo I thought you just wanted to have this information added to the "Tested on " line by him. So I did

[PATCH v2] ath10k: avoid leaving .bss_info_changed prematurely

From: Sven Eckelmann ath10k_bss_info_changed() handles various events from the upper layers. It parses the changed bitfield and then configures the driver/firmware accordingly. Each detected event is handled in a separate scope which is independent of each other - but in the same function. The

ath10k: TPC: Max antenna gain

Hi, the firmware doesn't seem to parse the max_antenna gain from ath10k_update_channel_list anymore. At least the /sys/kernel/debug/ieee80211/phy0/ath10k/tpc_stats shows me max antenna gain 0 when I set it in ath10k_update_channel_list to 12. grep Gain /sys/kernel/debug/ieee80211/phy*/ath1

[PATCH] ath10k: fix max antenna gain unit

From: Sven Eckelmann Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB steps). This isn't the case for max_antenna_gain - which is still expected by the firmware as dB. The firmware is converting it from dB to the internal (twicepower) representation when it calcu

Re: ath10k: TPC: Max antenna gain

On Tuesday, 11 June 2019 12:59:25 CEST Sven Eckelmann wrote: > Hi, > > the firmware doesn't seem to parse the max_antenna gain from > ath10k_update_channel_list anymore. At least the > /sys/kernel/debug/ieee80211/phy0/ath10k/tpc_stats shows me max antenna gain 0

[PATCH v2] ath10k: fix max antenna gain unit

From: Sven Eckelmann Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB steps). This isn't the case for max_antenna_gain - which is still expected by the firmware as dB. The firmware is converting it from dB to the internal (twicepower) representation when it calcu

ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A62 specific BDFs

[resent of mail from 2019-06-11; seems like @datto.com mail server ate the outgoing mails] Hi, The OpenMesh A62 AP requires three special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s would clash with one of the the IPQ401X AP-DK boards because QCA doesn't provide specia

ath10k-firmware: QCA9888 hw2.0: Update OpenMesh A62 specific BDFs

[resent of mail from 2019-06-11; seems like @datto.com mail server ate the outgoing mails] Hi, The OpenMesh A62 AP requires three special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s would clash with one of the the IPQ401X AP-DK boards because QCA doesn't provide specia

ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A42 specific BDFs

[resent of mail from 2019-06-11; seems like @datto.com mail server ate the outgoing mails] Hi, The OpenMesh AA2 AP requires two special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s would clash with one of the the IPQ401X AP-DK boards because QCA doesn't provide special

[PATCH v3] ath10k: avoid leaving .bss_info_changed prematurely

From: Sven Eckelmann ath10k_bss_info_changed() handles various events from the upper layers. It parses the changed bitfield and then configures the driver/firmware accordingly. Each detected event is handled in a separate scope which is independent of each other - but in the same function. The

Re: [PATCH] cfg80211: Add cumulative channel survey dump support.

On Thursday, 31 May 2018 11:06:59 CEST vnara...@codeaurora.org wrote: > I will sent next version of patch with updated commit log. Can you please point me to the second version? Btw. I've just checked the minimal changes in ath10k to get this working. It seems we need SURVEY_INFO_NON_ACC_DATA in

Re: [PATCH] cfg80211: Add cumulative channel survey dump support.

On Tuesday, 17 September 2019 19:27:50 CEST Sven Eckelmann wrote: [...] > So whatever the firmware does when it gets a > WMI_BSS_SURVEY_REQ_TYPE_READ_CLEAR - it is not a CLEAR after read. And they > also don't simply wrap around but there all values have to get some kind of &g

[RFC PATCH 0/2] ath10k: provide survey info as accumulated data

From: Sven Eckelmann Hi, it was observed that ath9k provides accumulated survey counters but ath10k neither provides deltas nor accumulated counters. Instead it returns some value which was returned at some point from the firmware. But as it turns out, this data is not reliable. To make it

[RFC PATCH 2/2] ath10k: regularly fetch survey counters

From: Sven Eckelmann The survey counters from firmwares like 10.2.4 are not actually using the full 64 bit. Instead, they only use the lower 31 bit and overflow ever 14-30s. The driver must frequently fetch the survey data and add it to the survey data storage to avoid this problem and to

[RFC PATCH 1/2] ath10k: report survey info as accumulated values

From: Sven Eckelmann The survey report is expected to contain a counter which is increasing all the time. But ath10k reports some kind of delta. This can either be the difference to the last get_survey or the difference to some even older get_survey because the values are sometimes cached and

Re: [PATCH] cfg80211: Add cumulative channel survey dump support.

On Wednesday, 18 September 2019 14:58:46 CEST Ben Greear wrote: [...] > > So as Ben Greear said, the 10.4 firmware version is fixed and 10.2.* (for > > the wave-1 cards) is still broken and we need a QCA firmware engineer to > > fix it. Or to work around it by polling every couple of seconds and >

Re: [PATCH] cfg80211: Add cumulative channel survey dump support.

On Wednesday, 18 September 2019 15:07:11 CEST Sven Eckelmann wrote: [...] > I have now prepared a test patch [1] to get the data every 10 seconds. This > was a compromise between having useful information over time and the > overflowing problem. ...over time without too many &qu

Re: [RFC PATCH 0/2] ath10k: provide survey info as accumulated data

On Monday, 14 October 2019 00:15:20 CEST Sebastian Gottschall wrote: > i checked your patch on 10.4 based chipsets with 9984. the values are > now looking bogus and wrong at all. busy and active time time in ms does > increase in hours each second > the problem seem to be that your patch is 10.2.

Re: [PATCH] ath10k: increase rx buffer size to 2048

On Wednesday, 5 February 2020 20:10:43 CEST Linus Lüssing wrote: > From: Linus Lüssing > > Before, only frames with a maximum size of 1528 bytes could be > transmitted between two 802.11s nodes. > > For batman-adv for instance, which adds its own header to each frame, > we typically need an MTU

Re: [PATCH] ath10k: increase rx buffer size to 2048

On Wednesday, 1 April 2020 09:00:49 CEST Sven Eckelmann wrote: > On Wednesday, 5 February 2020 20:10:43 CEST Linus Lüssing wrote: > > From: Linus Lüssing > > > > Before, only frames with a maximum size of 1528 bytes could be > > transmitted between two 802.11s nodes.

Re: [PATCH 1/2] ath10k: use cumulative survey statistics

On Monday, 4 May 2020 17:41:21 CEST Markus Theil wrote: > ath10k currently reports survey results for the last interval between each > invocation of NL80211_CMD_GET_SURVEY. For concurrent invocations, this > can lead to unexpectedly small results, e.g. when hostapd uses survey > data and iw survey

Re: [PATCH 2/2] ath11k: use cumulative survey statistics

On Monday, 4 May 2020 17:41:22 CEST Markus Theil wrote: [...] > diff --git a/drivers/net/wireless/ath/ath11k/wmi.c > b/drivers/net/wireless/ath/ath11k/wmi.c > index c2a972377687..322ddfda5bfd 100644 > --- a/drivers/net/wireless/ath/ath11k/wmi.c > +++ b/drivers/net/wireless/ath/ath11k/wmi.c > @@ -5

Re: [PATCH 1/2] ath10k: use cumulative survey statistics

On Tuesday, 5 May 2020 01:46:12 CEST Rajkumar Manoharan wrote: [...] > IIRC this was fixed a while ago by below patch. Somehow it never landed > in ath.git. > Simple one line change is enough. > > https://patchwork.kernel.org/patch/10550707/ Because it doesn't work for everything. Remember that

Re: [PATCH 1/2] ath10k: use cumulative survey statistics

On Tuesday, 5 May 2020 09:01:34 CEST Sven Eckelmann wrote: > On Tuesday, 5 May 2020 01:46:12 CEST Rajkumar Manoharan wrote: > [...] > > IIRC this was fixed a while ago by below patch. Somehow it never landed > > in ath.git. > > Simple one line change i

Re: [PATCH 1/2] ath10k: use cumulative survey statistics

On Tuesday, 5 May 2020 09:49:46 CEST Sven Eckelmann wrote: [...] > See also https://patchwork.kernel.org/patch/9701459/ And I completely forgot about this one: https://patchwork.kernel.org/patch/10417673/ Kind regards, Sven signature.asc Description: This is a digitally signed mess

Re: [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote: [...] > could somone clarify the state here and why it was dropped? > the original patch i wrote does exclude the soc chipsets, but the patch > was later reorganized and some part have been rewritten > so i'm not sure if it covers

Re: [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

On Monday, 25 May 2020 11:22:13 CEST Sven Eckelmann wrote: [...] > And it still can with this OpenWrt version. But it doesn't seem to happen > with > the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000 > commits inbetween. So no idea what changed (just

[PATCH v5] ath10k: provide survey info as accumulated data

John Deere <24601dee...@gmail.com> [s...@narfation.org: adjust commit message] Signed-off-by: Sven Eckelmann --- v5: * add additional tested devices * restructure commit message v4: * updated signed-off-by v3: * Rebased on TOT and added Tested-by Everything expect QCA9984 hw1.0 firmware 10.4

Re: CT ath10k firmware now supports IBSS + RSN

Hi, On Friday 10 April 2015 16:32:29 Ben Greear wrote: > First, thanks to everyone that helped me with questions, > QCA/Tieto's upstream patches, etc. > > This needs more testing, but it appears to at least mostly work. > > I am using this 4.0 related kernel. I think only the last 3 patches > a

Re: CT ath10k firmware now supports IBSS + RSN

On Monday 17 August 2015 08:33:06 Ben Greear wrote: [...] > > * IBSS/RSN isn't working between ath10k<->ath10k, ath9k<->ath10k > >(works well between ath9k<->ath9k) > >- the ath10k device doesn't seem to send its broadcast frames > > after the handshake finished (ath9k already tries t

Re: CT firmware and linux kernel patches for OpenWRT( ar71xx - Tp-Link 1750AC )

On Wednesday 26 August 2015 18:59:51 s prasad wrote: > Does anybody have patches for CT firmware testing using OpenWRT environment. > I tried to create patch, however OpenWRT patches supporting only for > kernel versions 3.18 and 4.1 at the same time CT Kernels supporting > 3.17_dev, 4.0.4 and 4.2.

Re: [PATCH v3] ath10k: set MAC timestamp in management Rx frame

On Thursday 25 February 2016 10:53:23 Peter Oh wrote: > > I see new warnings: > > > > drivers/net/wireless/ath/ath10k/wmi.c:2199:16: warning: restricted __le32 > > degrades to integer > > drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: restricted __le32 > > degrades to integer > > drivers/

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

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

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

Add the hardware name, revision, firmware names and update the pci_id table. QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about he firmware interface are currently unknown. Signed-off-by: Sven Eckelmann --- drivers/net/wireless/ath/ath10k/core.c | 20

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

The QCA9887 stores its calibration data (board.bin) inside the EEPROM of the target. This has to be downloaded manually to allow the device to initialize correctly. Signed-off-by: Sven Eckelmann --- drivers/net/wireless/ath/ath10k/core.c | 41 +- drivers/net/wireless/ath/ath10k/core.h

Re: [PATCH v1] ath10k: Fix 10.4 extended peer stats update

On Wednesday 11 May 2016 11:54:30 Mohammed Shafi Shajakhan wrote: > #else > -static inline void ath10k_sta_update_rx_duration(struct ath10k *ar, > - struct list_head *peer) > +static inline > +void ath10k_sta_update_rx_duration(struct ath10k *ar, > +

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

On Thursday 26 May 2016 17:32:30 Valo, Kalle wrote: > Sven Eckelmann writes: > > > the QCA9887 chip is similar to the QCA988x chips. But it requires a special > > firmware and uses a different calibration data source. Unfortunately, no > > working firmware currently exist

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

On Friday 27 May 2016 12:44:52 Valo, Kalle wrote: [...] > > But maybe I should add that the results with the original AP147 firmware > > also > > wasn't better. > > That doesn't sound good. Maybe a calibration issue? Maybe but I don't have a different card to compare it to. [...] > I pushed a n

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

On Saturday 04 June 2016 13:26:39 you wrote: [...] > Looking at this again I noticed that we issue this warning even if > EEPROM is not supported, which I think is wrong. I fixed this in the > pending branch, the diff is below. > > I also renamed target_board_data to cal_eeprom because, at least t

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

On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote: [...] > [shafi] it would be helpful if you can share your basic test results (if its > possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz. > Or both of them were tried ? * 5GHz-only (I have no 2.4GHz capable ca

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote: [...] > > We're testing encrypted AP + Mesh quite successfully right now with > > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b > > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip. >

QCA4019: calibration files and board files

Hi, I've just tested LEDE-IPQ40XX [1] after the official open QSDK 1.1.3 [2] was not able to boot on an ap.dk01.1-c1-like device. This seemed to work exceptionally well (the device basically worked after the first build) but I got a little suspicious when looking at the code which it uses f

Re: QCA4019: calibration files and board files

On Dienstag, 17. Januar 2017 12:54:52 CET Sven Eckelmann wrote: > Hi, > > I've just tested LEDE-IPQ40XX [1] after the official open QSDK 1.1.3 [2] > was > not able to boot on an ap.dk01.1-c1-like device. This seemed to work > exceptionally well (the device basically

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

On Montag, 19. September 2016 11:34:00 CET Sven Eckelmann wrote: > On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote: > [...] > > > We're testing encrypted AP + Mesh quite successfully right now with > > > this firmware: https://github.com/kvalo/at

Re: QCA4019: calibration files and board files

Thanks for the insights On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote: [...] > * I can't talk about what Christian did, where he got the board data > from, etc, etc. You mentioned a DK style board, but didn't say which. model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1";

QCA4019 firmware: wrong numChain setting for bmi-board 16+17

Hi, I've just noticed that the numChain in (ath10k/)QCA4019/hw1.0/board-2.bin is wrong in the bus=ahb,bmi-chip-id=0,bmi-board-id=16 and bus=ahb,bmi-chip-id=0,bmi-board-id=17 from the linux-firmware and ath10k-firmware repository. It is 0x4 for a 2x2 device. This was fixed in the QSDK by commit 171

Re: QCA4019: calibration files and board files

Hi Anilkumar Kolli, we've noticed that your change in QSDK [1] removed the call to ath10k_download_and_run_otp in ath10k_download_cal_data after the call to ath10k_core_get_board_id_from_otp. We reported [2] this to ath10k when we asked for some clarifications regarding the loading process of the

Re: QCA4019: calibration files and board files

On Donnerstag, 9. Februar 2017 15:56:59 CET ako...@codeaurora.org wrote: [...] > Thanks for pointing this, I broke the sequence in qsdk while loading cal > data > from flash MTD partitions. I will revert these changes in QSDK patch[1]. > > @@ -224,21 +224,13 @@ > +* from board data

Re: QCA4019: calibration files and board files

On Dienstag, 28. Februar 2017 19:22:32 CET Rajkumar Manoharan wrote: > On 2017-02-27 23:58, Sven Eckelmann wrote: > > It looks to me now that this information is contradicting your > > implementation > > (which now loads the data from 0:ART partition [1] like pre-cal data

Re: QCA4019 firmware: wrong numChain setting for bmi-board 16+17

On Mittwoch, 8. Februar 2017 11:40:07 CET Sven Eckelmann wrote: > Hi, > > I've just noticed that the numChain in (ath10k/)QCA4019/hw1.0/board-2.bin is > wrong in the bus=ahb,bmi-chip-id=0,bmi-board-id=16 and > bus=ahb,bmi-chip-id=0,bmi-board-id=17 from the linux-firmware a

Re: QCA4019: calibration files and board files

Hi Adrian, On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote: > If people aren't using unique BMI IDs (which is another question we > have for QCA) then it's possible you don't have enough information to > "know" which board data to use, so it has to be overridden by a custom > package. W

Re: QCA4019: calibration files and board files

On Dienstag, 7. März 2017 08:30:54 CET Adrian Chadd wrote: > "use your own bmi ids". :-) > > (yeah, this is going to make open source firmware for these things > more painful than it should be. :( ) Thanks for the reply. I was just informed that the firmware binary will behave differently depend

Re: QCA4019: calibration files and board files

On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote: [...] > I haven't followed the discussion very closely, so I might be way off, > but for laptop SMBIOS implementations Waldemar added a variant field to > board-2.bin so that we can have multiple images for the same subsystem > id. Could i

Re: QCA4019: calibration files and board files

On Donnerstag, 9. März 2017 13:46:00 CET Sven Eckelmann wrote: > The board-2.bin would then require entries for bus=ahb,bmi-chip-id=0,bmi- > board-id=16,variant=RT-AC58U and bus=ahb,bmi-chip-id=0,bmi-board- > id=17,variant=RT-AC58U. Small remark: I know the SMBIOS format would be "

[RFC] ath10k: search DT for qcom,ath10k-calibration-variant

From: Sven Eckelmann Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified on QCA4019 using bus, bmi-chip-id and bmi-board-id. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it

Re: [RFC] ath10k: search DT for qcom,ath10k-calibration-variant

On Donnerstag, 9. März 2017 16:36:15 CET Sven Eckelmann wrote: > .../bindings/net/wireless/qcom,ath10k.txt | 3 +++ > drivers/net/wireless/ath/ath10k/core.c | 31 > +- > 2 files changed, 33 insertions(+), 1 deletion(-) Nice, not only us

[RFC v2] ath10k: search DT for qcom,ath10k-calibration-variant

s would create the boarddata identifiers for the board-2.bin search * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U Cc: Waldemar Rymarkiewicz Signed-off-by: Sven Eckelmann --- Cc: Christian Lamparter Cc: John Crispin Cc: Si

[PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

correct calibration data when combined with the pre-calibration data from the device. An additional "variant" information has to be provided (via SMBIOS or DT) to select the correct board data for a design which was modified by an ODM. Signed-off-by: Sven Eckelmann --- Since RFC: - Spli

[PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant

s would create the boarddata identifiers for the board-2.bin search * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U Signed-off-by: Sven Eckelmann --- Since RFC: - initialize variant pointer to have it initialized to NULL when

Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant

On Freitag, 10. März 2017 19:20:54 CET Christian Lamparter wrote: [...] > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

On Montag, 20. März 2017 10:07:33 CET Rob Herring wrote: > On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote: > > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct > > board data file on QCA4019 based devices. Multiple different boards sha

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

On Montag, 20. März 2017 09:42:05 CET Adrian Chadd wrote: > Vendors using ath10k will like this. I mean, I'm using ath10k, and I > really like this moving forward. This will make life so much easier in > the long run. > > Everyone else isn't using board-2.bin; they're just copying > calibration/bo

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

On Dienstag, 21. März 2017 08:00:34 CET Rob Herring wrote: [...] > > It would then up with something like this as compatibility string: > > > > * qcom,ipq4019-wifi-asus-rt-ac58u > > * qcom,ipq4019-wifi-fritzbox-4040 > > * qcom,ipq4019-wifi-netgear-whatever > > * qcom,ipq4019-wifi-openmesh-i-hav

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

On Dienstag, 21. März 2017 21:56:54 CET Rob Herring wrote: [...] > Is this always the case? There's never some variation beyond the > reference design that a BDF difference can't handle? I have no knowledge about anything which isn't handled directly by the BDF variants. But maybe Kalle can correc

Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

On Dienstag, 15. November 2016 22:07:29 CEST ako...@qti.qualcomm.com wrote: > From: Anilkumar Kolli > > Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS' > event, Firmware sends one HTT event for every four PPDUs. > HTT payload has success pkts/bytes, failed pkts/bytes, retry > pkt

[PATCH] ath10k: Fix reported HT MCS rates with NSS > 1

10.4") Signed-off-by: Sven Eckelmann --- drivers/net/wireless/ath/ath10k/htt_rx.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c index 84b6067ff6e7..6c0a821fe79d 10

Re: [PATCH] ath10k: Fix reported HT MCS rates with NSS > 1

On Donnerstag, 11. Mai 2017 11:39:46 CEST Arend Van Spriel wrote: [...] > So you leave VHT as is. Did you check with 11ac device? I am wondering > if it needs the same change. VHT MCS rates are reported by drivers with NSS + MCS rates 0-9 [1] as separated values. So I would say that the code is c

Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

[9.707224] [] ? kthread_park+0x60/0x60 [9.714363] [] ? ret_from_fork+0x25/0x30 [ 9.721589] ---[ end trace 6814c79dfe2a14da ]--- Tested-by: Sven Eckelmann Kind regards, Sven signature.asc Description: This is a digitally signed message part. __

Re: ath10k: Configure rxnss_override for 10.4 firmware.

On Mittwoch, 15. Februar 2017 01:26:58 CEST Kalle Valo wrote: > Ben Greear wrote: > > From: Ben Greear > > > > QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz. [] > Does not apply: > > error: patch failed: drivers/net/wireless/ath/ath10k/mac.c:2760 > error: drivers/net/wireless

[PATCH v2 2/3] ath10k: Configure rxnss_override for 10.4 firmware.

. This could use some testing Signed-off-by: Ben Greear [sven.eckelm...@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup] Signed-off-by: Sven Eckelmann --- v2: - rebased patch - minor cleanups - removal of the 160 MHz workaround (see patch 1) drivers/net/wireless/ath/ath10k

[PATCH v2 3/3] ath10k: Set rxnss_override for QCA9888

QCA9888 supports VHT80 with 2x2. But it only support 1x1 with VHT160 or VHT80+80. Inform userspace and the the QCA firmware about that limitation whenever VHT80+80 or VHT160 is configured. Signed-off-by: Sven Eckelmann --- v2: - new patch drivers/net/wireless/ath/ath10k/mac.c | 8 1

[PATCH v2 1/3] ath10k: Use complete VHT chan width for 160MHz workaround

nse. The correct mask for the VHT channel width should be used instead to make this check more readable. Signed-off-by: Ben Greear [sven.eckelm...@openmesh.com: separate 160Mhz workaround cleanup, add commit message] Signed-off-by: Sven Eckelmann --- v2: - extracted this cleanup portion and c

Re: [PATCH v2 2/3] ath10k: Configure rxnss_override for 10.4 firmware.

On Freitag, 16. Juni 2017 08:50:13 CEST Kalle Valo wrote: > We have hw_params for stuff like this so I changed this and the > following patch to use that. Please review: Looks good. Thanks for adjusting the patches. Kind regards, Sven signature.asc Description: This is a digitally signed

ath: Incorrect regDomainPairs/allCountries settings

Hi, I just had two inquiries from Vietnam and Singapore regarding the used CTL limits by Atheros based chips. I've checked through the code and noticed that regd_common.h assigns SG to APL6_WORLD and VN to NULL1_WORLD. * SG: APL6_WORLD - 2.4GHz: CTL_ETSI - 5GHz: CTL_ETSI * VN: NULL1_W

  1   2   >