From: Kalle Valo <kvalo@codeaurora.org>
To: Adrian Chadd <adrian@freebsd.org>
Cc: linux-wireless@vger.kernel.org, srirrama@codeaurora.org,
ath10k@lists.infradead.org
Subject: Re: [PATCH 2/2] ath10k: DFS Host Confirmation
Date: Mon, 14 May 2018 21:25:46 +0300 [thread overview]
Message-ID: <87h8naqel1.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAJ-VmonSEuh7Ou=K9Gu-gZ5ikpX9H=nzXe9NssNu1vw8fEk3hg@mail.gmail.com> (Adrian Chadd's message of "Thu, 03 May 2018 23:48:53 +0000")
Adrian Chadd <adrian@freebsd.org> 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 firmware for confirmation? What's the intended
> behaviour from the firmware? Will the firmware have a hard-coded set of
> patterns we have to answer in/by?
That's really an implementation detail inside the firmware and from
ath10k point of view we don't care what checks the firmware has, we just
provide all the necessary information. The checks in firmware might even
change in later releases.
> I ask (like Peter, we work together) because we've had to tweak this
> behaviour a little to actually pass FCC / ETSI DFS certification. My
> general concern is that this'll cause a lot of false detects on boards that
> haven't had things tweaked for the given board. As far as I'm aware the DFS
> parameters are still hard-coded into the firmware image so if you have to
> change those you're SOL without the relevant NDAs - this makes running the
> open source DFS stuff a little tricksy on vendor boards.
This shouldn't cause more false detections, the pattern detection from
ath.ko is still used as before. The firmware will just disable DFS
altogether if it thinks ath10k is not compliant.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-05-14 18:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 17:45 [PATCH 0/2] ath/ath10k: DFS Host Confirmation Sriram R
2018-04-30 17:45 ` [PATCH 1/2] ath: Add support to get the detected radar specifications Sriram R
2018-04-30 19:01 ` Peter Oh
2018-05-14 14:51 ` Kalle Valo
2018-04-30 17:45 ` [PATCH 2/2] ath10k: DFS Host Confirmation Sriram R
2018-04-30 19:50 ` Peter Oh
2018-05-02 11:27 ` Kalle Valo
2018-05-03 6:25 ` Peter Oh
2018-05-14 18:10 ` Kalle Valo
2018-05-14 20:55 ` Peter Oh
2018-05-05 9:45 ` Sebastian Gottschall
2018-05-09 10:45 ` Sriram R
2018-05-03 23:48 ` Adrian Chadd
2018-05-14 18:25 ` Kalle Valo [this message]
2018-05-14 21:13 ` Adrian Chadd
2018-05-15 5:04 ` Kalle Valo
2018-05-15 18:59 ` Peter Oh
2018-05-16 10:09 ` Kalle Valo
2018-05-12 9:57 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8naqel1.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=adrian@freebsd.org \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=srirrama@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox