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

, 2023 at 08:03:23PM +0300, Kalle Valo wrote: Christian Marangi writes: 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 "ath10

Re: New staging repos for ath1*k firmware

Am 07.03.2024 um 17:49 schrieb Kalle Valo: Robert Marko writes: On Wed, Mar 6, 2024 at 8:23 PM Jeff Johnson wrote: Historically, prior to being incorporated into the linux-firmware project, firmware for kernel.org ath1*k drivers has been first published to Kalle's GitHub: https://github.c

Re: QCA9892 firmware crash (10.2.4.70.70) on Linux 6.0.1

try 10.2.4-1.0-00047 thats the one i'm using Am 01.02.2023 um 11:07 schrieb Claudius Zingerli: Hi, After about one hour of operation (~6 scans/connects/disconnects), the chipset's firmware seems to have crashed. As the firmware used is >3y old, are there any updated versions available? How a

Re: [RFC v2] wifi: ath10k: Implement duplicate detection for non-offloaded PCIe

this patch causes severe performance issues on 988x Am 06.12.2022 um 08:30 schrieb Zhi-Jun You: Chips like QCA9984, IPQ4019 doesn't do duplicate detection in firmware. Implement it in driver so it can skip a check in mac80211. Check only the first skb since all the skbs in amsdu share the same

Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

Am 20.09.2022 um 01:42 schrieb Sergey Ryazanov: Hello, I would like to add my 2c. On Mon, Sep 19, 2022 at 8:25 PM Tim Harvey wrote: I'm not clear if there are many other cards that have this same issue. The list of cards with unprogrammed regdomain can be extended with several relatively mo

Re: [PATCH] ath10k: remove TX lock from ath10k_htt_tx_inc_pending

Am 17.09.2019 um 09:12 schrieb Kalle Valo: Erik Stromdahl wrote: This commit removes the call to ath10k_mac_tx_lock() from ath10k_htt_tx_inc_pending() in case the high water mark is reached. ath10k_mac_tx_lock() calls ieee80211_stop_queues() in order to stop mac80211 from pushing more TX da

[PATCH] ath10k: Fix tx hanging

q was not wake when the num_tx_pending counter reaches zero. To fix this, we simply move the wake_up call to htt_tx_dec_pending, since this call was missed on several locations within the ath10k code. Signed-off-by: Sebastian Gottschall --- drivers/net/wireless/ath/ath10k/htt_tx.c | 3 +++ driver

Re: Reading default values of Roaming parameters with wmi commands

Am 15.04.2021 um 05:24 schrieb Arvind: Hi All, I have been using ath10k driver for a qualcomm chip QCA9377 based module used in a custom board and I was looking at the code to see if there is a way to read the values of the following Roaming parameters from firmware to find its defaul

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

then it might be something different. i'm not sure at that point. but consider that AP_VLAN is also used for WDS STA/WDS AP implementations. so each wds station becomes a individual interface on ap side for bridging. that might of course have a influence to broadcast/multicast frames Interestin

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

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. Just to be sure that we are talking about the same thing: I am (or actually hostapd is) using

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

the standard ath10k firmware für qca988x chipsets does filter vlans. the only option for you is using the CT firmware by candelatech, which does not suffer from this issue. Sebastian Am 01.02.2021 um 21:54 schrieb Sven Eckelmann: Hi, I was just testing EAP with dynamic_vlan=2 (and a radius ser

Re: WMM not working for mcast packets on ath10k

Am 11.08.2020 um 01:05 schrieb Ben Greear: On 8/10/20 3:08 PM, Ahmed Zaki wrote: Hello, I have 2 ath10k devices set in Mesh Point mode. When I use iptables' DSCP target to set the WMM AC for some traffic ports to VO, the rules work fine but only for unicast packets. All broadcast on the target

Re: [RFC 0/7] Add support to process rx packets in thread

i agree. i just can say that i tested this patch recently due this discussion here. and it can be changed by sysfs. but it doesnt work for wifi drivers which are mainly using dummy netdev devices. for this i made a small patch to get them working using napi_set_threaded manually hardcoded in the

Re: [RFC 0/7] Add support to process rx packets in thread

Am 25.07.2020 um 14:25 schrieb Hillf Danton: On Sat, 25 Jul 2020 12:38:00 +0200 Sebastian Gottschall wrote: you may consider this https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html <https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html>

Re: [RFC 0/7] Add support to process rx packets in thread

you may consider this https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1142611.html years ago someone already wanted to bring this feature upstream, but it was denied. i already tested this patch the last

Re: [RFC 7/7] ath10k: Handle rx thread suspend and resume

your patch seem to only affect the WCN3990 chipset. all other ath10k supported chipset are not supported here. so you see a chance to implement this more generic? Sebastian Am 21.07.2020 um 19:14 schrieb Rakesh Pillai: During the system suspend or resume, the rx thread also needs to be suspen

Re: [PATCH] ath10k: Avoid override CE5 configuration for QCA99X0 chipsets

Yeah, that patch is buggy but this should fix it: commit 32221df6765b3773ff1af37c77f8531ebc48f246 Author: Arnd Bergmann AuthorDate: Sat May 9 14:06:33 2020 +0200 Commit: Kalle Valo CommitDate: Tue May 12 10:33:13 2020 +0300 ath10k: fix ath10k_pci struct layout this patch seem to b

Re: [PATCH] ath10k: Avoid override CE5 configuration for QCA99X0 chipsets

will check it Am 29.05.2020 um 17:36 schrieb Kalle Valo: Sebastian Gottschall writes: Am 05.05.2020 um 09:34 schrieb Kalle Valo: Maharaja Kennadyrajan wrote: As the exisiting CE configurations are defined in global, there are the chances of QCA99X0 family chipsets CE configurations are

Re: [PATCH] ath10k: Avoid override CE5 configuration for QCA99X0 chipsets

Am 05.05.2020 um 09:34 schrieb Kalle Valo: Maharaja Kennadyrajan wrote: As the exisiting CE configurations are defined in global, there are the chances of QCA99X0 family chipsets CE configurations are getting changed by the ath10k_pci_override_ce_config() function. The override will be hit a

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

Am 25.05.2020 um 11:22 schrieb Sven Eckelmann: 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

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

Am 22.05.2020 um 12:29 schrieb Kalle Valo: (please don't top post) Sebastian Gottschall writes: this code is not in use in its original form for ipq4019. i have seen that his patch is also dropped from ath.git but is still in use by openwrt. could somone clarify the state here and w

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

ok into it, yet. the led code will just be used if you set a trigger. otherwise it doesnt touch the gpios. the code itself was written to make use of the led's builtin to several routers. if you dont set a led trigger, nothing will happen Best, Vincent On 20.05.20 09:39, Sebastian Gottsc

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

reorganized and some part have been rewritten so i'm not sure if it covers the scenario mentioned here, which i did take care of Sebastian Am 26.02.2019 um 10:16 schrieb Sven Eckelmann: On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote: From: Sebastian Gottschall Adds LED and GPIO Co

Re: [RESEND] ath10k: add tx hw 802.11 encapusaltion offloading support

no way. check that you applied code correctly and enabled ethernetmode parameter. iperf or ping also wouldn't start from wired machine in ethernetmode unless pinged from wireless machine first let me verify this again. maybe i'm wrong. ___ ath10k

Re: [RESEND] ath10k: add tx hw 802.11 encapusaltion offloading support

Am 18.12.2019 um 23:45 schrieb Tom Psyborg: ccing Johannes Berg since upstream change (mac80211-next) breaks build: In the commit log its written: remove SUPPORTS_80211_ENCAP HW flag Any sane reasons for doing that? mac80211 fails to build because of removed flags, this is on backports-5.3-rc4

Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels

the calibration intervall for 988x. for 9984 i need to check if its different Thanks, Ben On Tue, Dec 17, 2019 at 8:05 PM Sebastian Gottschall wrote: Am 18.12.2019 um 03:37 schrieb Ben Greear: On 12/17/2019 06:12 PM, Sebastian Gottschall wrote: i dont know what you want to compare

Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels

ure changes (if change is more than 30 degrees celsius) and various baseband hanging checks. in addition its still periodic thats the case for 10.4 and also for 10.2 based firmwares. (i checked qca998x and qca9984 firmware codes) On Tue, Dec 17, 2019 at 8:05 PM Sebastian Gottschall wrote: A

Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels

Am 18.12.2019 um 03:37 schrieb Ben Greear: On 12/17/2019 06:12 PM, Sebastian Gottschall wrote: i dont know what you want to compare here. 1. you compare 2 different wifi chipsets. both have different sensititivy and overall output power spec 2. both have different amount of antenna

Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels

i dont know what you want to compare here. 1. you compare 2 different wifi chipsets. both have different sensititivy and overall output power spec 2. both have different amount of antenna chains. which does make a difference in input sensitivity 3. the patch ben made has no effect on qca988

Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels

currently debugging in your code, but i already have seen that the values are wrong now for this chipset Thanks for testing.  I'll add a check for 0 and ignore that value too.  That seem OK? i tested already the 0 check and it works Were the per-chain values OK? on 9984 i see no disadvanta

Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels

result of my tests on qca988x rxd->ppdu_start.rssi_comb_ht is always zero. so you need to add a additional check Am 17.12.2019 um 13:02 schrieb Sebastian Gottschall: i see a issue in your patch for qca988x chipsets +    if (rxd->ppdu_start.rssi_comb_ht != 0x80) { +    status-&

Re: [PATCH] ath10k: Per-chain rssi should sum the secondary channels

i see a issue in your patch for qca988x chipsets + if (rxd->ppdu_start.rssi_comb_ht != 0x80) { + status->signal = ATH10K_DEFAULT_NOISE_FLOOR + + rxd->ppdu_start.rssi_comb_ht; + } this is always true for qca988x, but the field is not provided on th

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

10.4 has additional 64 bit cycle counters. see wmi_pdev_bss_chan_info_event the standard 32 cycle counters do individual wrap around as far as i know Am 14.10.2019 um 09:07 schrieb Sven Eckelmann: On Monday, 14 October 2019 00:15:20 CEST Sebastian Gottschall wrote: i checked your patch on

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

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.4 only related. ath_clean_survey does not trigger on 10.4 so the values doub

Re: [PATCH] ath10k: restore QCA9880-AR1A (v1) detection

Am 10.09.2019 um 16:11 schrieb Ben Greear: On 09/10/2019 06:51 AM, Sebastian Gottschall wrote: the tplink archer c7 v1 indeed has this hw 1 version. but thats the only device i know comming with this chipset version but the v1 has also a minipcie slot and is not soldered like all other

Re: [PATCH] ath10k: restore QCA9880-AR1A (v1) detection

the tplink archer c7 v1 indeed has this hw 1 version. but thats the only device i know comming with this chipset version but the v1 has also a minipcie slot and is not soldered like all other revisions.  so i just replaced the card on my test device. in addition we may ask ben grear if he is able

Re: [PATCH] ath10k: add cleanup in ath10k_sta_state()

this patch will kick our any peer each time you call for statistics.so it will not solve anything. it creates a massive bug. usually just kfree is enough here but even this will maybe just kill existing stats Am 15.08.2019 um 23:04 schrieb Wenwen Wang: If 'sta->tdls' is false, no cleanup is ex

Re: Problem with 9984 in routed mode with 512b frames.

Am 17.05.2019 um 18:00 schrieb Ben Greear: On 5/17/19 8:47 AM, Adrian Chadd wrote: On Fri, 17 May 2019 at 08:06, Sebastian Gottschall wrote: personally i think going back to basic rates like 2 mbit makes no sense anyway. its that dead slow that a connection must break and has to be broken

Re: Problem with 9984 in routed mode with 512b frames.

Am 17.05.2019 um 17:47 schrieb Adrian Chadd: On Fri, 17 May 2019 at 08:06, Sebastian Gottschall wrote: personally i think going back to basic rates like 2 mbit makes no sense anyway. its that dead slow that a connection must break and has to be broken if this doesnt work. still a shame

Re: Problem with 9984 in routed mode with 512b frames.

Am 17.05.2019 um 13:48 schrieb Ben Greear: On 05/16/2019 09:21 PM, Sebastian Gottschall wrote: Am 16.05.2019 um 21:40 schrieb Ben Greear: On 5/15/19 6:00 AM, Ben Greear wrote: On 5/15/19 5:26 AM, Sebastian Gottschall wrote: Am 15.05.2019 um 14:20 schrieb Ben Greear: On 05/14/2019 09:26

Re: Problem with 9984 in routed mode with 512b frames.

Am 16.05.2019 um 21:40 schrieb Ben Greear: On 5/15/19 6:00 AM, Ben Greear wrote: On 5/15/19 5:26 AM, Sebastian Gottschall wrote: Am 15.05.2019 um 14:20 schrieb Ben Greear: On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: can you send me a detailed instruction for testing this on my

Re: Problem with 9984 in routed mode with 512b frames.

Am 15.05.2019 um 14:20 schrieb Ben Greear: On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) I am using our own traffic generator, but I

Re: Problem with 9984 in routed mode with 512b frames.

can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) Sebastian Am 15.05.2019 um 03:52 schrieb Ben Greear: Hello, I found a strange issue and curious if someone has seen similar. I made an AP where th

Re: ath10k crash on QCA9880

end of the flash, but this depends on the router model. which device are we talking about? (vendor/model) Thanks On Thu, Apr 11, 2019 at 2:01 PM Sebastian Gottschall wrote: ensure that the boarddata is correct. its stored in flash memory on alot of routers. if this data is incorrect or a wrong

Re: ath10k crash on QCA9880

ensure that the boarddata is correct. its stored in flash memory on alot of routers. if this data is incorrect or a wrong flash offset has been used for boarddata, the firmware will crash Am 11.04.2019 um 21:09 schrieb Carlito Nueno: Here is another crash log: Thu Apr 11 19:00:51 2019 kern.in

Re: [BUG] Can't change default country code from US to DE with Compex WLE900VX (Debian 10 Buster amd64)

ics: Which value for "*rd" in "ath10k_mac_get_wrdd_regulatory" would allow to set the country code with CRDA or "iw get set XX"? Am 08.04.19 um 09:52 schrieb Sebastian Gottschall: that doesnt matter. the bios locked country code isnt a new feature. i dont know in whi

Re: [BUG] Can't change default country code from US to DE with Compex WLE900VX (Debian 10 Buster amd64)

: GDM_LANG=de_DE.UTF-8 LANG=de_DE.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_NUMERIC=de_DE.UTF-8 Where else can I look? Am 07.04.19 um

Re: [BUG] Can't change default country code from US to DE with Compex WLE900VX (Debian 10 Buster amd64)

N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS    (5725 - 5875 @ 80), (N/A, 13), (N/A)    (57000 - 66000 @ 2160), (N/A, 40), (N/A) Am 07.04.19 um 10:41 schrieb Sebastian Gottschall: your docume

Re: [BUG] Can't change default country code from US to DE with Compex WLE900VX (Debian 10 Buster amd64)

your documentation is very unspecific. its unclear if you even tried to change the country code using "iw reg set" like ony any other qca/atheros card you can simply change the country code using iw reg set Am 07.04.2019 um 08:19 schrieb Rene 'Renne' Bartsch, B.Sc. Informatics: Hi, I posted

Re: [PATCH v6 3/4] ath10k: migrate to mac80211 txq scheduling

you mentioned yesterday that the called should own the right lock. doesnt that apply to ath10k as well? i dont see a lock here and you still calling txq_return Sebastian Am 22.01.2019 um 15:20 schrieb Toke Høiland-Jørgensen: From: Toke Høiland-Jørgensen ath10k maintains common txqs list for

Re: [PATCH v4 2/3] dt-bindings: net: ath10k: add new dt entry to identify external FEM

documentation still wrong. only  microsemi-lx5586 is valid .all other values are invalid see patch 4 + if (!strcmp("microsemi-lx5586", fem_name)) { + bb_timing->bb_tx_timing = 0x00; + bb_timing->bb_xpa_timing = 0x0101; + } else { + return -EN

Re: [PATCH v2 2/3] dt-bindings: net: ath10k: add new dt entry to identify external FEM

Hi you write that "microsemi-lx5586", "sky85703-11" and "sky85803" is supported, but you just check for microsemi-lx5586 in part 3 Am 03.12.2018 um 18:33 schrieb Bhagavathi Perumal S: This adds new dt entry ext-fem-name, it is used by ath10k driver to select correct timing parameters and con

Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtimeaccounting and scheduling to TXQs

its not bluetooth. active tire pressure control systems are based on 433 mhz in most countries. in the usa its 315 mhz Sebastian Am 21.11.2018 um 16:28 schrieb David P. Reed: Really? Tires are Bluetooth? I don't think mine are, but now I want to figure out how that works. 1600Chips/sec is 600

Re: [EXTERNAL] Re: [PATCH] ath10k: Disable 4addr source port learning in 10.4 FW by default

12.11.2018 um 08:33 schrieb Sebastian Gottschall: no problem. glad to help you. Sebastian Am 12.11.2018 um 06:34 schrieb Sathishkumar Muruganandam: On 2018-11-12 09:40, Sebastian Gottschall wrote: i tested my proposal now and it fixes the issue. the submitted patch was simply broken at that small

Re: [EXTERNAL] Re: [PATCH] ath10k: Disable 4addr source port learning in 10.4 FW by default

no problem. glad to help you. Sebastian Am 12.11.2018 um 06:34 schrieb Sathishkumar Muruganandam: On 2018-11-12 09:40, Sebastian Gottschall wrote: i tested my proposal now and it fixes the issue. the submitted patch was simply broken at that small point You're right. Thanks for

Re: [EXTERNAL] Re: [PATCH] ath10k: Disable 4addr source port learning in 10.4 FW by default

i tested my proposal now and it fixes the issue. the submitted patch was simply broken at that small point Am 12.11.2018 um 03:44 schrieb Sebastian Gottschall: hint for a possible fix disable_4addr_src_lrn is not set in 10_4 vdev parameter map. so this feature cannot work --- wmi.c

Re: [EXTERNAL] Re: [PATCH] ath10k: Disable 4addr source port learning in 10.4 FW by default

hint for a possible fix disable_4addr_src_lrn is not set in 10_4 vdev parameter map. so this feature cannot work --- wmi.c   (Revision 4214) +++ wmi.c   (Arbeitskopie) @@ -972,6 +972,7 @@     .meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,     .rx_decap_type = WMI_VDEV_PARAM_UNSUPPORT

Re: [PATCH] ath10k: Disable 4addr source port learning in 10.4 FW by default

after tested 2 WDS devices (one WDS AP, one WDS STA) with 9984 (netgear r7800) i found out that the issue persists. gtk rekeying fails, so disconnect and reconnect after 60 minutes. but the issue is not present with other classic atheros 802.11n WDS STA devices. so there is still a issue with 99

Re: [PATCH] ath10k: Disable 4addr source port learning in 10.4 FW by default

thank you very much. waiting for this fix since a long time. i also reported this issue years ago with no response Sebastian Am 09.11.2018 um 07:11 schrieb Sathishkumar Muruganandam: One such visible functional impact is when GTK rekey frame from _

Re: [PATCH 3/3] ath10k: Add support to configure ftm responder role

Am 15.08.2018 um 02:30 schrieb Pradeep Kumar Chitrapu: + if (test_bit(WMI_SERVICE_RTT, ar->wmi.svc_map)) + wiphy_ext_feature_set(ar->hw->wiphy, + NL80211_EXT_FEATURE_SET_FTM_RESPONDER); + not sure if this is accurate. even if WMI_SERVICE_RT

Re: [PATCH 3/3] ath10k: Add support to configure ftm responder role

Am 15.08.2018 um 02:30 schrieb Pradeep Kumar Chitrapu: Configure fine timing measurement (FTM) responder role from the ftm_responder bss param sent by mac80211. With FTM functionality offloaded to firmware, adding the interface allows userspace to enable or disable FTM responder functionality.

Re: Backporting issues, please help

Am 09.08.2018 um 12:30 schrieb Kalle Valo: "Shu, Nick" writes: I'm trying to backport ath10k driver from 4.9 kernel into 4.8 kernel currently using . In my 4.8 kernel, I built the backporting environment by using tag "v4.14-rc4-1". When I used that Python script to generate backport tree,

Re: ath10k kernel requirements (coherent_pool etc)

Am 08.08.2018 um 18:56 schrieb Arthur Watt: Good afternoon. We have been testing 3 x ath10k devices on a 4.14 based Linux kernel with a Cavium processor. Up to this point we have been seeing some unexplained crashes from the ath10k devices (firmware crashes due to corrupt HTC messages is the

Re: ath10k: antenna bitmask support?

Hello Brian Am 07.08.2018 um 07:01 schrieb Brian Norris: Thanks for your response. The thing is, masks like 0x2 and 0x4 *do* appear to work for IPQ8064, as I noted above. Let me elaborate. I tested with a conductively-wired setup, where antennas are wired directly from an AP to a client (with

Re: ath10k: antenna bitmask support?

Am 07.08.2018 um 04:08 schrieb Brian Norris: Hi all, I'm looking at ancient changes like this: commit 5572a95b4b5768187652a346356e39e7542ca6e0 Author: Ben Greear Date: Mon Nov 24 16:22:10 2014 +0200 ath10k: apply chainmask settings to vdev on creation since I see that some firmwares

Re: QCA988X firmware crash in AP mode

you may also try a more recent firmware than 10.2.4.70 10.2.4-1.0-00040 is the one i use and i dont have crash issues Am 11.07.2018 um 22:46 schrieb Adrian Chadd: Hi, My only suggestion is to try the candalatech 10.1 firmware for QCA9880/Peregrine chips and see if it behaves better. There ar

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

(0x0038) #define BW_NSS_FWCONF_MAP_M  (0x003F) so your comment doesnt seem to belong to the patch. maybe the openwrt guys renamed some values in the patch. my one is based on my original sources Am 04.07.2018 um 12:48 schrieb Sebastian Gottschall: Am 04.07.2018 um 12:40

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

Am 04.07.2018 um 12:40 schrieb Sven Eckelmann: 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 | \ +

Re: 160 mhz crash

Am 03.07.2018 um 16:58 schrieb Kalle Valo: Sebastian Gottschall writes: Am 28.06.2018 um 08:46 schrieb Sven Eckelmann: 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

Re: 160 mhz crash

Am 28.06.2018 um 14:24 schrieb Sven Eckelmann: 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

Re: 160 mhz crash

btw. openwrt imported my patches recently, but with some openwrt specific modifications Am 28.06.2018 um 08:46 schrieb Sven Eckelmann: 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

Re: 160 mhz crash

Am 28.06.2018 um 08:46 schrieb Sven Eckelmann: 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

Re: 160 mhz crash

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. Sebastian Am 15.06.2018 um 23:04 schrieb Ansuel Smith: router r7800 when i set 160mhz channel 64 i get this Fri Jun 15 23:00:20 2018 kern.err kernel:

Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

Am 28.05.2018 um 16:43 schrieb Ben Greear: On 05/27/2018 03:25 PM, Sebastian Gottschall wrote: Am 25.05.2018 um 16:52 schrieb Ben Greear: On 05/25/2018 07:44 AM, Kalle Valo wrote: Sebastian Gottschall writes: Am 26.04.2018 um 15:44 schrieb Ben Greear: On 04/26/2018 02:43 AM

Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

Am 25.05.2018 um 16:52 schrieb Ben Greear: On 05/25/2018 07:44 AM, Kalle Valo wrote: Sebastian Gottschall writes: Am 26.04.2018 um 15:44 schrieb Ben Greear: On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall starting with firmware 10.4.3.4.x series QCA

Re: [PATCH] ath10k: add dynamic vlan support

Am 23.05.2018 um 12:39 schrieb Johannes Berg: On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote: + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting + * frames encrypted in software, only valid when SW_CRYPTO_CONTROL + * is enabled. Based on this flag,

Re: [PATCH] ath10k: add dynamic vlan support

Am 18.05.2018 um 11:54 schrieb Johannes Berg: On Fri, 2018-05-04 at 12:20 +0530, Manikanta Pubbisetty wrote: Johannes, It seems like commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices") has broken 4-addr operation on crypto controlled devices as reported by se

Re: [PATCH] ath10k: add dynamic vlan support

Am 18.05.2018 um 11:53 schrieb Johannes Berg: On Mon, 2018-04-23 at 21:18 +0200, Sebastian Gottschall wrote: this patch makes no sense at some points. AP_VLAN must be enabled always (it is enabled by mac80211 by default, but is now disabled in very latest git version for drivers which

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

Am 09.05.2018 um 08:15 schrieb Sven Eckelmann: 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 i

Re: [PATCH] ath10k: add dynamic vlan support

Please let me know which is the better way to deal the problem. Thanks, Manikanta On 2018-04-24 14:39, Sebastian Gottschall wrote: consider my comment regarding vlan_ap. this patch will break wds ap / wds sta support with latest mac80211 (see also my post on the wireless mailing list about the bre

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

e firmware seem to be sensitive on the regdomain set by the host so if host sets anything else than a FCC regdomain, it will still work in the old way. so its more a pseudo enforcement. dont know if this is usefull and it also will it make impossible to fix radar detection issues for certificat

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

MAP_80_80MHZ_S) & BW_NSS_FWCONF_MAP_80_80MHZ_M))   struct wmi_10_4_peer_assoc_complete_cmd {   struct wmi_10_2_peer_assoc_complete_cmd cmd; -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Regis

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

btw 4019 doesnt support vht160 in ath10k see vht160_mcs_rx_highest in core params if it does support vht160, ath10k must be adjusted here Am 28.04.2018 um 17:37 schrieb Ben Greear: On 04/28/2018 08:26 AM, Sebastian Gottschall wrote: Am 28.04.2018 um 17:01 schrieb Ben Greear: On 04/27

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

Am 28.04.2018 um 17:01 schrieb Ben Greear: On 04/27/2018 05:47 PM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized

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

md->peer_bw_rxnss_override = -    __cpu_to_le32((arg->peer_bw_rxnss_override - 1) | -  BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET)); -    else -    cmd->peer_bw_rxnss_override = 0; + +    cmd->peer_bw_rxnss_override = __cpu_to_le32(arg->peer_bw_rxnss_override

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

Am 27.04.2018 um 23:57 schrieb Ben Greear: On 04/27/2018 11:54 AM, Sebastian Gottschall wrote: Am 27.04.2018 um 18:07 schrieb Ben Greear: On 04/26/2018 09:40 PM, Sebastian Gottschall wrote: Am 26.04.2018 um 22:35 schrieb Ben Greear: On 04/26/2018 01:21 PM, Sebastian Gottschall wrote: Am

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

Am 27.04.2018 um 18:07 schrieb Ben Greear: On 04/26/2018 09:40 PM, Sebastian Gottschall wrote: Am 26.04.2018 um 22:35 schrieb Ben Greear: On 04/26/2018 01:21 PM, Sebastian Gottschall wrote: Am 26.04.2018 um 17:30 schrieb Ben Greear: On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote

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

Am 26.04.2018 um 22:35 schrieb Ben Greear: On 04/26/2018 01:21 PM, Sebastian Gottschall wrote: Am 26.04.2018 um 17:30 schrieb Ben Greear: On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on

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

Am 26.04.2018 um 17:30 schrieb Ben Greear: On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized

Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

Am 26.04.2018 um 15:44 schrieb Ben Greear: On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall starting with firmware 10.4.3.4.x series QCA changed the handling of the channel property band_center_freq1 and band_center_freq2 in vht160 operation mode likelly

Re: 9984 with 10.4.3.5.3-0057 crashes

Am 25.04.2018 um 17:23 schrieb Kalle Valo: Sebastian Gottschall writes: Am 24.04.2018 um 07:27 schrieb Kalle Valo: Sebastian Gottschall writes: just for your notice. 10.4.3.5.3-0057 on 9984 which was just released crashes in vht160 operation mode immediatly after first station associates

Re: 9984 with 10.4.3.5.3-0057 crashes

Am 25.04.2018 um 17:23 schrieb Kalle Valo: Sebastian Gottschall writes: Am 24.04.2018 um 07:27 schrieb Kalle Valo: Sebastian Gottschall writes: just for your notice. 10.4.3.5.3-0057 on 9984 which was just released crashes in vht160 operation mode immediatly after first station associates

Re: [PATCH] ath10k: add dynamic vlan support

Am 24.04.2018 um 11:52 schrieb Kalle Valo: Sebastian Gottschall writes: consider my comment regarding vlan_ap. I am considering comment, I just go one issue at a time and haven't had a time to look at your comment. But PLEASE do not top post, it's very annoying and creates

Re: [PATCH] ath10k: add dynamic vlan support

to change your name during registration, but only one time. If that doesn't work then send a request to helpd...@kernel.org and the admins can fix it. [1] https://patchwork.kernel.org/register/ -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firme

Re: 9984 with 10.4.3.5.3-0057 crashes

Am 24.04.2018 um 07:27 schrieb Kalle Valo: Sebastian Gottschall writes: just for your notice. 10.4.3.5.3-0057 on 9984 which was just released crashes in vht160 operation mode immediatly after first station associates last known working stable fw so far is 10.4-3.4-00104. the whole 10.4.3.5.3

Re: [PATCH] ath10k: add dynamic vlan support

WMI_SERVICE_CFR_CAPTURE_IND_MSG_TYPE_1, len); + SVCMAP(WMI_10_4_SERVICE_PER_PACKET_SW_ENCRYPT, + WMI_SERVICE_PER_PACKET_SW_ENCRYPT, len); } #undef SVCMAP -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stub

9984 with 10.4.3.5.3-0057 crashes

just for your notice. 10.4.3.5.3-0057 on 9984 which was just released crashes in vht160 operation mode immediatly after first station associates last known working stable fw so far is 10.4-3.4-00104. the whole 10.4.3.5.3 series seem to be seriously broken or the api has been changed in a way wh

Re: [PATCH v2 4/4] ath10k: Enable sta idle power save

power? wcn3990 is a chip for a mobile device anyway. it might be made for mobile devices but who knows how it is used by the market. Sebastian -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Reg

Re: [PATCH v2 4/4] ath10k: Enable sta idle power save

goto err_core_stop; + } + __ath10k_set_antenna(ar, ar->cfg_tx_chainmask, ar->cfg_rx_chainmask); /* -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Gesc

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

Am 09.04.2018 um 17:49 schrieb Kalle Valo: Sebastian Gottschall writes: you removed the call to leds_start from certain locations but you seem to have ignored the comment i wrote above the function call. IIRC I moved the comment to ath10k_leds_start(). there is a reason why i reinitialize

  1   2   3   >