On Thu, Oct 17, 2013 at 9:51 PM, Chauhan, Rajesh <rajeshc@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
