Re: [PATCH] Revert "ipw2200: select CFG80211_WEXT"

[Johannes Berg]

On Mon, 2015-01-05 at 18:38 +0100, Paul Bolle wrote:

> > ipw2200 is a WEXT driver using some wext functionality (and struct 
> > wiphy) provided by cfg80211 hence it needs CFG80211_WEXT. I guess that 
> > is what makes it confusing.
> 
> It doesn't help that I hardly know anything about mac80211, cfg80211 and
> nl80211 (and lib80211 for that matter). To me these are mostly just
> names that end in 80211.

:-)
There isn't really all that much that ipw2x00 is using from cfg80211
though - of note is that it has completely empty ops:

static struct cfg80211_ops libipw_config_ops = { };

IOW - all it does is register with the framework - courtesy of
a3caa99e6c68f. It's practically useless.

> Anyhow, concerning, CFG80211_WEXT: it seems the only functionality
> provided by that symbol that ipw2200 uses directly is
> cfg80211_wext_giwname(). Perhaps ipw2200 could have a private version of
> that function, something like ipw2100's ipw2100_wx_get_name(). Should be
> trivial to implement (ie, it could take _me_ a day or two).

We could just revert that part of the commit above - or even completely.

However, in theory at least doing *that* would now be a userspace
regression - today you can at least discover the presence of ipw2200
devices with nl80211, even if you can't do anything with them that way.

> But perhaps ipw2200 uses CFG80211_WEXT _indirectly_ too. Ie, in
> net/wireless/core.c I stumbled on
>     #ifdef CONFIG_CFG80211_WEXT
>             rdev->wiphy.wext = &cfg80211_wext_handler;
>     #endif

I don't think it does - see the note about the ops above. If it did,
it'd have to implement the ops.

> But I net/wireless/wext-core.c I then found
>     #ifdef CONFIG_CFG80211_WEXT
>             if (dev->ieee80211_ptr && dev->ieee80211_ptr->wiphy)
>                     handlers = dev->ieee80211_ptr->wiphy->wext;
>     #endif
>     #ifdef CONFIG_WIRELESS_EXT
>             if (dev->wireless_handlers)
>                     handlers = dev->wireless_handlers;
>     #endif
> 
> (There's much more to discover about WEXT, of course.) Anyhow, IPW2200
> uses both CFG80211_WEXT and WIRELESS_EXT and cfg80211_wext_handler and
> ipw2200's wireless_handlers appear to cover the same set of IOCTLS (one
> exception: SIOCSIWPMKSA). So by now I'm really puzzled how this all fits
> together.

Well, this was meant as a transition mechanism for drivers. Ultimately,
the way we thought how you'd convert a driver (and how we converted
mac80211) would be to have the wext handlers like for example the scan
ones:

static iw_handler ipw_wx_handlers[] = {
...
        IW_HANDLER(SIOCSIWSCAN, ipw_wx_set_scan),
        IW_HANDLER(SIOCGIWSCAN, ipw_wx_get_scan),
...
};

Then you could make a patch that uses the cfg80211 APIs for scanning in
the driver -- i.e. implement the cfg80211_ops.scan method, report frames
to the cfg80211 scanning and remove all the ieee->network_list stuff
etc. using the related cfg80211 API (e.g. cfg80211_get_bss() and friends
for getting a network, etc.) And then you'd change the handlers to be

static iw_handler ipw_wx_handlers[] = {
...
        IW_HANDLER(SIOCSIWSCAN, cfg80211_wext_siwscan),
        IW_HANDLER(SIOCGIWSCAN, cfg80211_wext_giwscan),
...
};

This part would have to be done in a single patch.

Multiple other groups of ioctls could be converted in similar patches,
until at the end you can completely remove ipw_wx_handlers and rely
entirely on cfg80211's wext compatibility.

So far the theory - in practice nobody cared enough to start working on
any of these drivers, let alone actually has the hardware today.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/