On 2018-12-18 18:35, Johannes Berg wrote:
On Fri, 2018-11-16 at 17:13 +0530, Veerendranath Jakkam wrote:
There was no such capability advertisement from the driver and thus
the
current user space has to assume the driver to support all the AKMs.
While
that may be the case with some drivers (e.g., mac80211-based ones),
there
are cfg80211-based drivers that have constraints on which AKMs can be
used.
Allow such drivers to advertise the exact set of supported AKMs so
that
user space tools can determine what network profile options should be
allowed to be configured.
I think you need to explain here (and probably also in the docs) where
this actually matters. Clearly with drivers that do it all in userspace
it doesn't matter - so I guess it's intended for the offload cases?
Also, it'd be good to know which driver needs/implements this.
This is required by the Wi-Fi driver/solution , where the SME is part of
the driver and does not define separate commands for authentication and
association. The driver we are targeting here is specific to Qualcomm
and the design needs update to support new AKM's. (For EX,this driver
needs an enhancement to trigger NL80211_CMD_EXTERNAL_AUTH for SAE AKM).
This commit addresses the requirement of user space entity to know the
supported AKM's by a specific driver version.
As you have rightly mentioned this capability would also be required for
the cases where an AKM is offloaded to the driver/firmware.
Finally,
+ if (rdev->wiphy.akm_suites)
+ if (nla_put(msg, NL80211_ATTR_AKM_SUITES,
+ sizeof(u32) * rdev->wiphy.n_akm_suites,
+ rdev->wiphy.akm_suites))
+ goto nla_put_failure;
That's probably better written as a single if statement.
Thanks . We shall update this in the next version.
johannes
