Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)

[Dan Williams <dcbw@redhat.com>]

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?

Dan

> Regards,
> Rajesh Chauhan
> 
> -----Original Message-----
> From: mcgrof@gmail.com [mailto:mcgrof@gmail.com] On Behalf Of Luis R. Rodriguez
> Sent: Sunday, October 20, 2013 3:39 AM
> To: Chauhan, Rajesh
> Cc: Dan Williams; Johannes Berg; linux-wireless@vger.kernel.org; Malinen, Jouni; Bahini, Henri; Chang, Leo; Luo, Xun
> Subject: Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
> 
> On Thu, Oct 17, 2013 at 9:51 PM, Chauhan, Rajesh <rajeshc@qca.qualcomm.com> wrote:
> > Hi Dan,
> >
> > Thanks for your comments.
> >
> > Current patch is to report event asynchronously and that would be needed even if we have your suggested interface of client collecting that information upfront, which seems like you also kind of agree, because RF environment may change later and generating an event at that time with frequency details would help. So your suggested approach of "mechanism for the client to get this information" in itself seems like a candidate for a separate patch.
> 
> The infrastructure for this sort of thing that me, Inaky and Marcel had proposed in 2007 is the Frequency Broker:
> 
> http://wireless.kernel.org/en/developers/FrequencyBroker
> 
> > On the race condition which you described - thanks!, but it is something which implementation of driver would need to take care. Similarly, user space can have implementation to cache information on receipt of the event to use it later.
> 
> This patch is vague. Once we set something as API we have to live with it, I am not comfortable with this patch having enough information for proper usage by different drivers for the same purpose or intent. The only real positive argument that could be used here is where something like Android might have already embraced some similar API but are we going to always just enable API on Linux just because Android did it without thinking about proper long term architecture? I don't think so.
> 
>  Luis