All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] regression after, " ath9k_htc: Add support for mesh interfaces"
Date: Wed, 26 Jun 2013 09:31:22 +0200	[thread overview]
Message-ID: <1372231882.8157.0.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <CAG6hwVMa+i=wXRyfcwaXH8NesCXgKXW6Ad4dzgd9DZONGYA=xQ@mail.gmail.com> (sfid-20130625_220609_973590_1D631910)

On Tue, 2013-06-25 at 13:05 -0700, Thomas Pedersen wrote:

> That warning is triggered by wiphy_verify_combinations():
> 
>                         if (WARN_ON((wiphy->interface_modes & types) != types))
>                                 return -EINVAL;
> 
> But before that, the mesh iftype bit is cleared in ieee80211_register_hw():
> 
> #ifndef CONFIG_MAC80211_MESH
>         /* mesh depends on Kconfig, but drivers should set it if they want */
>         local->hw.wiphy->interface_modes &= ~BIT(NL80211_IFTYPE_MESH_POINT);
> #endif
> 
> It seems the intention was to avoid an #ifdef CONFIG_MAC80211_MESH in
> every driver, but then mac80211 also has to clear the MESH_POINT bit
> for each ieee80211_iface_limit? I don't really see a cleaner way of
> resolving this.

The problem is that the data structures there are const, so we can't
modify them. I think the other drivers just have an #ifdef on
MAC80211_MESH or so in there.

johannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: Thomas Pedersen <thomas@cozybit.com>
Cc: Oleksij Rempel <linux@rempel-privat.de>,
	"ath9k-devel@lists.ath9k.org" <ath9k-devel@venema.h4ckr.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Javier Cardona <javier@cozybit.com>
Subject: Re: regression after, " ath9k_htc: Add support for mesh interfaces"
Date: Wed, 26 Jun 2013 09:31:22 +0200	[thread overview]
Message-ID: <1372231882.8157.0.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <CAG6hwVMa+i=wXRyfcwaXH8NesCXgKXW6Ad4dzgd9DZONGYA=xQ@mail.gmail.com> (sfid-20130625_220609_973590_1D631910)

On Tue, 2013-06-25 at 13:05 -0700, Thomas Pedersen wrote:

> That warning is triggered by wiphy_verify_combinations():
> 
>                         if (WARN_ON((wiphy->interface_modes & types) != types))
>                                 return -EINVAL;
> 
> But before that, the mesh iftype bit is cleared in ieee80211_register_hw():
> 
> #ifndef CONFIG_MAC80211_MESH
>         /* mesh depends on Kconfig, but drivers should set it if they want */
>         local->hw.wiphy->interface_modes &= ~BIT(NL80211_IFTYPE_MESH_POINT);
> #endif
> 
> It seems the intention was to avoid an #ifdef CONFIG_MAC80211_MESH in
> every driver, but then mac80211 also has to clear the MESH_POINT bit
> for each ieee80211_iface_limit? I don't really see a cleaner way of
> resolving this.

The problem is that the data structures there are const, so we can't
modify them. I think the other drivers just have an #ifdef on
MAC80211_MESH or so in there.

johannes


  reply	other threads:[~2013-06-26  7:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-22  4:56 [ath9k-devel] regression after, " ath9k_htc: Add support for mesh interfaces" Oleksij Rempel
2013-06-22  4:56 ` Oleksij Rempel
2013-06-25  0:54 ` [ath9k-devel] " Thomas Pedersen
2013-06-25  0:54   ` Thomas Pedersen
2013-06-25  6:14   ` [ath9k-devel] " Oleksij Rempel
2013-06-25  6:14     ` Oleksij Rempel
2013-06-25 20:05     ` [ath9k-devel] " Thomas Pedersen
2013-06-25 20:05       ` Thomas Pedersen
2013-06-26  7:31       ` Johannes Berg [this message]
2013-06-26  7:31         ` Johannes Berg
2013-06-26 18:52         ` [ath9k-devel] " Thomas Pedersen
2013-06-26 18:52           ` Thomas Pedersen
2013-06-26 19:16           ` [ath9k-devel] " Oleksij Rempel
2013-06-26 19:16             ` Oleksij Rempel
2013-06-26 21:45             ` [ath9k-devel] " Thomas Pedersen
2013-06-26 21:45               ` Thomas Pedersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1372231882.8157.0.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.