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

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

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

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

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

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

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

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

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

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

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

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

[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

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 a

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

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

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

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

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

[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

[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

[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

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 >

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

[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

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

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

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

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

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

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

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

[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

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

gt; 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 didn't really

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

[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

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-

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

gt; Tested 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

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

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

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 >

Re: ath10k: tpc_stats(_final) odd twicepowers and 160Mhz not supported

On Donnerstag, 26. Juli 2018 15:03:54 CEST Sven Eckelmann wrote: > On Dienstag, 10. Juli 2018 08:52:35 CEST Sven Eckelmann wrote: > > On Donnerstag, 28. Juni 2018 12:05:18 CEST Sven Eckelmann wrote: > > > Hi, > > > > > > I have some small question r

Re: [PATCHv2] ath10k : Fix channel survey dump

On Donnerstag, 9. August 2018 20:46:26 CEST Peter Oh wrote: > > In ath9k driver also survey data being accumulated in driver and send > > survey data to user space is accumulated one. same thing we are > > implementing in FW(with WMI request type WMI_BSS_SURVEY_REQ_TYPE_READ) > > instead of

[PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit

but ath10k has to manually call this functionality to limit the currrently set wiphy channels further. Signed-off-by: Sven Eckelmann --- drivers/net/wireless/ath/ath10k/mac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k

Re: [PATCH] ath10k: Prevent active scans on potential unusable channels

On Donnerstag, 26. Juli 2018 17:22:31 CEST Kalle Valo wrote: > Sven Eckelmann writes: > > > On Donnerstag, 26. Juli 2018 16:47:00 CEST Kalle Valo wrote: > > [...] > >> > Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") > >> > Sig

[PATCH RESENT] ath10k: Prevent active scans on potential unusable channels

From: Sven Eckelmann The QCA4019 hw1.0 firmware 10.4-3.2.1-00050 and 10.4-3.5.3-00053 (and most likely all other) seem to ignore the WMI_CHAN_FLAG_DFS flag during the scan. This results in transmission (probe requests) on channels which are not "available" for transmissions. Since th

Re: [PATCH] ath10k: Prevent active scans on potential unusable channels

On Donnerstag, 26. Juli 2018 16:47:00 CEST Kalle Valo wrote: [...] > > Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") > > Signed-off-by: Sven Eckelmann > > You didn't CC linux-wireless so I don't see this in patchwork. Can you > resend, please? In th

Re: ath10k: tpc_stats(_final) odd twicepowers and 160Mhz not supported

On Dienstag, 10. Juli 2018 08:52:35 CEST Sven Eckelmann wrote: > On Donnerstag, 28. Juni 2018 12:05:18 CEST Sven Eckelmann wrote: > > Hi, > > > > I have some small question regarding the debugging functionality introduced > > by > > commit bc64d05220f3 ("at

ath10k: 160MHz/80+80 radar detect with Wave2 cards

Hi, as we know, some wave2 cards support 160MHz (with some limitations). This also requires support for radar detection with 160MHz/80+80 or otherwise cfg80211 will reject this setting. I would like to propose following change but I am unsure whether it actually works correctly on this

Re: ath10k: tpc_stats(_final) odd twicepowers and 160Mhz not supported

On Donnerstag, 28. Juni 2018 12:05:18 CEST Sven Eckelmann wrote: > Hi, > > I have some small question regarding the debugging functionality introduced > by > commit bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 > variants") [1] and

ath10k: Non-passive scan on DFS channels

Hi, it was noticed that ath10k is actively scanning on DFS channels. This seems to be a bad idea. It looks like the passive flag [1] is only specified when no ssid was requested or when the channel is marked as NO_IR [2]. But interestingly, the channel information for the scan also contains a

Re: [PATCH v8] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

On Mittwoch, 4. Juli 2018 12:48:06 CEST Sebastian Gottschall wrote: [...] > can you explain your request? the macros are unchanged and just > reformated for maximum line length restriction. the values have been > taken from QCA's wmi header You use long shift and mask statements in your patch.

Re: [PATCH v8] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

On Mittwoch, 4. Juli 2018 11:29:53 CEST s.gottsch...@dd-wrt.com wrote: > +/* Values defined to set 160 MHz Bandwidth NSS Mapping into FW*/ > +#define BW_NSS_FWCONF_160(x) (BW_NSS_FWCONF_MAP_ENABLE | \ > + (((x - 1) << > BW_NSS_FWCONF_MAP_160MHZ_S) \

Re: 160 mhz crash

On Donnerstag, 28. Juni 2018 11:56:39 CEST Sebastian Gottschall wrote: > btw. openwrt imported my patches recently, but with some openwrt > specific modifications Thanks, just tested these [1]. It doesn't crash anymore and at least the basic functionality seems to work. On Donnerstag, 28. Juni

ath10k: tpc_stats(_final) odd twicepowers and 160Mhz not supported

Hi, I have some small question regarding the debugging functionality introduced by commit bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 variants") [1] and commit 295426669cd6 ("ath10k: implement debugfs interface for Transmit Power Control stats") [2]. Goal of this is

Re: 160 mhz crash

On Samstag, 16. Juni 2018 10:11:27 CEST Sebastian Gottschall wrote: > > this is normal. i already posted a patch on this mailinglist to resolve > this issue, but > > but it hasnt found its way to the main source yes. Problem seems to be that the patch [1] has obvious style problems and open

Re: [PATCH v2] ath10k: support for multicast rate control

On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote: > Issues wmi command to firmwre when multicast rate change is received > with the new BSS_CHANGED_MCAST_RATE flag. > Also fixes the incorrect fixed_rate setting for CCK rates which got > introduced with addition of

Re: ath10k-firmware: QCA4019 hw1.0: Add FRITZ!Box 4040 specific BDFs

On Dienstag, 17. April 2018 10:15:42 CEST Sven Eckelmann wrote: [...] > - QCA4019 hw1.0 > > + bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=AVM-FRITZBox-4040 > sha256sum: > eb866d036149fe4ba35f3f9d0d97e51969b1f1dbac6ea962daf9012ffa75427a > + bus=ahb,bmi-c

Re: ath10k-firmware: QCA4019 hw1.0: Add Meraki MR33 specific BDFs

On Mittwoch, 18. April 2018 16:56:23 CEST Kalle Valo wrote: [...] > I added these now, please check that I did it correctly. It's very easy > for me to make a mistake. > > https://github.com/kvalo/ath10k-firmware/commit/66be3a48d9cf17ace8413cf478a5954483393af4 Thanks, this looks exactly like

ath10k-firmware: QCA4019 hw1.0: Add Meraki MR33 specific BDFs

Hi, The support for this device was added a while ago to OpenWrt. This 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

Re: [PATCH] ath10k:add support for multicast rate control

FDM; + } * bcast + mcast (+ mgmt) have to be set separately I have attached my POC patch (which I was using for packet loss based mesh metrics) and to work around (using debugfs) the silly mgmt vs. mcast/bcast settings of the QCA fw for APs. Many of the information came from Ben Greears

Re: Please add new board files for WLE1216V5-20 and another Compex NIC.

On Mittwoch, 11. April 2018 08:18:15 CEST Tim Harvey wrote: > It's not clear what the process is for getting new board id's > supported in the board.bin files. The reaction of QCA when asking for new IDs was mostly "please go away, we will not talk to you about it". But with the help of Kalle

ath10k-firmware: QCA4019 hw1.0/QCA9888 hw2.0: Add OpenMesh A62 specific BDFs

Hi, I am currently starting to prepare the OpenMesh A62 support for Openwrt. This 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

Re: ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

On Mittwoch, 28. März 2018 08:23:43 CEST Sebastian Gottschall wrote: > correct me if i'm wrong. but isnt the board data stored in flash memory > on these devices like on every other router i know using ath10k chipsets? > this all sounds a little bit curious for me The BDF is stored either in the

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

On Mittwoch, 28. März 2018 11:41:51 CEST ako...@codeaurora.org wrote: [...] > The rate average and throughput are relative. no? In the sense that rate has a tendency to affect the expected throughput - yes. But it is not like the expected throughput perfectly correlates with the rate and you

Re: ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

On Dienstag, 27. März 2018 14:48:05 CEST Dongming Han wrote: > I think the ART data is made based on BDF. Maybe the antCtrlCommon logic > and target power parameter is passed to driver by ART but not BDF? > That way we're all happier no need to mantain these change. Please advise. The

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

On Freitag, 23. März 2018 19:37:14 CEST Anilkumar Kolli wrote: > +static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw, > + struct ieee80211_sta *sta) > +{ > + struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv; > + > +

Re: [PATCH] ath10k: Implement get_expected_throughput callback

On Freitag, 23. März 2018 13:07:00 CET Anilkumar Kolli wrote: [...] > +static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw, > + struct ieee80211_sta *sta) > +{ > + struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv; > +

Re: Spectral Scan - Received power computation

On Dienstag, 20. März 2018 21:02:18 CET sandip sitapara wrote: > I have been trying to calculate power computation from the spectral scan data. [...] > So is there any way to calculate the power computation for ath10k samples? Have a look at

Re: [PATCH 2/2] ath10k: add debugfs support to configure fwtest parameters

On Montag, 5. März 2018 12:29:08 CET Anilkumar Kolli wrote: > @@ -496,6 +497,8 @@ struct ath10k_debug { > u32 reg_addr; > u32 nf_cal_period; > void *cal_data; > + u32 fw_test_param_id; > + u32 fw_test_param_value; > }; Why is it necessary to have these two

ath10k-firmware: QCA4019 hw1.0: Add 8devices Jalapeno specific BDFs

Hi, Robert Marko is currently trying to integrate the support for 8devices Jalapeno in OpenWrt [1]. This module/board 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

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

On Donnerstag, 2. Juni 2016 12:53:55 CET Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > CCK hardware table mapping from QCA99X0 onwards got revised. > The CCK hardware rate values are in a proper order wrt. to > rate and preamble as below > >

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

On Donnerstag, 15. Februar 2018 15:31:04 CET Sebastian Gottschall wrote: > Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and > ipq4019 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: ath10k-firmware: QCA4019 hw1.0: Add OpenMesh A42 specific BDFs

On Freitag, 26. Januar 2018 16:07:10 CET Kalle Valo wrote: [...] > > * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=OM-A42 > > - sha256sum: > > 10700a7ac636d57fe055e5bb4bd5f7bb3f1c282a7f25a8bb2204fc36e8c317bf > > * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=OM-A42 > > - sha256sum: > >

Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

On Montag, 11. Dezember 2017 18:50:09 CET ako...@codeaurora.org wrote: [...] > >> > Just tried this on an QCA9984 which doesn't seem to have the > >> > calibration data in the PCI EEPROM. > >> > > >> > [ 71.728929] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 > >> > target 0x0100

Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

On Freitag, 8. Dezember 2017 18:05:38 CET ako...@codeaurora.org wrote: > On 2017-12-08 17:42, Sven Eckelmann wrote: > > On Donnerstag, 25. Mai 2017 16:21:23 CET ako...@qti.qualcomm.com wrote: > >> From: Anilkumar Kolli <ako...@qti.qualcomm.com> > >> > &

Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

On Donnerstag, 25. Mai 2017 16:21:23 CET ako...@qti.qualcomm.com wrote: > From: Anilkumar Kolli > > QCA99X0, QCA9888, QCA9984 supports calibration data in > either OTP or DT/pre-cal file. Current ath10k supports > Calibration data from OTP only. > > If caldata is loaded

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

in the 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 <sven.eckelm...

[PATCH v2 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 <sven.eckelm...@openmesh.com> --- drivers/net/wireless/ath/ath10k/core.c |

[PATCH v2 0/2] ath10k: DT support for ath10k calibration variant

From: Sven Eckelmann <s...@narfation.org> Hi, here is the second version of the qcom,ath10k-calibration-variant support patchset. I think the ath10k patch describes these changes the best: Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is iden

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

On Dienstag, 28. November 2017 15:45:52 CET Sven Eckelmann wrote: [] > I think that Christian Lamparter also has some BDFs for Asus RT-AC58U, > FRITZ!Box 4040 and Zyxel NBG6617 [3] which could be upstreamed in a similar > way. So please tell us when you want to have these things

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

On Dienstag, 21. November 2017 11:43:36 CET ako...@codeaurora.org wrote: [...] > > I think we should add a special case to not print the warning if mcs == > > 15 until we figure out what it means. > > Fix identified in Firmware and will push ASAP. Is it known when this will be released and for

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

Hi, I am currently trying to integrate the OpenMesh A42 support in LEDE [1]. This 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

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

On Dienstag, 21. November 2017 10:00:20 CET Sebastian Gottschall wrote: > maybe this one? > > i have this qca988x supporting tx/rx rate patch in my local tree. just > need to extract it again > > ath10k: report per-station tx/rate rates to mac80211 This one sounds like

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

On Dienstag, 21. November 2017 09:00:54 CET Sebastian Gottschall wrote: [...] > >> Why is the support for 10.2.4 firmware not upstreamed? I mean the one > >> which is > >> using pktlog to transfer the PEER_STATS information. > > I'm not sure what you are asking. If you are asking the firmware

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

On Dienstag, 15. November 2016 22:07:29 CET 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,

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

On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote: > Am 06.11.2017 um 09:23 schrieb Sven Eckelmann: > > On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote: > >> the assumption made in this patch is obviously wrong (at least for more >

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

On Freitag, 10. März 2017 19:20:54 CEST 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

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:

  1   2   >