On Friday, August 23, 2013 04:16:49 PM Johannes Berg wrote: > Ilan also pointed out to me that it might be necessary to document (and > enforce?) that scan/sched_scan can't be executed in parallel? Or can > they? Indeed, one can't simultaneously scan and do p2p_find on the same hardware, because of contradictionary requirements. I documented it in start_p2p_find: > + * P2P find can't run concurrently with ROC or scan, > + * conflict with scan detected by cfg80211 and -EBUSY returned; > + * and driver should check for ROC and return -EBUSY to indicate > conflict. Shall I elaborate more, what is appropriate location for this explanation? Regarding locking - I feel I need to do it similar to scan. There, we have locked inner function that is invoked from cfg80211_wq. And, overall - maybe reuse scan pattern in other aspects - allocate cfg80211_p2p_find_params like it is done for cfg80211_scan_request (and rename struct to cfg80211_p2p_find_request). instead of wdev->p2p_find_active, have rdev->p2p_find_req - this will sort concurrent p2p_find for sibling wdevs Also, same pattern will make p2p_find API more intuitive if it follows same conventions as scan Comments? -- 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
