On 9/10/24 12:08 PM, Alexis Lothoré wrote:
On 9/9/24 21:29, Marek Vasut wrote:
Register wiphy after reading out chipid, so the chipid can be
used to determine chip features and not advertise WPA3/SAE
support to userspace on WILC3000. Note that wilc_netdev_cleanup()
will deregister the wiphy in fail path.
Signed-off-by: Marek Vasut <marex@xxxxxxx>
[...]
@@ -1804,14 +1803,8 @@ static struct wilc *wilc_create_wiphy(struct device *dev)
BIT(NL80211_IFTYPE_P2P_GO) |
BIT(NL80211_IFTYPE_P2P_CLIENT);
wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
- wiphy->features |= NL80211_FEATURE_SAE;
set_wiphy_dev(wiphy, dev);
wl->wiphy = wiphy;
- ret = wiphy_register(wiphy);
- if (ret) {
- wiphy_free(wiphy);
- return NULL;
- }
If I am reading the patch correctly, there are still some failure paths in
wilc_cfg80211_init which try to call wiphy_unregister on the (not registered
anymore in there) wphy.
return wl;
}
@@ -1861,6 +1854,14 @@ int wilc_cfg80211_init(struct wilc **wilc, struct device *dev, int io_type,
}
EXPORT_SYMBOL_GPL(wilc_cfg80211_init);
+int wilc_cfg80211_register(struct wilc *wilc)
+{
+ wilc->wiphy->features |= NL80211_FEATURE_SAE;
Even if I get the general need, it feels weird to have parts of the wphy init
performed in wilc_create_wiphy, and some parts (the features field) here.
Wouldn't it work to just move wilc_create_wiphy content here, since wphy will
not be usable anyway before eventually registering it ?
That's what I thought initially too, but look closely at
wilc_create_wiphy():
struct wilc *wilc_create_wiphy(struct device *dev)
{
...
struct wiphy *wiphy;
struct wilc *wl;
...
wiphy = wiphy_new(&wilc_cfg80211_ops, sizeof(*wl));
...
wl = wiphy_priv(wiphy); // <----------- HERE , *wl is struct wilc
...
return wl;
}
That 'struct wilc' is allocated as part of wiphy_new() and used all
around the place before we reach wiphy_register() much later on.
