On 3/25/2022 2:16 PM, Johannes Berg wrote:
On Fri, 2022-03-25 at 20:36 +0000, William McVicker wrote:
I found that my wlan driver is using the vendor commands to create/delete NAN
interfaces for this Android feature called Wi-Fi aware [1]. Basically, this
features allows users to discover other nearby devices and allows them to
connect directly with one another over a local network.
Wait, why is it doing that? We actually support a NAN interface type
upstream :) It's not really quite fully fleshed out, but it could be?
Probably should be?
And this is the issue with Android drivers. Android team proposes
changes to the Wifi HAL and driver vendors have to implement those
quickly to meet product deadlines. Some infrastructure changes we're
able to get into the core kernel without having an in-tree driver that
uses them (such as introducing NL80211_IFTYPE_NAN), but there have been
instances of core kernel changes being rejected because there was not an
in-tree user.
Yes, in your ideal world all of the Android wifi drivers would be
in-tree. And in that ideal world every release cycle the Android team
would advocate for core kernel changes needed to support the new
features of the HAL. But past history has shown attempts to upstream new
features has been delayed, perhaps in part due to the absence of an
in-tree driver that utilizes those features, and the only way to meet
product deadlines is to take the vendor command route.
And yes my out-of-tree driver is facing the exact same issue with NAN
interface creation and deletion via vendor commands.
Previously you had suggested:
Your easiest option might be to just patch NL80211_FLAG_NEED_RTNL into
your kernel for vendor commands and call it a day?
Would you consider taking that upstream given that there are very few
in-tree users of vendor commands, and I fear Will and I aren't the only
ones who'll face this issue?
Will, suggest you at least advocate for getting this into the 5.15 ACK.
/jeff
