On Fri, Jan 03, 2020 at 10:55:23AM +0800, Neo Jou wrote: > I agree that " Shouldn't the upper layer code be able to find the > matching mode and > channel from the existing HOSTAPD_MODE_IEEE80211G/_IEEE80211A entries". > At first I met problem at Android VTS test, since "the upper layer > code" doesn't consider > this situation... The issue was recorded at: > https://issuetracker.google.com/issues/145944392 > That's why there comes this temporary solution, just to make Android > VTS pass... > https://android-review.googlesource.com/c/platform/external/wpa_supplicant_8/+/1180867 That issue sounds like a valid issue, but that proposed change does not look at all like a good way of handling this. If hw_mode=any does not work with not offloaded ACS, it would be appropriate to extend that to work rather than try to somehow hide the fact that this functionality has not yet been implemented or try to make upper layer components have to be aware of such difference in capabilities. > I am thinking if there is any general approach for not only QCA, but other > Wifi vendor also. It seems hard to decide which OUI hostapd can use as > the general OUI for hostapd to send Linux wiphy vendor command... I'm not sure I follow what you mean here. hostapd has two available ACS options today: internal one using channel survey mechanism and an offloaded (to the driver) if the driver advertises support for that. There should be no need to be deciding which OUI to use since that happens automatically based on driver capabilities. All this really needs is straightforward extension of the not offloaded ACS to provide same level of functionality as the offloaded case. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
