From: Jeffrey Johnson <jjohnson@qca.qualcomm.com>
To: Dan Williams <dcbw@redhat.com>
Cc: "Chauhan, Rajesh" <rajeshc@qca.qualcomm.com>,
"Rodriguez, Luis" <rodrigue@qca.qualcomm.com>,
Johannes Berg <johannes@sipsolutions.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"Malinen, Jouni" <jouni@qca.qualcomm.com>,
"Bahini, Henri" <hbahini@qca.qualcomm.com>,
"Chang, Leo" <schang@qca.qualcomm.com>,
"Luo, Xun" <xunl@qca.qualcomm.com>
Subject: Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
Date: Mon, 28 Oct 2013 14:11:50 -0700 [thread overview]
Message-ID: <526ED316.7090205@qca.qualcomm.com> (raw)
In-Reply-To: <1382986906.7298.10.camel@dcbw.foobar.com>
On 10/28/2013 12:01 PM, Dan Williams wrote:
> On Mon, 2013-10-28 at 18:08 +0000, Chauhan, Rajesh wrote:
>> Hi Luis,
>>
>> For "enough information for proper usage" - how about if I add an attribute for the source of interference (say, for example, "cellular") for each of those frequency range?
> When you say "cellular" here, do mean a WWAN card in the same machine,
> sharing the antenna (or using a very very nearby antenna) with the WiFi
> card? Or do you mean a close-by phone, or a tower itself? How is this
> different from BT coexistence or WiMAX coexistence?
>
One use case would be a colocated WWAN card sharing an antenna or using
a very very nearby antenna. There could be other use cases. I would say
this is complimentary to coexistence. The idea is to tell userspace
which frequencies have know sources of interference so that they can be
avoided, and hence coexistence would not be required. If userspace
chooses to use an "unsafe" frequency, the the driver's coexistence logic
would then be utilized, but the user experience could suffer compared to
if a "safe" frequency had been selected.
The issue that has been debated internally is whether or not userspace
needs to know the source of the interference. In other words, if we
have an enumerated set of interference sources, would userspace behave
differently based upon the source?
This is, after all, just meant to be a hint to userspace to give it more
information to use when selected a channel to be used in a master mode
of operation.
next prev parent reply other threads:[~2013-10-28 21:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 4:57 [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s) Rajesh Chauhan
2013-10-17 14:40 ` Johannes Berg
2013-10-17 17:19 ` Chauhan, Rajesh
2013-10-28 14:44 ` Johannes Berg
2013-10-28 18:14 ` Chauhan, Rajesh
2013-10-17 17:46 ` Chauhan, Rajesh
2013-10-17 18:39 ` Dan Williams
2013-10-17 19:51 ` Chauhan, Rajesh
2013-10-20 10:39 ` Luis R. Rodriguez
2013-10-28 18:08 ` Chauhan, Rajesh
2013-10-28 19:01 ` Dan Williams
2013-10-28 21:11 ` Jeffrey Johnson [this message]
2013-10-29 10:30 ` Luis R. Rodriguez
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=526ED316.7090205@qca.qualcomm.com \
--to=jjohnson@qca.qualcomm.com \
--cc=dcbw@redhat.com \
--cc=hbahini@qca.qualcomm.com \
--cc=johannes@sipsolutions.net \
--cc=jouni@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=rajeshc@qca.qualcomm.com \
--cc=rodrigue@qca.qualcomm.com \
--cc=schang@qca.qualcomm.com \
--cc=xunl@qca.qualcomm.com \
/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