All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Alexandre Salim <salimma@fedoraproject.org>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH] ath9k: add module option for disabling 11n functionality
Date: Wed, 29 Jun 2011 15:43:20 +0200	[thread overview]
Message-ID: <4E0B2BF8.6090300@fedoraproject.org> (raw)
In-Reply-To: <20110629130910.GA2688@jm.kir.nu>

On 06/29/2011 03:09 PM, Jouni Malinen wrote:
> On Wed, Jun 29, 2011 at 10:56:33AM +0200, Michel Alexandre Salim wrote:
>> I agree with you and Adrian; it should ideally be in the 802.11
>> stack. But as Ben noted, it does have a useful purpose -- for
>> debugging.
>>
>> If the maintainers are agreeable to a shared mac80211 mechanism,
>> which is the preferred way to handle this -- get this in, then
>> refactor *both* iwlagn and ath9k to use it, or to implement a shared
>> mechanism, demonstrate it with ath9k, then fix iwlagn later?
>
> I don't follow this.. Why would we get this into ath9k first if the more
> appropriate way of doing this would be to modify mac80211 in the first
> place. I see no point in doing driver specific hacks for this unless
> there really is some driver specific issues that are being worked around
> and that does not seem to be the case here.
>
The argument would be that driver-specific implementations are easier to 
get committed, and less intrusive than a general framework, but yes, I 
would prefer a more general solution myself.

> As far as being able to disable 802.11n in general is concerned, it
> would much better to do that as a parameter for the connection (e.g.,
> new nl80211 attribute for NL80211_CMD_ASSOCIATE) rather than a module
> parameter. This workaround seems to be needed with some APs and global
> disabling of 802.11n does not sound like the ideal mechanism for that.

Would this not require modifications to e.g. NetworkManager, ConnMan 
etc.  as well? While a module parameter is not an ideal workaround, it's 
at least easy to use. If this goes in as a connection parameter, it'd be 
nice to still have a way of manually adjusting it through a command-line 
tool.

My first attempt to solve this was to use 'iwconfig wlan0 set rate 54M' 
-- but this yields "Operation not supported". How about making a request 
for a rate of 54M or below switch the device to 802.11g mode (and 
optionally, a rate of 11M or below => 802.11b mode)? That way we don't 
need to invent a new interface at all. How would I go about adding 
support for rate setting requests to the driver?

Thanks,

-- 
Michel Alexandre Salim
?blog:      http://identi.ca/hircus
             http://twitter.com/hircus
GPG key ID: 78884778

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

WARNING: multiple messages have this Message-ID (diff)
From: Michel Alexandre Salim <salimma@fedoraproject.org>
To: Jouni Malinen <j@w1.fi>
Cc: "John W. Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net,
	"Luis R. Rodriguez" <lrodriguez@atheros.com>,
	Jouni Malinen <jmalinen@atheros.com>,
	Vasanthakumar Thiagarajan <vasanth@atheros.com>,
	Senthil Balasubramanian <senthilkumar@atheros.com>
Subject: Re: [PATCH] ath9k: add module option for disabling 11n functionality
Date: Wed, 29 Jun 2011 15:43:20 +0200	[thread overview]
Message-ID: <4E0B2BF8.6090300@fedoraproject.org> (raw)
In-Reply-To: <20110629130910.GA2688@jm.kir.nu>

On 06/29/2011 03:09 PM, Jouni Malinen wrote:
> On Wed, Jun 29, 2011 at 10:56:33AM +0200, Michel Alexandre Salim wrote:
>> I agree with you and Adrian; it should ideally be in the 802.11
>> stack. But as Ben noted, it does have a useful purpose -- for
>> debugging.
>>
>> If the maintainers are agreeable to a shared mac80211 mechanism,
>> which is the preferred way to handle this -- get this in, then
>> refactor *both* iwlagn and ath9k to use it, or to implement a shared
>> mechanism, demonstrate it with ath9k, then fix iwlagn later?
>
> I don't follow this.. Why would we get this into ath9k first if the more
> appropriate way of doing this would be to modify mac80211 in the first
> place. I see no point in doing driver specific hacks for this unless
> there really is some driver specific issues that are being worked around
> and that does not seem to be the case here.
>
The argument would be that driver-specific implementations are easier to 
get committed, and less intrusive than a general framework, but yes, I 
would prefer a more general solution myself.

> As far as being able to disable 802.11n in general is concerned, it
> would much better to do that as a parameter for the connection (e.g.,
> new nl80211 attribute for NL80211_CMD_ASSOCIATE) rather than a module
> parameter. This workaround seems to be needed with some APs and global
> disabling of 802.11n does not sound like the ideal mechanism for that.

Would this not require modifications to e.g. NetworkManager, ConnMan 
etc.  as well? While a module parameter is not an ideal workaround, it's 
at least easy to use. If this goes in as a connection parameter, it'd be 
nice to still have a way of manually adjusting it through a command-line 
tool.

My first attempt to solve this was to use 'iwconfig wlan0 set rate 54M' 
-- but this yields "Operation not supported". How about making a request 
for a rate of 54M or below switch the device to 802.11g mode (and 
optionally, a rate of 11M or below => 802.11b mode)? That way we don't 
need to invent a new interface at all. How would I go about adding 
support for rate setting requests to the driver?

Thanks,

-- 
Michel Alexandre Salim
µblog:      http://identi.ca/hircus
             http://twitter.com/hircus
GPG key ID: 78884778

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

  reply	other threads:[~2011-06-29 13:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-28 19:46 [ath9k-devel] [PATCH] ath9k: add module option for disabling 11n functionality Michel Alexandre Salim
2011-06-28 19:46 ` Michel Alexandre Salim
2011-06-28 19:51 ` [ath9k-devel] " Ben Greear
2011-06-28 19:51   ` Ben Greear
2011-06-28 20:06   ` [ath9k-devel] " Luis R. Rodriguez
2011-06-28 20:06     ` Luis R. Rodriguez
2011-06-28 20:40     ` Ben Greear
2011-06-28 20:40       ` Ben Greear
2011-06-29 17:50     ` Andreas Hartmann
2011-06-28 21:57 ` Jouni Malinen
2011-06-28 21:57   ` Jouni Malinen
2011-06-29  1:26   ` [ath9k-devel] " Adrian Chadd
2011-06-29  1:26     ` Adrian Chadd
2011-06-29  8:56   ` [ath9k-devel] " Michel Alexandre Salim
2011-06-29  8:56     ` Michel Alexandre Salim
2011-06-29 13:09     ` [ath9k-devel] " Jouni Malinen
2011-06-29 13:09       ` Jouni Malinen
2011-06-29 13:43       ` Michel Alexandre Salim [this message]
2011-06-29 13:43         ` Michel Alexandre Salim
2011-06-29 13:55         ` [ath9k-devel] " Jouni Malinen
2011-06-29 13:55           ` Jouni Malinen
2011-06-29 14:06           ` [ath9k-devel] " Michel Alexandre Salim
2011-06-29 14:06             ` Michel Alexandre Salim

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=4E0B2BF8.6090300@fedoraproject.org \
    --to=salimma@fedoraproject.org \
    --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.