Yep, I need this fix as well. Without it the ath5k driver built in

bombs out during module_init(). Something with kref and a struct

device pointing to an uninitialized ieee80211_class.
I need a similar fix for net/mac80211/rc80211_simple.c as well to get

ath5k working though, not sure why at the moment. There may be some

bug with request_module() not being called properly.

ieee80211_register_hw() calls ieee80211_init_rate_ctrl_alg() with NULL

as name which calls rate_control_alloc() with NULL which always seems

to fail when built in.
This hack works around that problem, not sure what the real fix is.
--- 0002/net/mac80211/rc80211_simple.c

+++ work/net/mac80211/rc80211_simple.c  2007-09-09 18:11:48.000000000 +0900

@@ -431,7 +431,8 @@ static void __exit rate_control_simple_e

 }
-module_init(rate_control_simple_init);

+//module_init(rate_control_simple_init);

+postcore_initcall(rate_control_simple_init);

 module_exit(rate_control_simple_exit);
 MODULE_DESCRIPTION("Simple rate control algorithm for ieee80211");
Thanks,
/ magnus

-

Nah, it's just all too late and the rate control algorithm is built-in

too iirc. Rob tested a patch that changes those to subsys_initcall() as

well, so I'll be posting that.
johannes

Same problem here, except with the rt2x00 driver. I changed it to

subsys_initcall(rate_control_simple_init), which also worked. I also

found that without this change, it was failing at this point in

ieee80211_rate.c:
ieee80211_try_rate_control_ops_get(const char *name)

{

        struct rate_control_alg *alg;

        struct rate_control_ops *ops = NULL;
        mutex_lock(&rate_ctrl_mutex);

        list_for_each_entry(alg, &rate_ctrl_algs, list) {   <===== Here

                if (!name || !strcmp(alg->ops->name, name))

                        if (try_module_get(alg->ops->module)) {

                                ops = alg->ops;

                                break;

                        }

-