On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote:
> This allows individual users and deployments to disable mesh support at
> runtime, i.e. without having to build and maintain a custom kernel.
Does the mesh interface somehow cause problems, even when nothing is
using it? I'd expect that if the mesh interface was simply left alone,
there would be no need to disable it.
Dan
> Based on a patch by Paul Fox <pgf@xxxxxxxxxx>.
> Signed-off-by: Sascha Silbe <silbe@xxxxxxxxxxxxxxxxxxx>
> ---
> drivers/net/wireless/libertas/main.c | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> The patch is based on the OLPC 2.6.35 kernel tree, but applies cleanly to
> wireless-next.
>
> diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
> index 8445473..62069e2 100644
> --- a/drivers/net/wireless/libertas/main.c
> +++ b/drivers/net/wireless/libertas/main.c
> @@ -41,6 +41,10 @@ unsigned int lbs_debug;
> EXPORT_SYMBOL_GPL(lbs_debug);
> module_param_named(libertas_debug, lbs_debug, int, 0644);
>
> +unsigned int lbs_disablemesh;
> +EXPORT_SYMBOL_GPL(lbs_disablemesh);
> +module_param_named(libertas_disablemesh, lbs_disablemesh, int, 0644);
> +
>
> /* This global structure is used to send the confirm_sleep command as
> * fast as possible down to the firmware. */
> @@ -1086,7 +1090,10 @@ int lbs_start_card(struct lbs_private *priv)
>
> lbs_update_channel(priv);
>
> - lbs_init_mesh(priv);
> + if (!lbs_disablemesh)
> + lbs_init_mesh(priv);
> + else
> + lbs_pr_info("%s: mesh disabled\n", dev->name);
>
> /*
> * While rtap isn't related to mesh, only mesh-enabled
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
