[RFC,2/2] wifi: wireless: deny wireless extensions on MLO-capable devices

From: Johannes Berg <johannes.berg@intel.com>

These are new devices that will be introduced into the market
in 2023, with new drivers. Wireless extensions haven't been in
real development since 2006. Since wireless has evolved a lot,
and continues to evolve significantly with MLO, there's really
no good way to still support wireless extensions for devices
that do MLO.

Stop supporting wireless extensions for new devices. We don't
consider this a regression since no such devices (apart from
hwsim) exist yet.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/wireless/wext-core.c | 4 ++++
 1 file changed, 4 insertions(+)

Johannes Berg <johannes@sipsolutions.net> writes:

> From: Johannes Berg <johannes.berg@intel.com>
>
> These are new devices that will be introduced into the market

s/new/Wi-Fi 7/?

> in 2023, with new drivers. Wireless extensions haven't been in
> real development since 2006. Since wireless has evolved a lot,
> and continues to evolve significantly with MLO, there's really

s/MLO/Multi-Link Operation/?

It would good to spell out the acronym at least once per commit log.

> no good way to still support wireless extensions for devices
> that do MLO.
>
> Stop supporting wireless extensions for new devices. We don't
> consider this a regression since no such devices (apart from
> hwsim) exist yet.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
>  net/wireless/wext-core.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
> index cbeb8be214a8..d3b5cf02690c 100644
> --- a/net/wireless/wext-core.c
> +++ b/net/wireless/wext-core.c
> @@ -662,6 +662,8 @@ struct iw_statistics *get_wireless_stats(struct net_device *dev)
>  	    dev->ieee80211_ptr->wiphy->wext &&
>  	    dev->ieee80211_ptr->wiphy->wext->get_wireless_stats) {
>  		wireless_warn_cfg80211_wext();
> +		if (dev->ieee80211_ptr->wiphy->flags & WIPHY_FLAG_SUPPORTS_MLO)
> +			return NULL;

Should we have a some kind of warning in this case as well? Otherwise
the user has no idea why it stopped working, right?

>  		return dev->ieee80211_ptr->wiphy->wext->get_wireless_stats(dev);
>  	}
>  #endif
> @@ -702,6 +704,8 @@ static iw_handler get_handler(struct net_device *dev, unsigned int cmd)
>  #ifdef CONFIG_CFG80211_WEXT
>  	if (dev->ieee80211_ptr && dev->ieee80211_ptr->wiphy) {
>  		wireless_warn_cfg80211_wext();
> +		if (dev->ieee80211_ptr->wiphy->flags & WIPHY_FLAG_SUPPORTS_MLO)
> +			return NULL;

And here?

On Thu, 2022-11-17 at 12:51 +0200, Kalle Valo wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
> > From: Johannes Berg <johannes.berg@intel.com>
> > 
> > These are new devices that will be introduced into the market
> 
> s/new/Wi-Fi 7/?
> 
> > in 2023, with new drivers. Wireless extensions haven't been in
> > real development since 2006. Since wireless has evolved a lot,
> > and continues to evolve significantly with MLO, there's really
> 
> s/MLO/Multi-Link Operation/?
> 
> It would good to spell out the acronym at least once per commit log.

:)

> > +++ b/net/wireless/wext-core.c
> > @@ -662,6 +662,8 @@ struct iw_statistics *get_wireless_stats(struct net_device *dev)
> >  	    dev->ieee80211_ptr->wiphy->wext &&
> >  	    dev->ieee80211_ptr->wiphy->wext->get_wireless_stats) {
> >  		wireless_warn_cfg80211_wext();
> > +		if (dev->ieee80211_ptr->wiphy->flags & WIPHY_FLAG_SUPPORTS_MLO)
> > +			return NULL;
> 
> Should we have a some kind of warning in this case as well? Otherwise
> the user has no idea why it stopped working, right?

Well it's added after the warning wireless_warn_cfg80211_wext(), so it
already prints the warning from the previous.

I guess we could make an argument to the warning and modify the message
if it's rejected?

johannes

Johannes Berg <johannes@sipsolutions.net> writes:

> On Thu, 2022-11-17 at 12:51 +0200, Kalle Valo wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>> 
>> > From: Johannes Berg <johannes.berg@intel.com>
>> > 
>> > These are new devices that will be introduced into the market
>> 
>> s/new/Wi-Fi 7/?
>> 
>> > in 2023, with new drivers. Wireless extensions haven't been in
>> > real development since 2006. Since wireless has evolved a lot,
>> > and continues to evolve significantly with MLO, there's really
>> 
>> s/MLO/Multi-Link Operation/?
>> 
>> It would good to spell out the acronym at least once per commit log.
>
> :)
>
>> > +++ b/net/wireless/wext-core.c
>> > @@ -662,6 +662,8 @@ struct iw_statistics *get_wireless_stats(struct net_device *dev)
>> >  	    dev->ieee80211_ptr->wiphy->wext &&
>> >  	    dev->ieee80211_ptr->wiphy->wext->get_wireless_stats) {
>> >  		wireless_warn_cfg80211_wext();
>> > +		if (dev->ieee80211_ptr->wiphy->flags & WIPHY_FLAG_SUPPORTS_MLO)
>> > +			return NULL;
>> 
>> Should we have a some kind of warning in this case as well? Otherwise
>> the user has no idea why it stopped working, right?
>
> Well it's added after the warning wireless_warn_cfg80211_wext(), so it
> already prints the warning from the previous.
>
> I guess we could make an argument to the warning and modify the message
> if it's rejected?

Sorry, I was blind again :) I first read that the call to
wireless_warn_cfg80211_wext() was removed, but clearly it wasn't, and
IMHO that warning is enough. So please ignore this comment.