| Message ID | 20190215003129.98298-1-briannorris@chromium.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 6f21ab30469d670de620f758330aca9f3433f693 |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | mwifiex: don't advertise IBSS features without FW support | expand |
Brian Norris <briannorris@chromium.org> wrote: > As it is, doing something like > > # iw phy phy0 interface add foobar type ibss > > on a firmware that doesn't have ad-hoc support just yields failures of > HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code > (-EPERM? not really right...) and sometimes may even crash the firmware > along the way. > > Let's parse the firmware capability flag while registering the wiphy, so > we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP > from nl80211 instead. > > Fixes: e267e71e68ae ("mwifiex: Disable adhoc feature based on firmware capability") > Signed-off-by: Brian Norris <briannorris@chromium.org> Patch applied to wireless-drivers-next.git, thanks. 6f21ab30469d mwifiex: don't advertise IBSS features without FW support
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 1467af22e394..883752f640b4 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -4310,11 +4310,13 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter) wiphy->mgmt_stypes = mwifiex_mgmt_stypes; wiphy->max_remain_on_channel_duration = 5000; wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) | - BIT(NL80211_IFTYPE_ADHOC) | BIT(NL80211_IFTYPE_P2P_CLIENT) | BIT(NL80211_IFTYPE_P2P_GO) | BIT(NL80211_IFTYPE_AP); + if (ISSUPP_ADHOC_ENABLED(adapter->fw_cap_info)) + wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC); + wiphy->bands[NL80211_BAND_2GHZ] = &mwifiex_band_2ghz; if (adapter->config_bands & BAND_A) wiphy->bands[NL80211_BAND_5GHZ] = &mwifiex_band_5ghz; @@ -4374,11 +4376,13 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter) wiphy->available_antennas_tx = BIT(adapter->number_of_antenna) - 1; wiphy->available_antennas_rx = BIT(adapter->number_of_antenna) - 1; - wiphy->features |= NL80211_FEATURE_HT_IBSS | - NL80211_FEATURE_INACTIVITY_TIMER | + wiphy->features |= NL80211_FEATURE_INACTIVITY_TIMER | NL80211_FEATURE_LOW_PRIORITY_SCAN | NL80211_FEATURE_NEED_OBSS_SCAN; + if (ISSUPP_ADHOC_ENABLED(adapter->fw_cap_info)) + wiphy->features |= NL80211_FEATURE_HT_IBSS; + if (ISSUPP_RANDOM_MAC(adapter->fw_cap_info)) wiphy->features |= NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR | NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR |
As it is, doing something like # iw phy phy0 interface add foobar type ibss on a firmware that doesn't have ad-hoc support just yields failures of HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code (-EPERM? not really right...) and sometimes may even crash the firmware along the way. Let's parse the firmware capability flag while registering the wiphy, so we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP from nl80211 instead. Fixes: e267e71e68ae ("mwifiex: Disable adhoc feature based on firmware capability") Signed-off-by: Brian Norris <briannorris@chromium.org> --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)