Surely this should be a firmware fix/patch?
-adrian
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On Mon, 18 Jul 2022 at 15:28, Linus Lüssing wrote:
>
> From: Linus Lüssing
>
> AR9003 based wifi chips have a hardware bug, they always report a
> channel bandwidth of HT40 for any sub-frame of an aggregate which is
> not the last one. Only the last sub-frame has correct channel bandwidth
> infor
On Wed, 27 May 2020 at 11:30, Ben Greear wrote:
>
> While doing a torture test on OpenWrt using ath10k-ct drivers/firmware, the
> 5Ghz AP fell off the
> air. After debugging, I found this in the console logs.
>
> I am guessing that the only way to recover in this case would be to reboot,
> but
On Tue, 17 Dec 2019 at 10:29, Tom Psyborg wrote:
>
> On 17/12/2019, Ben Greear wrote:
> > On 12/17/19 8:23 AM, Justin Capella wrote:
> >> I believe someone recently submitted a patch that defined noise floors
> >> per band (2/5).
> >
> > I looked at using the real noise floor. Our radio was repo
It'd be good to at least post the client devices, with the
kernel/firmware versions if you know them. That way people can check
for regressions.
-a
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Are these er, apple devices?
-adrian
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On Tue, 22 Oct 2019 at 10:17, Peter Oh wrote:
>
>
> On 10/22/19 1:57 AM, Zhi Chen wrote:
> > This reverts commit 76d164f582150fd0259ec0fcbc485470bcd8033e.
> > PCIe hung issue was observed on multiple platforms. The issue was reproduced
> > when DUT was configured as AP and associated with 50+ STAs
On Mon, 20 May 2019 at 09:59, Sebastian Gottschall
wrote:
> the curious thing is still that the fallback code applies only for 2.4
> ghz so it would never have affected 802.11ac
Hm, does RC fall back to 11na or 11a rates when doing 11ac? (in 5G
mode.) It's good to know fixing that would fix it
On Fri, 17 May 2019 at 09:00, Ben Greear wrote:
>
> 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
> >&
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 that beacons are still transmitted in this way
On Thu, 16 May 2019 at 13:20, Ben Greear wrote:
>
> On 5/16/19 1:16 PM, Adrian Chadd wrote:
> > You can't do AMPDU with OFDM/CCK. If they're setting the AMPDU bit
> > then that's wrong. it needs to be individual MPDU/PPDUs.
> >
> > There's a benef
0, Ben Greear wrote:
>
> On 5/16/19 12:55 PM, Adrian Chadd wrote:
> > You can totally go down to OFDM yeah but you then need to send it at
> > 20MHz and non-AMPDU.
> >
> > Is it maybe the retry code + rate control code is retagging an AMPDU
> > at a lower rate and it&#
You can totally go down to OFDM yeah but you then need to send it at
20MHz and non-AMPDU.
Is it maybe the retry code + rate control code is retagging an AMPDU
at a lower rate and it's transitioning down to CCK/OFDM without
breaking the AMPDU apart?
-a
On Thu, 16 May 2019 at 12:40, Ben Greear w
On Fri, 10 May 2019 at 05:28, Linus Torvalds
wrote:
>
> Hmm.
>
> I have a nice new laptop, and it works fine. Except today it lost
> wireless, and I have no idea why.
>
> It's not happened before (but it's fairly new and I'm actually on my
> first trip with it), so I don't know how common this is,
Hi,
My only suggestion is to try the candalatech 10.1 firmware for
QCA9880/Peregrine chips and see if it behaves better. There are a
bunch of unresolved issues in the 10.2 firmware which I think Ben has
fixed in his 10.1 firmware.
If it works in Ben's firmware release then you maybe can work with
On Thu, 17 May 2018 at 16:16, Niklas Cassel
wrote:
> diff --git a/drivers/net/wireless/ath/ath10k/txrx.c
b/drivers/net/wireless/ath/ath10k/txrx.c
> index cda164f6e9f6..1d3b2d2c3fee 100644
> --- a/drivers/net/wireless/ath/ath10k/txrx.c
> +++ b/drivers/net/wireless/ath/ath10k/txrx.c
> @@ -95,6 +95,
On Mon, 14 May 2018 at 11:25, Kalle Valo wrote:
> Adrian Chadd writes:
> > May we have a little more information about how this is supposed to
work?
> >
> > It looks like we're supposed to send the information about the matched
> > radar pattern back to the f
Hi,
May we have a little more information about how this is supposed to work?
It looks like we're supposed to send the information about the matched
radar pattern back to the firmware for confirmation? What's the intended
behaviour from the firmware? Will the firmware have a hard-coded set of
pat
y!
-a
On 23 April 2018 at 13:31, Arvid Picciani wrote:
> from where does ath10k know where to look for it? all i know about is
> ath79_register_wmac in arch init. That points to a partition called
> "wifi" which makes ath9k work, but not ath10k.
>
> On Mon, Apr 23, 201
d be on the chip itself?
>
> This is a tplink archer c7 v5.0.
>
>
> this is a tplink-
>
> On Mon, Apr 23, 2018 at 9:12 PM, Adrian Chadd wrote:
>> hi!
>>
>> It should be in OTP on the QCA9880 chip. Which board is this?
>>
>>
>>
>> -ad
o 9k and 10k usually share the same partition for that info or should i go
> hunting for something completely else?
> Any more reading material that might help me find out how to load that
> correctly?
>
> /b/
>
> On Mon, Apr 23, 2018 at 9:07 PM, Adrian Chadd wrote:
>>
>
Hi,
That's designed for debugging. It means you'll have an invalid MAC
address and no calibration information so your NIC won't work very
well.
The reason why needs to be figured out!
-adrian
On 23 April 2018 at 09:56, Arvid Picciani wrote:
> Hi,
>
> Is it ok to run a QCA9880 with skip_otp=
On 23 April 2018 at 08:50, Kalle Valo wrote:
>
> Adrian was also commenting something similar about adding a debugfs
> interface but I don't really see the point right now while we are adding
> initial wcn3990 support. If someone wants to run measurements with and
> without this parameter it's ve
Hi,
My 2c here.
As much as I like power save stuff, I've been bitten enough times by
these wifi chips kinda implementing
mostly-ok-but-not-that-particular-time power savings stuff and so have
had to make it configurable chip by chip.
A good example is active state power management in various run
Support for IO bounce buffering for systems without an IOMMU.
> This allows us to DMA to the full physical address space on
> platforms where the size of a physical address is larger
> than the bus address. Not all platforms support this.
>
>
>
Sorry, a quick follow-up:
I bring it up because I know there's some oddness with the PPC IOMMU
and where they put their devices in the physical address map, so you
have to do a lot of gymnastics to be able to even access devices.
Anything above 32 bit boundary requires that they do a temporary IOM
Hi,
I don't recall there being any issues with physical memory addresses
that high. I'd ask the vendor to help you with the DMA mapping side of
things and see what the deal is.
Is fbff7000 an actual valid return or is it some error return? the
ath10k firmware/copy-engine cares about that bit and
HI,
What were the mac addresses? Why were they so dissimilar?
-adrian
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
hi,
so it's going to eventually leak? Can we fix the firmware bug too? :)
-a
On 26 February 2018 at 09:06, wrote:
> Hi,
>
>
>> Can you share exactly which resource the firmware ran out of? It would
>> seem to
>> be a FW bug if it is leaking, so maybe it can be fixed as well...
>>
>
> Firmwa
hi!
On 25 February 2018 at 22:16, Karthikeyan Periyasamy
wrote:
> This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159.
>
> When Ath10k is in AP mode and an unassociated STA sends a VHT action frame
> (Operating Mode Notification for the NSS change) periodically to AP this
> causes
> ath
Hi,
Yeah, it's possible it's being dropped in the HTT notification path -
the hardware afaik is doing the ACKing there.
I think pktlog is the primary way I'd try to debug this but yeah,
there's no open pktlog tool iirc for even just looking at the packet
data..
-adrian
___
hi,
do you have firmware source at the current gig? or access to the pktlog tools?
Have you verified that the frames weren't at all indicated up via HTT?
Like are they absolutely NOT coming up via HTT, or are they coming up
via HTT but being thrown out before the driver is ready to pass them
up.
[top post for emphasis]
Arend is right. You won't be the only driver which has issues with a
controller that doesn't handle non-aligned data payloads. Please push
it into the stack or the controller side, but not in the driver side.
That'll be a forever game of whack-a-mole.
-adrian
(I'm living
Hi,
I think Kalle is pointing out that maybe it's the SDHCI driver
responsibility to do the bounce buffering?
-adrian
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
hi,
fyi - i tried the latest board-2.bin and firmware-6.bin from kvalo's
ath10k repository - still getting HTT timeouts. This is on the QSDK
4.0.8 backports.
-adrian
On 14 December 2017 at 13:55, Adrian Chadd wrote:
> Hi,
>
> * QSDK 4.0.8 doesn't run with QCA6174 - H
Hi,
* QSDK 4.0.8 doesn't run with QCA6174 - HTT timeout as above
* QSDK ILQ 1.1.8 runs with QCA6174
* The HTT debugging shows that after the HTC/HTT stuff is setup, none
of the HTT "i'm awake" messages are coming back.
I'll try the latest firmware and board data from Kalle's repository
and see if
Hi,
I've had this issue with a 4.11 update from QSDK (4.0.8.) ILQ-1.1.8
worked fine with ye olde backports.
Is it really just a board-2.bin issue? I tried it and it didn't fix it.
-adrian
___
ath10k mailing list
ath10k@lists.infradead.org
http://lis
Hi,
Do you also need to populate the channel list in the ath10k regulatory
side of things with these flags?
(Sorry I haven't looked at the firmware to check)
-a
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/li
hiya,
I'd honestly rather see firmware changes for wave 2 chips, as I know
there's a lot more MAC changes messing up this stuff ..
-adrian
On 16 October 2017 at 12:10, Sebastian Gottschall
wrote:
> Am 16.10.2017 um 19:59 schrieb Adrian Chadd:
>>
>> On 16 October
On 16 October 2017 at 10:57, Ben Greear wrote:
> On 08/25/2016 06:25 AM, Benjamin Berg wrote:
>>
>> Unfortunately ath10k does not generally allow modifying the coverage class
>> with the stock firmware and Qualcomm has so far refused to implement this
>> feature so that it can be properly supporte
[snip]
* WMI setup stuff fails locally because of memory fragmentation when
you reload the driver. Heh. Sigh.
* I also see the PCI wakeup failures, so I'm going to go poke that
soon and see what I find.
-adrian
___
ath10k mailing list
ath10k@lists.in
On 13 October 2017 at 05:41, Kalle Valo wrote:
> gree...@candelatech.com writes:
>
>> From: Ben Greear
>>
>> This works around a problem we see when sometimes the wifi NIC does
>> not respond the first time. This seems to happen especially often on
>> some of the 9984 NICs in mid-range platforms
fwiw - I did this on my in progress ath10k port to freebsd, and I've
tested it on Rome and Peregrine. It seems to be the right thing to do
during suspend to at least cleanly shut things down.
-adrian
On 11 October 2017 at 17:38, Brian Norris wrote:
> Ping? Any comments? I know there's more tha
Hi,
IIRC, I think it's the drivers job to determine per-peer fixed rate.
-adrian
On 10 October 2017 at 11:34, Ben Greear wrote:
> I was trying to use 'iw' to set rates on an AP interface, hoping it would
> set tx-rates on all of the stations (peers) to the same thing.
>
> It appears that the
heh,
On 18 September 2017 at 08:08, Kalle Valo wrote:
> Hauke Mehrtens writes:
>
>> I am using a BT Home Hub 5A with LEDE and backports-4.14-rc1 + some
>> patches from the LEDE repository. It has one QCA988X card in it which
>> works like expected with FW firmware-5.bin_10.2.4-1.0-00029, but cr
On 15 September 2017 at 13:19, Ben Greear wrote:
> It is not that reliable. I'm now trying a hack to re-probe the bus up
> to 3 times if we failhoping maybe that will help.
>
> We just hit a case where the first 2 times failed, but it booted on
> the third.
See if there's a call to reset an
On 15 September 2017 at 09:59, Ben Greear wrote:
> On 09/14/2017 07:33 PM, Adrian Chadd wrote:
>>
>> On 14 September 2017 at 17:13, Ben Greear wrote:
>>
>>>>
>>>> There were always weird cold reset races that necessitated a PCI bus
>>>> re
On 14 September 2017 at 17:13, Ben Greear wrote:
>>
>> There were always weird cold reset races that necessitated a PCI bus reset
>> of the device. :( can you even see the device? do any of the registers work?
>
>
> Can the cold reset be done on generic x86-64 hardware?
I'll have to go check. Y
Hi,
So I asked around. I haven't gotten an official answer from QCA yet.
The peregrine caldata format uhm, "changed slightly" between versions
of 10.2, and they didn't make it backwards compatible. I need to ask
them about it again.
The later firmware works with the later caldata. The earlier fi
Hi,
I'd rather see the ones that are known-to-be-ok-to-ignore be ignored.
I've been bitten by unhandled firmware IDs that I had to backfill
whilst doing driver bring-up / QSDK patch porting. :-)
(And honestly, if I were to submit a patch, it would be to log the
actual event ID and flags in a way
domain: 0x8210
> [ 20.521642] ath: EEPROM indicates we should expect a country code
> [ 20.527830] ath: doing EEPROM country->regdmn map search
> [ 20.533216] ath: country maps to regdmn code: 0x37
> [ 20.538083] ath: Country alpha2 being used: NL
> [ 20.542587] ath:
ere identical between his crash at startup and my crash at startup on
> different hardware platforms and thought this might prove useful to
> somebody with more knowledge.
>
> If there is some useful test that I could perform to help the
> community further then please just ask.
>
>
On 7 August 2017 at 14:26, svp wrote:
>>
>> On 05.08.2017 03:07, Adrian Chadd wrote:
>>>
>>> Hi,
>>>
>>> Is this being used as a STA? AP? What's it associating to? what
>>> channel, mode, etc
>>>
>>>
>>>
>>&g
Hi,
Is this being used as a STA? AP? What's it associating to? what
channel, mode, etc
-adrian
On 4 August 2017 at 10:18, svp wrote:
> Hi!
>
> Have a firware crash at system start.
>
> uname -a
> Linux I5-4670 4.12.4-1-ARCH #1 SMP PREEMPT Fri Jul 28 18:54:18 UTC 2017
> x86_64 GNU/Linux
>
> j
say the card it should make 2g or 5g?
> So where do I get those "special" files? Or can I build them myself?
> I can not find any helpful information on "Google".
>
> Thanks
> BG
> Frank
>
> -Ursprüngliche Nachricht-
> Von: adrian.ch...@gmail.c
ke LNA or what ever missing, we can do this our self.
> Thanks.
> BG
> Frank
>
> -Ursprüngliche Nachricht-
> Von: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Im Auftrag von
> Adrian Chadd
> Gesendet: Mittwoch, 31. Mai 2017 21:48
> An: Lindner, Frank
>
Hi,
Well, it sounds like something you need a 40 node test network for :)
I was wondering whether it was some kind of MAC bug that was being
triggered because of so many units say, overflowing the keycache or
something. But if it's software encryption then maybe not. I wish I
could help more, but
Hi!
Does it happen if you run 40 IBSS nodes without encryption?
(I wonder if it's a MAC or PHY bug..)
-adrian
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On 1 June 2017 at 06:24, Kalle Valo wrote:
> Arend van Spriel writes:
>
>> On 31-05-17 14:16, Kalle Valo wrote:
>>> Adrian Chadd writes:
>>>
>>>> This adds a few configurable debugging options:
>>>>
>>>> * driver debugging and
oh
is the NIC /disappearing/ or firmware crashing?
There are ... and I know someone's going to slap me, but firmware/rate
control bugs in STA mode on these chips in 11bg (not n, not ac) modes.
I can't (yet) get eyeballs at QCA on it to fix them :(
-adrian
_
On 31 May 2017 at 14:28, Arend van Spriel wrote:
> On 31-05-17 22:23, Adrian Chadd wrote:
>> On 31 May 2017 at 13:20, Arend van Spriel
>> wrote:
>>> On 31-05-17 14:16, Kalle Valo wrote:
>>>> Adrian Chadd writes:
>>>>
>>>>> This
On 31 May 2017 at 13:20, Arend van Spriel wrote:
> On 31-05-17 14:16, Kalle Valo wrote:
>> Adrian Chadd writes:
>>
>>> This adds a few configurable debugging options:
>>>
>>> * driver debugging and tracing is now configurable per device
>>> *
On 30 May 2017 at 22:23, Lindner, Frank wrote:
> Hi.
> 9994 is Cascade, which should be 2.4 GHz capable as fas as Qualcomm is
> correct on their specs site.
> Question was not, which other card can do 2.4 GHz. I want to enable 2.4 GHz /
> dualband mode via some registers or what ever on this car
hi,
wait - is that besra? if it's besra then nope - 5G only. If it's
beeliner or cascade then I think you can do 2G, but no dynamic 2G/5G?
-a
On 30 May 2017 at 09:28, Ben Greear wrote:
> I think zcomax makes a 2.4Ghz NIC with 9984 chipset, but that NIC cannot do
> 5Ghz as far as I know.
>
> T
hi,
I mean, if you can load a calibrration data file that has 2G cal data
and 2G enabled, then maybe. But IIRC only at firmware load time, and
it's not exactly the supported config.
-adrian
On 29 May 2017 at 08:15, Lindner, Frank wrote:
> This card is only 5GHz capable. Is this somehow possib
On 27 May 2017 at 09:07, Ben Greear wrote:
> At low encoding rates, especially if it switches to a single-chain encoding,
> maybe the on-air signal really is stronger?
>
> Have you verified in some other manner than the signals reported by ath10k
> are
> wrong?
Hiya,
So yeah, multipath, higher T
[snip]
hiya,
I have something local that I've been meaning to push up to do this,
but with no smoothing. Ideally (!) smoothing is done optionally in
mac80211.
What do you think about just committing the per-chain RSSI stuff to
mac80211 so it shows up right now, and then we figure out how to
expr
On 19 May 2017 at 02:17, Kalle Valo wrote:
> Felix Fietkau writes:
>
>> On 2017-04-26 16:41, Venkateswara Rao Naralasetty wrote:
>>> Channel active/busy time are showing incorrect
>>> (less than previous or sometimes zero) for
>>> successive survey dump command.
[snip]
>> Does the firmware read
[snip]
hi!
Which driver are you using as a reference for the SDIO/USB side of things?
We have an interest in USB/SDIO support for Rome/Tuffalo in ath10k and
I'd like to see how I/we could help in kicking this along!
-adrian
___
ath10k mailing list
hi,
which reference design? which kernel? What does the driver say?
-a
On 9 May 2017 at 16:26, Guo Feng <18511331...@126.com> wrote:
> To whomever may can help,
>
>
> Recently, I got one reference design board with a qca9994 802.11ac Wave2
> pcie module.
>
>
> And now I have bring up the boa
.
Signed-off-by: Adrian Chadd
---
drivers/net/wireless/ath/ath10k/core.c | 2 +
drivers/net/wireless/ath/ath10k/core.h | 2 +
drivers/net/wireless/ath/ath10k/debug.c | 101
drivers/net/wireless/ath/ath10k/debug.h | 44 +-
4 files changed, 125
grr, no. lemme go re-add that and resubmit.
thanks!
-a
On 10 May 2017 at 09:44, Steve deRosier wrote:
> Hi Adrian,
>
> On Wed, May 10, 2017 at 9:25 AM, Adrian Chadd wrote:
>
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.h
>> b/drivers/net/wireless/ath
.
Signed-off-by: Adrian Chadd
---
drivers/net/wireless/ath/ath10k/core.c | 2 +
drivers/net/wireless/ath/ath10k/core.h | 2 +
drivers/net/wireless/ath/ath10k/debug.c | 101
drivers/net/wireless/ath/ath10k/debug.h | 44 +-
4 files changed, 125
On 9 May 2017 at 05:57, Simon Wunderlich wrote:
> Hey Kalle,
>
> it seems like there was some discussion here and I wouldn't expect too many
> more opinions ... do you think we can have a decision based on what has been
> discussed here?
(Note: FreeBSD has had in-tree support for 4.9GHz and 900MH
reallocates them every time the vdevs are brought down) fragmentation
should stop being such a touchy issue. If it is though, using
dma_alloc_coherent() use gets us access to the CMB APIs too relatively
easily and ideally we would be allocating memory early in boot for
exactly these reasons.
Sign
can we get a definition of the feature so we can just implement it? It
looks like something simpleish?
-a
On 21 April 2017 at 12:00, Ryan Hsu wrote:
> On 04/19/2017 11:34 PM, Kalle Valo wrote:
>
>> "Mohammed Shafi Shajakhan (Mohammed Shafi)"
>> writes:
>>
>>> my quick analysis suggests this b
does the newer firmware expect something ath10k isn't supplying? I
found (when porting ath10k to freebsd) that rome is pickier when it
comes to commands being sent and requires commands that 10.2 on
peregrine was less picky about.
-adrian
On 19 April 2017 at 20:50, Mohammed Shafi Shajakhan (Mo
Hiya,
I think there's a known issue with the compex NIC not being "will work
on all mini-pcie slots" for some reason. I don't know why :(
-adrian
On 14 April 2017 at 06:22, Marek Behun wrote:
> Hello,
> I have a question about the MiniPCI-e wifi module COMPEX WLE900VX-7A.
> This module can b
hi!
For reference, would you mind pulling out what hte format of the edge
detection dword is?
Thanks!
-adrian
On 10 April 2017 at 07:26, Mohammed Shafi Shajakhan
wrote:
> From: Mohammed Shafi Shajakhan
>
> spectral_bin length (number of bins per fft sample) is usually
> a value where (2^n =
hi,
I don't think HT greenfield is supported, no :(
-adrian
On 4 April 2017 at 04:15, KAVITA MATHUR wrote:
>
> Hi,
>
> When I give ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][GF] in hosapd.conf, AP
> is
> disabled with following error:
>
> wlan0: interface state UINITIALIZED->country_update
>
hiya,
hm, what's the reference driver do for pci powersave versus aspm? Does
it change any pci config space register settings for allowable sleep
states?
-adrian
On 31 March 2017 at 04:12, Kalle Valo wrote:
> Guilherme Íscaro writes:
>
>> I would like to inform that I "fixed" the problem. A
Hi,
Isn't this because by default the world regulatory domain the stack is
in marks all 5GHz channels as NO-IR, and wants to hear beacons before
it determines it can use 5G channels?
We've had to port the openwrt/qsdk changes that allow for the
regdomain to be set rather than it defaulting to wor
hiya,
sure, but the NIC also has calibration tables for the maximum power
it's been calibrated at for each channel. This includes per-channel
targets and band-edge targets.
Unfortunately :( ath10k doesn't easily expose the NIC regulatory / CTL
entries in a useful fashion. That would sure be nice.
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/board data files over so the reference driver can assemble
a board data
have you verified with a sniffer that it indeed is an A-MSDU that the
hardware is decap'ing for you?
(ath9k doesn't do hardware A-MSDU decap.)
-adrian
On 15 March 2017 at 08:26, Ben Greear wrote:
> We notice a strange problem when receiving ath10k frames in
> raw mode (with modified firmware).
Hi,
Whilst you're at it, the DK07 2G/5G-low and DK07 5G-high/5G-high board
values would be good to add too. They're the same bmi-id though;
there's a jumper to select radio0 as "2G or 5G-high RF path". You'd
have to add them as separate files that people can select at runtime.
:)
I think there's
Hi,
I mean - it's binary data required to make something work, I don't
know if copyright applies?
Guess we should ask QCA again a bit more. :)
Yes, we likely need a separate repository of board data files indexed
by actual board.
-adrian
___
ath10k
"use your own bmi ids". :-)
(yeah, this is going to make open source firmware for these things
more painful than it should be. :( )
-adrian
On 7 March 2017 at 01:54, Sven Eckelmann wrote:
> Hi Adrian,
>
> On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote:
>&g
hiya,
I don't think it's something that you can do with any accuracy out of
the box? You'd need some design help from QCA to figure out which NICs
would let you set such low TX power levels accurately.
-adrian
On 6 March 2017 at 04:13, Xue Liu wrote:
> Hello everyone,
>
> I am working on a pr
hi!
the ath9k list has been deprecated. use linux-wireless list instead. :)
AR_CHAN_BASE looks like it's the start of the PHY/baseband block.
Not sure about MRC - I think it's "maximum rate(?) combining" but I
don't know exactly. I'd have to go hunt it down.
BB_WATCHDOG has to do with the baseb
On 2 March 2017 at 23:47, Sebastian Gottschall wrote:
> Am 03.03.2017 um 01:22 schrieb Adrian Chadd:
>>
>> On 2 March 2017 at 16:08, Sebastian Gottschall
>> wrote:
>>>
>>> Am 03.03.2017 um 00:30 schrieb Adrian Chadd:
>>>>
>>>
On 2 March 2017 at 16:08, Sebastian Gottschall wrote:
> Am 03.03.2017 um 00:30 schrieb Adrian Chadd:
>>
>> On 2 March 2017 at 14:53, Sebastian Gottschall
>> wrote:
>>
>>>> Did you patch supplicant? If so, can you point me to the change(s) you
>>&g
On 2 March 2017 at 14:53, Sebastian Gottschall wrote:
>> Did you patch supplicant? If so, can you point me to the change(s) you
>> made?
>
> nope. i just used its features. there is a config entry named "vht_capa" and
> "vht_capa_mask" which allows to mask out / in vht capabilities
RIght, but y
hiya,
we're working on something similar to this, but based on bmi-id.
Why'd you withdraw this patch for now?
-a
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
... looks like some changes for 802.11-2016 because yeah, some clients
don't handle 80+80/160MHz right...
-a
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
hiya,
I'll go double check. I think it's the same as ath9k hardware..
-a
On 2 February 2017 at 11:21, Michael Everett Feder
wrote:
> I understand that both the ath9k and the ath10k drivers support a spectral
> scan feature with an FFT output. But the ath9k's output only lists the
> magnitudes
aiee, some clients messed up freq1/freq2 handling in this way?
-adrian
On 14 February 2017 at 07:21, Sebastian Gottschall
wrote:
> Am 14.02.2017 um 11:30 schrieb Valo, Kalle:
>>
>> (you forgot to CC ath10k list, adding it back)
>>
>> Sebastian Gottschall writes:
>>
>>> Am 10.02.2017 um 07:50
.. or give us a legit way to acquire the 2016 spec? :)
Curious implementers want to know!
-a
On 13 February 2017 at 11:21, Ben Greear wrote:
> On 02/12/2017 11:06 PM, Johannes Berg wrote:
>>
>> On Fri, 2017-02-10 at 14:58 -0800, Ben Greear wrote:
>>>
>>> So, it appears that the ath10k QCA9984
On 10 February 2017 at 20:22, Sebastian Gottschall
wrote:
> i really can't believe this. if this is true the 160 mhz mode would not
> make any sense.
> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so
> vht160 would not increase performance in any way
Well, if it can also d
On 9 February 2017 at 23:37, Joe Perches wrote:
> On Thu, 2017-02-09 at 23:14 -0800, Adrian Chadd wrote:
>
>> If there
>> were accessors for the skb data / len fields (like we do for mbufs)
>> then porting the code would've involved about 5,000 less changed
>>
1 - 100 of 177 matches
Mail list logo
