* Re: [PATCH w-t 2/3] rt2500usb: truly disable encryption when initialize
From: Ivo Van Doorn @ 2010-07-27 17:48 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Gertjan van Wingerde
In-Reply-To: <20100727144811.6012.56633.send-patch@dhcp-lab-109.englab.brq.redhat.com>
On Tue, Jul 27, 2010 at 4:48 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Without cipher part nullify of TXRX_CSR0 register we can receive
> corrupted frames (removed IV or IVC), after reloading rt2500usb module
> with nohwcrypt=1 option, if previous some keys were configured into
> the hardware.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2500usb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
> index 7892647..3028abb 100644
> --- a/drivers/net/wireless/rt2x00/rt2500usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2500usb.c
> @@ -813,6 +813,7 @@ static int rt2500usb_init_registers(struct rt2x00_dev *rt2x00dev)
> rt2500usb_register_write(rt2x00dev, MAC_CSR8, reg);
>
> rt2500usb_register_read(rt2x00dev, TXRX_CSR0, ®);
> + rt2x00_set_field16(®, TXRX_CSR0_ALGORITHM, CIPHER_NONE);
> rt2x00_set_field16(®, TXRX_CSR0_IV_OFFSET, IEEE80211_HEADER);
> rt2x00_set_field16(®, TXRX_CSR0_KEY_ID, 0);
> rt2500usb_register_write(rt2x00dev, TXRX_CSR0, reg);
> --
> 1.7.1
>
>
^ permalink raw reply
* Re: [PATCH w-t 1/3] rt2500usb: write keys to proper registers
From: Ivo Van Doorn @ 2010-07-27 17:48 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Gertjan van Wingerde, John W. Linville
In-Reply-To: <20100727144804.6012.94740.send-patch@dhcp-lab-109.englab.brq.redhat.com>
On Tue, Jul 27, 2010 at 4:48 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Fix rt2500usb hardware encryption broken by commit
> 96b61bafe22b2f2abcc833d651739edb977f1b1e
> "rt2x00: Clean up USB vendor request buffer functions"
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
> index 4b2fef3..7892647 100644
> --- a/drivers/net/wireless/rt2x00/rt2500usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2500usb.c
> @@ -376,7 +376,7 @@ static int rt2500usb_config_key(struct rt2x00_dev *rt2x00dev,
> if (key->hw_key_idx > 0 && crypto->cipher != curr_cipher)
> return -EOPNOTSUPP;
>
> - rt2500usb_register_multiwrite(rt2x00dev, reg,
> + rt2500usb_register_multiwrite(rt2x00dev, KEY_ENTRY(key->hw_key_idx),
> crypto->key, sizeof(crypto->key));
>
> /*
> --
> 1.7.1
>
>
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: Luis R. Rodriguez @ 2010-07-27 17:36 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, David Miller
In-Reply-To: <20100727171850.GD31694@tuxdriver.com>
On Tue, Jul 27, 2010 at 10:18 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Tue, Jul 27, 2010 at 09:54:20AM -0700, Luis R. Rodriguez wrote:
>
>> So I guess the next question is where does David base his net-next.git
>> off from? Will it only include 802.11 / Ethernet / Wimax / netcore /
>> etc next bits or is there more? I ask to know what I'm in for in case
>> I want to bisect from it or derivatives (wireless-next.git).
>
> Generally he branches from linux-2.6 at around -rc1 (and sometimes
> before) and then doesn't pull again until after the release.
Thanks this helps a lot!
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: fix sw scan bracketing
From: Luis R. Rodriguez @ 2010-07-27 17:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <AANLkTi=ZbskS-7TA8Mp5SKrRMrxOpNQJLpxnCHoRs-tb@mail.gmail.com>
On Tue, Jul 27, 2010 at 8:54 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Tue, Jul 27, 2010 at 3:22 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Tue, 2010-07-27 at 02:22 -0700, Luis R. Rodriguez wrote:
>>> To address and review all this I need more time and instead I think
>>> its easier to ask for revert of this patch.
>>
>> I'm OK with a revert, but *ONLY* if at the same time you remove the
>> double-scan-detected message from ath9k and stop claiming it's a
>> mac80211 bug :-)
>
> Deal :)
I just reviewed this and noticed both of these prints are using
KERN_DEBUG, and since the warning will become valid *after* this gets
properly fixed, are you OK with just a revert of your patch?
Luis
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: John W. Linville @ 2010-07-27 17:18 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, David Miller
In-Reply-To: <AANLkTi=Yan5f7hcGm-GTDL=aJ_Oc-U8JExZXMZdr+MPZ@mail.gmail.com>
On Tue, Jul 27, 2010 at 09:54:20AM -0700, Luis R. Rodriguez wrote:
> So I guess the next question is where does David base his net-next.git
> off from? Will it only include 802.11 / Ethernet / Wimax / netcore /
> etc next bits or is there more? I ask to know what I'm in for in case
> I want to bisect from it or derivatives (wireless-next.git).
Generally he branches from linux-2.6 at around -rc1 (and sometimes
before) and then doesn't pull again until after the release.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 4/5] mac80211: add WoW support
From: Luis R. Rodriguez @ 2010-07-27 17:20 UTC (permalink / raw)
To: Simsek, Burak; +Cc: Luis Rodriguez, linux-wireless
In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA1037B5158@EXCHSRV.fokus.fraunhofer.de>
On Tue, Jul 27, 2010 at 08:12:10AM -0700, Simsek, Burak wrote:
> Dear Luis,
>
> I have found out that you have worked on WoW for ath9k for a while. However,
> in the wiki page of wireless.kernel.org the current state is written as
> ongoing work. Can you please tell me whether you were successful while
> implementing WoW. Is there anything that we could use?
WoW worked for me but inconsistantly and at the time of writing
the patches I had to do quite a lot of coordination with Johannes
since he had a lot of API changes and his changes needed to get
merged first.
I also found quite a few issues in mac80211 back then but I believe
we have resolved all of them by now so I would expect that if the
same WoW-only patches to be rebased and tested we may get better
results.
I stopped working on the WoW stuff due to lack of time to keep
testing them but the last series can be edited to remove all
of the already merged stuff and test out the new stuff. The more
challenging thing for me was to actually get a WoW enabled
802.11 card, these are not as popular as you would hope. The
EEPROM would be modified when WoW is enabled but WoW requires
some actual hardware mucking to allow for the PCI Wake signal
which is typically blocked off. If the EEPROM has WoW enabled
then the hardware mucking would have been done.
To test WoW you also need to drop Network Manager and use
the supplicant directly so that during suspend you remain
associated. I should note that WoW will only work on
non-WPA networks with ath9k due to the lack of
hardware CPU, during suspend there is only power for the
802.11 hardware, the CPU on your box would be asleep but
would be required for group key changes. The way I was thinking
of doing this was to only enable WoW through cfg80211 for ath9k if
and only if you are associated and you are connected to a non
WPA network.
WoW would work with encryption on our USB devices where
there is a CPU though.
You can find my last series here:
http://www.mk.kernel.org/pub/linux/kernel/people/mcgrof/patches/wow-07-21.patch
http://www.mk.kernel.org/pub/linux/kernel/people/mcgrof/patches/iw-add-wow.patch
If you manage to do what I noted above, get an actual WoW enabled card,
and it works reliably I'd gladly welcome and ACK the patches :)
Luis
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: Luis R. Rodriguez @ 2010-07-27 16:54 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, David Miller
In-Reply-To: <20100727163141.GC31694@tuxdriver.com>
On Tue, Jul 27, 2010 at 9:31 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Tue, Jul 27, 2010 at 09:21:40AM -0700, Luis R. Rodriguez wrote:
>> On Tue, Jul 27, 2010 at 9:04 AM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>> > On Tue, Jul 27, 2010 at 08:56:54AM -0700, Luis R. Rodriguez wrote:
>> >> On Tue, Jul 27, 2010 at 7:01 AM, John W. Linville
>> >> <linville@tuxdriver.com> wrote:
>
>> >> > As for right now, it sounds like you should just use wireless-next-2.6
>> >> > instead?
>> >>
>> >> Oh OK, didn't realize that was bisectable, thanks. Also was unsure if
>> >> I'd get other subsystems's -next components. Is wireless-next.git just
>> >> the -next bits for 802.11 or does it also suck up net-next?
>> >
>> > Usually just the wireless bits, but I did just pull the bluetooth stuff
>> > (which included some net-next stuff).
>>
>> Oh neat. OK so which net-next.git release was wireless-next.git based
>> on and what net-next.git release was bluetooth-next.git based on? Did
>> it bump your next-next.git or do you routinely pull next-next.git into
>> your own wireless-next.git?
>
> I don't have those exact commit IDs. How badly do you need them?
I don't at all, was just interested to know if they were indeed
different and how each differ in terms of pulling new net-next.git
bits from future next-(date -I) releases.
> I don't normally pull net-next into wireless-next, but this release
> not doing that has been a source of pain due to the __packed patch
> in net-next and the addition of __attribute__ ((packed)) in various
> places in wireless-next. Since Marcel had already based on a net-next
> that had that patch and since it is close to the end of the release
> I decided it would be acceptable to pull it this time.
Ah I see.
> I have been considering making regular net-next pulls a standard
> practice. That would make my life easier, but would add some
> non-wireless instability into wireless-testing (which pulls from
> wireless-next). I don't think that would be a big problem _most_
> of the time, but I'm sure there would be some occasional pain from
> doing that.
Thanks for the details. Yeah indeed my concern over bisecting
wireless-next.git would have been testing other bleeding edge
non-802.11 / BT subsystem stuff, things in net core, but relying on
the master-(date -I) tags sufficed for me to bisect an issue down to
early June. Think I'll stick to that for now but I suppose we should
not fear using next-next.git as much given that we now have both
802.11 and BT
So I guess the next question is where does David base his net-next.git
off from? Will it only include 802.11 / Ethernet / Wimax / netcore /
etc next bits or is there more? I ask to know what I'm in for in case
I want to bisect from it or derivatives (wireless-next.git).
Luis
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-07-27 16:47 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <4C4F0BB1.6030002@openwrt.org>
On Tue, Jul 27, 2010 at 9:39 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-27 6:19 PM, Luis R. Rodriguez wrote:
>>> + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for transmitting.
>>> + * Each bit represents one antenna, starting with antenna 1 at the first
>>> + * bit. If the bitmap is zero (0), the TX antenna follows RX diversity.
>>
>> What about for 802.11n? What if you want to disable TX?
> Disabling tx shouldn't be handled by the antenna setting, IMHO.
>
>>> + * If multiple antennas are selected all selected antennas have to be used
>>> + * for transmitting (801.11n multiple TX chains).
>>
>> I rather call this TX / RX chainmask then.
> Well, for legacy hardware, these aren't really chains, as there is only
> one rx and one tx path, just with switching onto multiple antennas.
>
>>> + * Drivers may reject configurations they cannot support.
>>> + *
>>> + * @NL80211_ATTR_WIPHY_ANTENNA_RX: Bitmap of allowed antennas for receiving.
>>> + * Each bit represents one antenna, starting with antenna 1 at the first
>>> + * bit. If multiple antennas are selected in the bitmap, 802.11n devices
>>> + * should use multiple RX chains on these antennas, while non-802.11n
>>> + * drivers should use antenna diversity between these antennas.
>>
>> What about TX beamforming, and STBC?
> Disabling one antenna/chain on a two-chain device would naturally
> disable TxBF and STBC as well, since it limits the number of available
> chains. The driver should simply act as if the disabled chains didn't exist.
That would work.
>> Unless 802.11n is completely dealt with I really prefer this patch to
>> only address legacy. Otherwise I see sloppyness and inconsistencies on
>> supporting this feature throughout different drivers. I'd like to
>> avoid that at all costs on nl80211. What you are trying to address is
>> legacy antenna setup, not 802.11n RX/TX chainmask dynamic settings so
>> I'd really try to avoid it unless you really want to address all
>> aspects of chain configuration for 802.11n and even then what I'm
>> leading on to say is I think you'll see if you try to address both it
>> just gets messy.
> I think 802.11n is already completely dealt with if you treat this as
> the chainmask on 11n devices.
Its fine by me if the above cases are also embedded into the
documentation, just don't want these questions lingering. I can't
think of other 802.11n special cases.
Luis
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: John W. Linville @ 2010-07-27 16:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <AANLkTi=x7FzdRoC6DxeahvSm+2teN__TsoKjxphOMiPP@mail.gmail.com>
On Tue, Jul 27, 2010 at 09:21:40AM -0700, Luis R. Rodriguez wrote:
> On Tue, Jul 27, 2010 at 9:04 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Tue, Jul 27, 2010 at 08:56:54AM -0700, Luis R. Rodriguez wrote:
> >> On Tue, Jul 27, 2010 at 7:01 AM, John W. Linville
> >> <linville@tuxdriver.com> wrote:
> >> > As for right now, it sounds like you should just use wireless-next-2.6
> >> > instead?
> >>
> >> Oh OK, didn't realize that was bisectable, thanks. Also was unsure if
> >> I'd get other subsystems's -next components. Is wireless-next.git just
> >> the -next bits for 802.11 or does it also suck up net-next?
> >
> > Usually just the wireless bits, but I did just pull the bluetooth stuff
> > (which included some net-next stuff).
>
> Oh neat. OK so which net-next.git release was wireless-next.git based
> on and what net-next.git release was bluetooth-next.git based on? Did
> it bump your next-next.git or do you routinely pull next-next.git into
> your own wireless-next.git?
I don't have those exact commit IDs. How badly do you need them?
I don't normally pull net-next into wireless-next, but this release
not doing that has been a source of pain due to the __packed patch
in net-next and the addition of __attribute__ ((packed)) in various
places in wireless-next. Since Marcel had already based on a net-next
that had that patch and since it is close to the end of the release
I decided it would be acceptable to pull it this time.
I have been considering making regular net-next pulls a standard
practice. That would make my life easier, but would add some
non-wireless instability into wireless-testing (which pulls from
wireless-next). I don't think that would be a big problem _most_
of the time, but I'm sure there would be some occasional pain from
doing that.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-07-27 16:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <AANLkTi=4BtktKxPmFnYwAHaf9Wg-VdLmupcOfXEr1Bpg@mail.gmail.com>
On 2010-07-27 6:19 PM, Luis R. Rodriguez wrote:
>> + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for transmitting.
>> + * Each bit represents one antenna, starting with antenna 1 at the first
>> + * bit. If the bitmap is zero (0), the TX antenna follows RX diversity.
>
> What about for 802.11n? What if you want to disable TX?
Disabling tx shouldn't be handled by the antenna setting, IMHO.
>> + * If multiple antennas are selected all selected antennas have to be used
>> + * for transmitting (801.11n multiple TX chains).
>
> I rather call this TX / RX chainmask then.
Well, for legacy hardware, these aren't really chains, as there is only
one rx and one tx path, just with switching onto multiple antennas.
>> + * Drivers may reject configurations they cannot support.
>> + *
>> + * @NL80211_ATTR_WIPHY_ANTENNA_RX: Bitmap of allowed antennas for receiving.
>> + * Each bit represents one antenna, starting with antenna 1 at the first
>> + * bit. If multiple antennas are selected in the bitmap, 802.11n devices
>> + * should use multiple RX chains on these antennas, while non-802.11n
>> + * drivers should use antenna diversity between these antennas.
>
> What about TX beamforming, and STBC?
Disabling one antenna/chain on a two-chain device would naturally
disable TxBF and STBC as well, since it limits the number of available
chains. The driver should simply act as if the disabled chains didn't exist.
> Unless 802.11n is completely dealt with I really prefer this patch to
> only address legacy. Otherwise I see sloppyness and inconsistencies on
> supporting this feature throughout different drivers. I'd like to
> avoid that at all costs on nl80211. What you are trying to address is
> legacy antenna setup, not 802.11n RX/TX chainmask dynamic settings so
> I'd really try to avoid it unless you really want to address all
> aspects of chain configuration for 802.11n and even then what I'm
> leading on to say is I think you'll see if you try to address both it
> just gets messy.
I think 802.11n is already completely dealt with if you treat this as
the chainmask on 11n devices.
- Felix
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: Luis R. Rodriguez @ 2010-07-27 16:21 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100727160434.GB31694@tuxdriver.com>
On Tue, Jul 27, 2010 at 9:04 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Tue, Jul 27, 2010 at 08:56:54AM -0700, Luis R. Rodriguez wrote:
>> On Tue, Jul 27, 2010 at 7:01 AM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>> > On Mon, Jul 26, 2010 at 08:27:06PM -0700, Luis R. Rodriguez wrote:
>> >> 04:23 * mcgrof is confused, I just did a git bisect -i on
>> >> wireless-testing on some patch on Fri Jul 2 00:09:49 2010 and ended
>> >> up with a 2.6.34 top level
>> >> Makefile
>> >> 04:23 < mcgrof> it was git rebase -i ba17bc5e55ba541d2a8765fca53b6883b667ab21
>> >> 04:23 < mcgrof> eh
>> >> 04:24 < mcgrof> how am I supposed to bisect wl now
>> >> 04:24 < mcgrof> the odd thing though is that the top commit is ancient
>> >> 04:24 < mcgrof> http://paste.pocoo.org/show/242077/
>> >> 04:24 < mcgrof> but the other ones are OK
>> >>
>> >> I realize we should use wireless-2.6.git to bisect stable but I need
>> >> to bisect against recent patches that spans different master- tags
>> >> from you, I figured git bisecting wireless-testing would work now that
>> >> you are using a different method to move your tree forward but am I
>> >> wrong? Should I only bisect between master tags still?
>> >
>> > wireless-testing is a nasty mess when it comes to bisection.
>> > I am considering a one-time rebase of wireless-testing after the
>> > next -rc1, now that the current process is working reasonably well.
>> > wireless-testing will continue to have a messy history, but it should
>> > be a bit less nasty after a rebase.
>> >
>> > As for right now, it sounds like you should just use wireless-next-2.6
>> > instead?
>>
>> Oh OK, didn't realize that was bisectable, thanks. Also was unsure if
>> I'd get other subsystems's -next components. Is wireless-next.git just
>> the -next bits for 802.11 or does it also suck up net-next?
>
> Usually just the wireless bits, but I did just pull the bluetooth stuff
> (which included some net-next stuff).
Oh neat. OK so which net-next.git release was wireless-next.git based
on and what net-next.git release was bluetooth-next.git based on? Did
it bump your next-next.git or do you routinely pull next-next.git into
your own wireless-next.git?
Luis
^ permalink raw reply
* Re: ath9k: /proc/net/wireless always shows status of 0
From: Ben Greear @ 2010-07-27 16:20 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <AANLkTinh7JvGmx0s-A1ZKgGY+2WDPnptqt53=73PRzHD@mail.gmail.com>
On 07/26/2010 11:54 PM, Luis R. Rodriguez wrote:
> On Mon, Jul 26, 2010 at 11:48 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Mon, 2010-07-26 at 16:36 -0700, Ben Greear wrote:
>>
>>>> You can use nl28011 and register for netlink multicast messages which
>>>> broadcast device state changes like the ones you mentioned. These come
>>>> in on iw via event.c, see print_event() and see the case statements
>>>> for NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE,
>>>> NL80211_CMD_DISASSOCIATE, etc, you even get reason codes parsed for
>>>> you too.
>>>
>>> Ahhh, that is the kind of thing I'm looking for. I'll check out that
>>> code in detail tomorrow.
>>
>> Keep in mind though that not all drivers can give you the difference
>> between AUTH and ASSOC, and will ONLY report "CONNECTED" events. This is
>> those drivers that do roaming and all that in firmware rather than in
>> mac80211. Therefore, generally speaking, you cannot get the states
>> you're after.
>
> FWIW I think he's on ath9k.
My real goal is to support lots (128+ hopefully) of
virtual stations on ath5k and ath9k. We had this working
for ath5k in .31 kernel, but too much has changed to make it
a straight-forward upgrade to .34.
As soon as I can get the management logic fixed up (ie, libnl
to listen to wireless events, etc), we should be able to start
on the virtualization work in earnest.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-07-27 16:19 UTC (permalink / raw)
To: Bruno Randolf; +Cc: johannes, linville, linux-wireless
In-Reply-To: <20100727094759.27186.79639.stgit@tt-desk>
On Tue, Jul 27, 2010 at 2:48 AM, Bruno Randolf <br1@einfach.org> wrote:
> Allow setting TX and RX antenna configuration via nl80211.
>
> The antenna configuration is defined as a bitmap of allowed antennas to use for
> either receiving or transmitting. Separate bitmaps are used for RX and TX to
> allow configuring different antennas for receiving and transmitting. The bitmap
> is 8 bit long, each bit representing one antenna, starting with antenna 1.
>
> If multiple receive (RX) antennas are selected, the driver may use diversity or
> multiple 802.11n RX chains, according to the chipset capabilities and
> configuration.
>
> If multiple transmit (TX) antennas are selected, the driver has to send on all
> selected antennas, making this mode of operation only possible on 802.11n
> chipsets with multiple TX chains. If the transmit antenna bitmap is set to the
> special value zero (0) the driver should select the TX antenna based on the
> antenna which was used for receiving (TX antenna follows RX diversity - this is
> the usual mode of 'diversity') for pre 802.11n devices.
>
> Using bitmaps has the benefit of allowing for a flexible configuration
> interface which can support many different configurations. Drivers should
> reject configurations they cannot support. While covering the standard modes
> "fixed antenna 1", "fixed antenna 2" and "diversity" this API also allows more
> rare - but useful - configurations as follows:
>
> 1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
> have a low gain antenna for TX in order to keep within the regulatory
> constraints and a high gain antenna for RX in order to receive weaker signals
> ("speak softly, but listen harder"). This can be useful for building long-shot
> outdoor links. Another usage of this setup is having a low-noise pre-amplifier
> on antenna 1 and a power amplifier on the other antenna. This way transmit
> noise is mostly kept out of the low noise receive channel.
> (This would be bitmaps: tx 1 rx 2).
>
> 2) Another similar setup is: Use RX diversity on both antennas, but always send
> on antenna 1. Again that would allow us to benefit from a higher gain RX
> antenna, while staying within the legal limits.
> (This would be: tx 0 rx 3).
>
> 3) And finally there can be special experimental setups in research and
> development where more than 2 antennas are available. It's good to keep the API
> flexible.
>
> Signed-off-by: Bruno Randolf <br1@einfach.org>
> ---
> include/linux/nl80211.h | 17 +++++++++++++++++
> include/net/cfg80211.h | 3 +++
> net/wireless/nl80211.c | 30 +++++++++++++++++++++++++++++-
> 3 files changed, 49 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index 2c87016..b9de53c 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -731,6 +731,20 @@ enum nl80211_commands {
> * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
> * for non-automatic settings.
> *
> + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for transmitting.
> + * Each bit represents one antenna, starting with antenna 1 at the first
> + * bit. If the bitmap is zero (0), the TX antenna follows RX diversity.
What about for 802.11n? What if you want to disable TX?
> + * If multiple antennas are selected all selected antennas have to be used
> + * for transmitting (801.11n multiple TX chains).
I rather call this TX / RX chainmask then.
> + * Drivers may reject configurations they cannot support.
> + *
> + * @NL80211_ATTR_WIPHY_ANTENNA_RX: Bitmap of allowed antennas for receiving.
> + * Each bit represents one antenna, starting with antenna 1 at the first
> + * bit. If multiple antennas are selected in the bitmap, 802.11n devices
> + * should use multiple RX chains on these antennas, while non-802.11n
> + * drivers should use antenna diversity between these antennas.
What about TX beamforming, and STBC?
Unless 802.11n is completely dealt with I really prefer this patch to
only address legacy. Otherwise I see sloppyness and inconsistencies on
supporting this feature throughout different drivers. I'd like to
avoid that at all costs on nl80211. What you are trying to address is
legacy antenna setup, not 802.11n RX/TX chainmask dynamic settings so
I'd really try to avoid it unless you really want to address all
aspects of chain configuration for 802.11n and even then what I'm
leading on to say is I think you'll see if you try to address both it
just gets messy.
Luis
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: John W. Linville @ 2010-07-27 16:04 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <AANLkTimS2d0jZnu-44+cbFQXvitj_3Rq3egttgOzEiRh@mail.gmail.com>
On Tue, Jul 27, 2010 at 08:56:54AM -0700, Luis R. Rodriguez wrote:
> On Tue, Jul 27, 2010 at 7:01 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Mon, Jul 26, 2010 at 08:27:06PM -0700, Luis R. Rodriguez wrote:
> >> 04:23 * mcgrof is confused, I just did a git bisect -i on
> >> wireless-testing on some patch on Fri Jul 2 00:09:49 2010 and ended
> >> up with a 2.6.34 top level
> >> Makefile
> >> 04:23 < mcgrof> it was git rebase -i ba17bc5e55ba541d2a8765fca53b6883b667ab21
> >> 04:23 < mcgrof> eh
> >> 04:24 < mcgrof> how am I supposed to bisect wl now
> >> 04:24 < mcgrof> the odd thing though is that the top commit is ancient
> >> 04:24 < mcgrof> http://paste.pocoo.org/show/242077/
> >> 04:24 < mcgrof> but the other ones are OK
> >>
> >> I realize we should use wireless-2.6.git to bisect stable but I need
> >> to bisect against recent patches that spans different master- tags
> >> from you, I figured git bisecting wireless-testing would work now that
> >> you are using a different method to move your tree forward but am I
> >> wrong? Should I only bisect between master tags still?
> >
> > wireless-testing is a nasty mess when it comes to bisection.
> > I am considering a one-time rebase of wireless-testing after the
> > next -rc1, now that the current process is working reasonably well.
> > wireless-testing will continue to have a messy history, but it should
> > be a bit less nasty after a rebase.
> >
> > As for right now, it sounds like you should just use wireless-next-2.6
> > instead?
>
> Oh OK, didn't realize that was bisectable, thanks. Also was unsure if
> I'd get other subsystems's -next components. Is wireless-next.git just
> the -next bits for 802.11 or does it also suck up net-next?
Usually just the wireless bits, but I did just pull the bluetooth stuff
(which included some net-next stuff).
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: udevd / ext4 issue mounting 2.6.35-rc5
From: Luis R. Rodriguez @ 2010-07-27 16:03 UTC (permalink / raw)
To: Stefan Bader
Cc: Daniel J Blueman, Rafael J. Wysocki, Ubuntu Kernel Team,
linux-ext4, linux-wireless, linux-kernel
In-Reply-To: <4C4ED26C.5030502@canonical.com>
On Tue, Jul 27, 2010 at 5:34 AM, Stefan Bader
<stefan.bader@canonical.com> wrote:
> On 07/27/2010 01:43 AM, Luis R. Rodriguez wrote:
>> On Fri, Jul 23, 2010 at 10:56 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>> On Fri, Jul 23, 2010 at 9:49 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>>> On Thu, Jul 22, 2010 at 2:10 AM, Daniel J Blueman
>>>> <daniel.blueman@gmail.com> wrote:
>>>>> On 22 July 2010 02:06, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>>>>> On Wed, Jul 21, 2010 at 1:43 AM, Daniel J Blueman
>>>>>> <daniel.blueman@gmail.com> wrote:
>>>>>>> Hi Luis,
>>>>>>>
>>>>>>> On 21 July 2010 01:36, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>>>>>>> I have been reluctant to boot to 2.6.35-rc due to the large set of
>>>>>>>> regression list and the amount of work I needed to actually get done
>>>>>>>> on 2.6.35. Last I checked the regression list it was getting small so
>>>>>>>> I gave it a spin today. No luck. I get some bootup error from udevd
>>>>>>>> and ext2/ext3/ext4, something like this:
>>>>>>>>
>>>>>>>> EXT3-fs (sda1): error: couldn't mount because of unsupported optional
>>>>>>>> features (240)
>>>>>>>> EXT2-fs (sda1): error: couldn't mount because of unsupported optional
>>>>>>>> features (240)
>>>>>>>> EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
>>>>>>>
>>>>>>> This succeeded.
>>>>>>
>>>>>> Heh, OK :)
>>>>>>
>>>>>>>> VFS: Mounted root (ext4 filesystem) readonly on device 8:1
>>>>>>>> Freeing unused kernel memory: 708k freed
>>>>>>>> Write protecting the kernel read-only data: 102040k
>>>>>>>> Freeing unused kernel memory: 764k freed
>>>>>>>> Freeing unused kernel memory: 1796k freed
>>>>>>>> udevd: failed to create queue file: No such file or directory
>>>>>>>> udevd: error creating queue file
>>>>>>>
>>>>>>> It looks like you need to enable:
>>>>>>>
>>>>>>> CONFIG_DEVTMPFS
>>>>>>> CONFIG_DEVTMPFS_MOUNT
>>>>>>
>>>>>> Thanks, it also turned out that when I upgraded from Ubuntu 9.10 to
>>>>>> Ubuntu 10.04 it replaced my own /sbin/installkernel so this was likely
>>>>>> another issue. My /sbin/installkernel changes allow for easy initramfs
>>>>>> installation on Debian/Ubuntu but my patches have been ignored my the
>>>>>> maintainer.
>>>>>>
>>>>>> --- installkernel-ubuntu-10.04 2010-07-21 18:03:34.607678010 -0700
>>>>>> +++ installkernel 2010-01-29 13:17:10.000000000 -0800
>>>>>> @@ -36,7 +36,8 @@
>>>>>> # Create backups of older versions before installing
>>>>>> updatever () {
>>>>>> if [ -f "$dir/$1-$ver" ] ; then
>>>>>> - mv "$dir/$1-$ver" "$dir/$1-$ver.old"
>>>>>> + #mv "$dir/$1-$ver" "$dir/$1-$ver.old"
>>>>>> + rm -f "$dir/$1-$ver" "$dir/$1-$ver.old"
>>>>>> fi
>>>>>>
>>>>>> cat "$2" > "$dir/$1-$ver"
>>>>>> @@ -75,5 +76,16 @@
>>>>>> if [ -f "$config" ] ; then
>>>>>> updatever config "$config"
>>>>>> fi
>>>>>> +
>>>>>> +LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
>>>>>> +
>>>>>> +case $LSB_RED_ID in
>>>>>> +"Ubuntu")
>>>>>> + update-initramfs -c -k $ver
>>>>>> + update-grub
>>>>>> + ;;
>>>>>> +*)
>>>>>> + ;;
>>>>>> +esac
>>>>>>
>>>>>> exit 0
>>>>>>
>>>>>> But anyway I also now get another boot failure with:
>>>>>>
>>>>>> mount: mounting /dev on /root/dev failed: No such file or directory
>>>>>> mount: mounting /sys on /root/sys failed: No such file or directory
>>>>>
>>>>> Hmm...the scripts in the initrd are not doing what is expected -
>>>>> perhaps if you didn't use:
>>>>> linux$ fakeroot make-kpkg --append-to-version -luis1 --initrd kernel-image
>>>>
>>>> I am not using that to build my kernels I just build my kernels with
>>>>
>>>> make
>>>> sudo make modules_install install
>>>>
>>>>> ...or if there are eg initrd script modifications on the filesystem
>>>>> when it cooked the initd.
>>>>
>>>> I haven't modified any initrd scripts.
>>>>
>>>>> You could just try eg:
>>>>> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.35-9-generic_2.6.35-9.14_amd64.deb
>>>
>>> Fun, so that kernel actually works but the one I am building from
>>> wireless-testing.git does not. The curious thing is it doesn't boot
>>> even if I remove my 802.11 module... so something is fishy. This is
>>> likely a config issue. After booting with the above kernel though I
>>> generated a new one with
>>>
>>> make localmodconfig
>>>
>>> and then enabled my 802.11 modules. Still, no luck.. Going to reset my
>>> tree, I had manually merged Linus' latest stuff in but I don't think
>>> this should matter.
>>
>> That didn't work, but it seems this was just my config, the same
>> config worked on older kernels but I am not motivated enough to figure
>> out what I actually did enable which fixed this. But just for the
>> record
>>
>> config which did not work:
>>
>> http://bombadil.infradead.org/~mcgrof/configs/2010/config-issue/config-old.txt
>>
>> config which worked:
>>
>> http://bombadil.infradead.org/~mcgrof/configs/2010/config-issue/config.txt
>>
>> The diff:
>>
>> http://bombadil.infradead.org/~mcgrof/configs/2010/config-issue/diff-34-35.patch
>>
>> Luis
>>
>
> Hm, I hope I did not miss some info in the threads above, but have you tried to
> use the config in /boot/ as a base for your new config with make oldconfig?
Yeah, that's how I started my own configs for 2.6.34, then I always
use make localmodconfig to trim crap down. In this case my config just
stopped working on newer kernels. What cured it was I took Daniel J
Blueman's 2.6.35 ubuntu package:
http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.35-9-generic_2.6.35-9.14_amd64.deb
Then stole that config and used it as a starting reference, then did
the localmodconfig after booting into it and cp'ing that config to my
own and running oldconfig.
> I think to remember make modules_install purges all existing modules under
> kernel before installing the new ones. So likely there is something essential
> going away when rebuilding the initrd. The messages sound like basic root fs is
> not there, so it misses all the mount points. But I admit to be too lazy to walk
> all the config.
Right, I thought it was the rootfs, the rootfs is provided through the
tmpfs filesystem which both configs have. They also have devftmpfs.
This is why I started to suspect something on the distribution side
but low and behold linux-image-2.6.35-9-generic_2.6.35-9.14_amd64.deb
worked well.
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
Good news is its working now but certainly my old config did not work anymore.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v3] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-07-27 15:57 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Matthew Garrett, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, David Quan, Luis R. Rodriguez,
linux-kernel, kernel-team@lists.ubuntu.com, Luis Rodriguez,
Jussi Kivilinna, tim.gardner@canonical.com
In-Reply-To: <1280223313.3721.83.camel@maxim-laptop>
On Tue, Jul 27, 2010 at 2:35 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Mon, 2010-07-26 at 23:50 +0100, Matthew Garrett wrote:
>> On Mon, Jul 26, 2010 at 03:43:04PM -0700, Luis R. Rodriguez wrote:
>>
>> > I see.. thanks Mathew... in that case since L1 works on all devices we
>> > could just force enable L1 for all PCIE devices. What do you think?
>>
>> Works for me.
>>
>
> On the second thought, there is no 'pci_enable_link_state' :-)
> I afraid that if I add it, I might not do that right for all cases, thus
> do more harm that good...
I'm sorry, can you elaborate?
Luis
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: Luis R. Rodriguez @ 2010-07-27 15:56 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100727140139.GA31694@tuxdriver.com>
On Tue, Jul 27, 2010 at 7:01 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Mon, Jul 26, 2010 at 08:27:06PM -0700, Luis R. Rodriguez wrote:
>> 04:23 * mcgrof is confused, I just did a git bisect -i on
>> wireless-testing on some patch on Fri Jul 2 00:09:49 2010 and ended
>> up with a 2.6.34 top level
>> Makefile
>> 04:23 < mcgrof> it was git rebase -i ba17bc5e55ba541d2a8765fca53b6883b667ab21
>> 04:23 < mcgrof> eh
>> 04:24 < mcgrof> how am I supposed to bisect wl now
>> 04:24 < mcgrof> the odd thing though is that the top commit is ancient
>> 04:24 < mcgrof> http://paste.pocoo.org/show/242077/
>> 04:24 < mcgrof> but the other ones are OK
>>
>> I realize we should use wireless-2.6.git to bisect stable but I need
>> to bisect against recent patches that spans different master- tags
>> from you, I figured git bisecting wireless-testing would work now that
>> you are using a different method to move your tree forward but am I
>> wrong? Should I only bisect between master tags still?
>
> wireless-testing is a nasty mess when it comes to bisection.
> I am considering a one-time rebase of wireless-testing after the
> next -rc1, now that the current process is working reasonably well.
> wireless-testing will continue to have a messy history, but it should
> be a bit less nasty after a rebase.
>
> As for right now, it sounds like you should just use wireless-next-2.6
> instead?
Oh OK, didn't realize that was bisectable, thanks. Also was unsure if
I'd get other subsystems's -next components. Is wireless-next.git just
the -next bits for 802.11 or does it also suck up net-next?
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: fix sw scan bracketing
From: Luis R. Rodriguez @ 2010-07-27 15:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1280226169.19098.12.camel@jlt3.sipsolutions.net>
On Tue, Jul 27, 2010 at 3:22 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-07-27 at 02:22 -0700, Luis R. Rodriguez wrote:
>
>> > Yeap, reverting this patch alone today on wireless-testing makes me
>> > ath9k happy once again.
>>
>> So after some though and review in order to fix this we need a little
>> more time and thought. The above patch changes the order in which we
>> configure hardware upon a scan complete. It used to be we would
>> configure the hardware, configure the filter and then scan complete.
>> By then we'd be on the home channel and the filters would be set
>> correctly. ath9k's scan complete routine does a few things which
>> depend on the channel and will make hardware poo otherwise or do
>> stupid things:
>>
>> * start TX poll routine, due to the new latency introduced to
>> configure hardware and configure the RX filter the TX polll routine
>> now has some extra work done by hardware before it actually starts
>> TXing. I don't suspect this could introduce a huge regression but it
>> is worth noting.
>
> I don't even understand why this is stopped during scan?
Good question, perhaps some scans take too long and you don't TX at
all on some set of passive channels? Its the only thing I can think
of.
>> * ANI gets started, and the wrong channel is used if we're not yet
>> on the home channel. A simple patch to test if this may be causing the
>> disconnect issue I am seeing I just tried was to increase the delay
>> before starting ANI, this did indeed help.
>
> This really should be done when the channel is configured after scan
> anyway.
Indeed, I really prefer to do so on a new development kernel series,
think its too late in the series now.
>> * ath_beacon_config() which I suspect means that if we now scan in
>> AP mode/IBSS mode we could potentially be leaking beacons on the last
>> channel of a scan, prior to sending them on the actual desired home
>> channel.
>
> This should be done by the driver based on mac80211's indication of
> whether it should be beaconing or not, not based on the scan callbacks.
Yeah, this is odd, I'll check with our team to see how we came up with
this here.
> I'm starting to think that it was a mistake to add these callbacks to
> start with ...
Could be.
>> To address and review all this I need more time and instead I think
>> its easier to ask for revert of this patch.
>
> I'm OK with a revert, but *ONLY* if at the same time you remove the
> double-scan-detected message from ath9k and stop claiming it's a
> mac80211 bug :-)
Deal :)
Luis
^ permalink raw reply
* [PATCH w-t 3/3] rt2500usb: disallow to set WEP key with non zero index
From: Stanislaw Gruszka @ 2010-07-27 14:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Ivo van Doorn, sgruszka, Gertjan van Wingerde
In-Reply-To: <20100727144804.6012.94740.send-patch@dhcp-lab-109.englab.brq.redhat.com>
On our hardware (050d:7050 Belkin Components F5D7050 Wireless G Adapter),
setting any WEP key with non zero index, cause rx frames corruption.
Note: perhaps (I did not check) this can be fixed differently - by using
hw_key_idx the same as true MAC key index. But according to the comment in
rt2x00mac_set_key():
"the hardware requires keys to be assigned in correct order (When key 1
is provided but key 0 is not, then the key is not found by the hardware
during RX)"
this will be quite problematic. Since WEP should not be used, disabling
hardware crypto offload for it will not hurt much. Beside static
one key WEP will still be offloaded.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/rt2x00/rt2500usb.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 3028abb..bf059cd 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -351,6 +351,14 @@ static int rt2500usb_config_key(struct rt2x00_dev *rt2x00dev,
if (crypto->cmd == SET_KEY) {
/*
+ * Disallow to set WEP key other than with index 0,
+ * it is known that not work at least on some hardware.
+ * SW crypto will be used in that case.
+ */
+ if (key->alg == ALG_WEP && key->keyidx != 0)
+ return -EOPNOTSUPP;
+
+ /*
* Pairwise key will always be entry 0, but this
* could collide with a shared key on the same
* position...
--
1.7.1
^ permalink raw reply related
* [PATCH w-t 2/3] rt2500usb: truly disable encryption when initialize
From: Stanislaw Gruszka @ 2010-07-27 14:48 UTC (permalink / raw)
To: linux-wireless; +Cc: sgruszka, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <20100727144804.6012.94740.send-patch@dhcp-lab-109.englab.brq.redhat.com>
Without cipher part nullify of TXRX_CSR0 register we can receive
corrupted frames (removed IV or IVC), after reloading rt2500usb module
with nohwcrypt=1 option, if previous some keys were configured into
the hardware.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/rt2x00/rt2500usb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 7892647..3028abb 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -813,6 +813,7 @@ static int rt2500usb_init_registers(struct rt2x00_dev *rt2x00dev)
rt2500usb_register_write(rt2x00dev, MAC_CSR8, reg);
rt2500usb_register_read(rt2x00dev, TXRX_CSR0, ®);
+ rt2x00_set_field16(®, TXRX_CSR0_ALGORITHM, CIPHER_NONE);
rt2x00_set_field16(®, TXRX_CSR0_IV_OFFSET, IEEE80211_HEADER);
rt2x00_set_field16(®, TXRX_CSR0_KEY_ID, 0);
rt2500usb_register_write(rt2x00dev, TXRX_CSR0, reg);
--
1.7.1
^ permalink raw reply related
* [PATCH w-t 1/3] rt2500usb: write keys to proper registers
From: Stanislaw Gruszka @ 2010-07-27 14:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Ivo van Doorn, sgruszka, Gertjan van Wingerde
Fix rt2500usb hardware encryption broken by commit
96b61bafe22b2f2abcc833d651739edb977f1b1e
"rt2x00: Clean up USB vendor request buffer functions"
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 4b2fef3..7892647 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -376,7 +376,7 @@ static int rt2500usb_config_key(struct rt2x00_dev *rt2x00dev,
if (key->hw_key_idx > 0 && crypto->cipher != curr_cipher)
return -EOPNOTSUPP;
- rt2500usb_register_multiwrite(rt2x00dev, reg,
+ rt2500usb_register_multiwrite(rt2x00dev, KEY_ENTRY(key->hw_key_idx),
crypto->key, sizeof(crypto->key));
/*
--
1.7.1
^ permalink raw reply related
* RE: Intel Wireless: Microcode SW error detected.
From: Guy, Wey-Yi W @ 2010-07-27 14:40 UTC (permalink / raw)
To: Malthe Borch, linux-wireless@vger.kernel.org, Sternberg, Jay E
In-Reply-To: <AANLkTimrv507n5-WmikUOhPE95wM1p1_Qtd65rOA1hei@mail.gmail.com>
QWRkIEpheSB0byB0aGUgdGhyZWFkLA0KDQpKYXksIGNvdWxkIHlvdSBoZWxwIHRvIHRha2UgYSBs
b29rIGF0IGl0LiBUaGFua3MNCg0KV2V5LVlpIEd1eQ0KSW50ZWwgQ29ycG9yYXRpb24NCjIxMTEg
Ti5FLiAyNXRoIEF2ZW51ZSAgTS9TIEpGMy0zMDggICAgICAgICAgICAgICAgIA0KSGlsbHNib3Jv
IE9SIDk3MTI0LTU5NjENClVTQQ0KV29yayBQaG9uZTogNTAzLTI2NC02MDIzIChPUikNCkNlbGwg
UGhvbmU6IDUwMy0zMjktODQxMA0KRW1haWw6IHdleS15aS53Lmd1eUBpbnRlbC5jb20NCiANCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxpbnV4LXdpcmVsZXNzLW93bmVyQHZn
ZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LXdpcmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9y
Z10gT24gQmVoYWxmIE9mIE1hbHRoZSBCb3JjaA0KU2VudDogTW9uZGF5LCBKdWx5IDI2LCAyMDEw
IDI6MTkgUE0NClRvOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmcNClN1YmplY3Q6IElu
dGVsIFdpcmVsZXNzOiBNaWNyb2NvZGUgU1cgZXJyb3IgZGV0ZWN0ZWQuDQoNCkkgZ2V0IHRoaXMg
d2l0aCB0aGUgbGF0ZXN0IGFuZCBncmVhdGVzdCBJbnRlbCBmaXJtd2FyZSA5LjIyMS40LjEgYnVp
bGQgMjU1MzIuDQoNClVsdGltYXRlbHkgZW5hYmxpbmcgdGhlIGRldmljZSBmYWlscyB3aXRoOiAi
dUNvZGUgZGlkIG5vdCByZXNwb25kIE9LLiINCg==
^ permalink raw reply
* Re: Confused - bisecting wireless-testing
From: John W. Linville @ 2010-07-27 14:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <AANLkTim-0qoS7o+fcQ6uA18AC_gQSiiDe4Tv_L1FT1Ae@mail.gmail.com>
On Mon, Jul 26, 2010 at 08:27:06PM -0700, Luis R. Rodriguez wrote:
> 04:23 * mcgrof is confused, I just did a git bisect -i on
> wireless-testing on some patch on Fri Jul 2 00:09:49 2010 and ended
> up with a 2.6.34 top level
> Makefile
> 04:23 < mcgrof> it was git rebase -i ba17bc5e55ba541d2a8765fca53b6883b667ab21
> 04:23 < mcgrof> eh
> 04:24 < mcgrof> how am I supposed to bisect wl now
> 04:24 < mcgrof> the odd thing though is that the top commit is ancient
> 04:24 < mcgrof> http://paste.pocoo.org/show/242077/
> 04:24 < mcgrof> but the other ones are OK
>
> I realize we should use wireless-2.6.git to bisect stable but I need
> to bisect against recent patches that spans different master- tags
> from you, I figured git bisecting wireless-testing would work now that
> you are using a different method to move your tree forward but am I
> wrong? Should I only bisect between master tags still?
wireless-testing is a nasty mess when it comes to bisection.
I am considering a one-time rebase of wireless-testing after the
next -rc1, now that the current process is working reasonably well.
wireless-testing will continue to have a messy history, but it should
be a bit less nasty after a rebase.
As for right now, it sounds like you should just use wireless-next-2.6
instead?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 4/4] ath9k: remove unused base_index from rate table.
From: Senthil Balasubramanian @ 2010-07-27 13:46 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Senthil Balasubramanian
In-Reply-To: <1280238394-2565-1-git-send-email-senthilkumar@atheros.com>
base index is not used anymore and so remove it.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
---
drivers/net/wireless/ath/ath9k/rc.c | 320 +++++++++++++++++-----------------
drivers/net/wireless/ath/ath9k/rc.h | 1 -
2 files changed, 160 insertions(+), 161 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 5c9df3b..e49be73 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -24,141 +24,141 @@ static const struct ath_rate_table ar5416_11na_ratetable = {
8, /* MCS start */
{
[0] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 6000,
- 5400, 0, 12, 0, 0, 0, 0, 0 }, /* 6 Mb */
+ 5400, 0, 12, 0, 0, 0, 0 }, /* 6 Mb */
[1] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 9000,
- 7800, 1, 18, 0, 1, 1, 1, 1 }, /* 9 Mb */
+ 7800, 1, 18, 0, 1, 1, 1 }, /* 9 Mb */
[2] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 12000,
- 10000, 2, 24, 2, 2, 2, 2, 2 }, /* 12 Mb */
+ 10000, 2, 24, 2, 2, 2, 2 }, /* 12 Mb */
[3] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 18000,
- 13900, 3, 36, 2, 3, 3, 3, 3 }, /* 18 Mb */
+ 13900, 3, 36, 2, 3, 3, 3 }, /* 18 Mb */
[4] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 24000,
- 17300, 4, 48, 4, 4, 4, 4, 4 }, /* 24 Mb */
+ 17300, 4, 48, 4, 4, 4, 4 }, /* 24 Mb */
[5] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 36000,
- 23000, 5, 72, 4, 5, 5, 5, 5 }, /* 36 Mb */
+ 23000, 5, 72, 4, 5, 5, 5 }, /* 36 Mb */
[6] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 48000,
- 27400, 6, 96, 4, 6, 6, 6, 6 }, /* 48 Mb */
+ 27400, 6, 96, 4, 6, 6, 6 }, /* 48 Mb */
[7] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 54000,
- 29300, 7, 108, 4, 7, 7, 7, 7 }, /* 54 Mb */
+ 29300, 7, 108, 4, 7, 7, 7 }, /* 54 Mb */
[8] = { RC_HT_SDT_2040, WLAN_RC_PHY_HT_20_SS, 6500,
- 6400, 0, 0, 0, 8, 38, 8, 38 }, /* 6.5 Mb */
+ 6400, 0, 0, 0, 38, 8, 38 }, /* 6.5 Mb */
[9] = { RC_HT_SDT_20, WLAN_RC_PHY_HT_20_SS, 13000,
- 12700, 1, 1, 2, 9, 39, 9, 39 }, /* 13 Mb */
+ 12700, 1, 1, 2, 39, 9, 39 }, /* 13 Mb */
[10] = { RC_HT_SDT_20, WLAN_RC_PHY_HT_20_SS, 19500,
- 18800, 2, 2, 2, 10, 40, 10, 40 }, /* 19.5 Mb */
+ 18800, 2, 2, 2, 40, 10, 40 }, /* 19.5 Mb */
[11] = { RC_HT_SD_20, WLAN_RC_PHY_HT_20_SS, 26000,
- 25000, 3, 3, 4, 11, 41, 11, 41 }, /* 26 Mb */
+ 25000, 3, 3, 4, 41, 11, 41 }, /* 26 Mb */
[12] = { RC_HT_SD_20, WLAN_RC_PHY_HT_20_SS, 39000,
- 36700, 4, 4, 4, 12, 42, 12, 42 }, /* 39 Mb */
+ 36700, 4, 4, 4, 42, 12, 42 }, /* 39 Mb */
[13] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS, 52000,
- 48100, 5, 5, 4, 13, 43, 13, 43 }, /* 52 Mb */
+ 48100, 5, 5, 4, 43, 13, 43 }, /* 52 Mb */
[14] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS, 58500,
- 53500, 6, 6, 4, 14, 44, 14, 44 }, /* 58.5 Mb */
+ 53500, 6, 6, 4, 44, 14, 44 }, /* 58.5 Mb */
[15] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS, 65000,
- 59000, 7, 7, 4, 15, 45, 16, 46 }, /* 65 Mb */
+ 59000, 7, 7, 4, 45, 16, 46 }, /* 65 Mb */
[16] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS_HGI, 72200,
- 65400, 7, 7, 4, 15, 45, 16, 46 }, /* 75 Mb */
+ 65400, 7, 7, 4, 45, 16, 46 }, /* 75 Mb */
[17] = { RC_INVALID, WLAN_RC_PHY_HT_20_DS, 13000,
- 12700, 8, 8, 0, 16, 47, 17, 47 }, /* 13 Mb */
+ 12700, 8, 8, 0, 47, 17, 47 }, /* 13 Mb */
[18] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_DS, 26000,
- 24800, 9, 9, 2, 17, 48, 18, 48 }, /* 26 Mb */
+ 24800, 9, 9, 2, 48, 18, 48 }, /* 26 Mb */
[19] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_DS, 39000,
- 36600, 10, 10, 2, 18, 49, 19, 49 }, /* 39 Mb */
+ 36600, 10, 10, 2, 49, 19, 49 }, /* 39 Mb */
[20] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 52000,
- 48100, 11, 11, 4, 19, 50, 20, 50 }, /* 52 Mb */
+ 48100, 11, 11, 4, 50, 20, 50 }, /* 52 Mb */
[21] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 78000,
- 69500, 12, 12, 4, 20, 51, 21, 51 }, /* 78 Mb */
+ 69500, 12, 12, 4, 51, 21, 51 }, /* 78 Mb */
[22] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 104000,
- 89500, 13, 13, 4, 21, 52, 22, 52 }, /* 104 Mb */
+ 89500, 13, 13, 4, 52, 22, 52 }, /* 104 Mb */
[23] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 117000,
- 98900, 14, 14, 4, 22, 53, 23, 53 }, /* 117 Mb */
+ 98900, 14, 14, 4, 53, 23, 53 }, /* 117 Mb */
[24] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 130000,
- 108300, 15, 15, 4, 23, 54, 25, 55 }, /* 130 Mb */
+ 108300, 15, 15, 4, 54, 25, 55 }, /* 130 Mb */
[25] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS_HGI, 144400,
- 120000, 15, 15, 4, 23, 54, 25, 55 }, /* 144.4 Mb */
+ 120000, 15, 15, 4, 54, 25, 55 }, /* 144.4 Mb */
[26] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 19500,
- 17400, 16, 16, 0, 24, 56, 26, 56 }, /* 19.5 Mb */
+ 17400, 16, 16, 0, 56, 26, 56 }, /* 19.5 Mb */
[27] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 39000,
- 35100, 17, 17, 2, 25, 57, 27, 57 }, /* 39 Mb */
+ 35100, 17, 17, 2, 57, 27, 57 }, /* 39 Mb */
[28] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 58500,
- 52600, 18, 18, 2, 26, 58, 28, 58 }, /* 58.5 Mb */
+ 52600, 18, 18, 2, 58, 28, 58 }, /* 58.5 Mb */
[29] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 78000,
- 70400, 19, 19, 4, 27, 59, 29, 59 }, /* 78 Mb */
+ 70400, 19, 19, 4, 59, 29, 59 }, /* 78 Mb */
[30] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 117000,
- 104900, 20, 20, 4, 28, 60, 31, 61 }, /* 117 Mb */
+ 104900, 20, 20, 4, 60, 31, 61 }, /* 117 Mb */
[31] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS_HGI, 130000,
- 115800, 20, 20, 4, 28, 60, 31, 61 }, /* 130 Mb*/
+ 115800, 20, 20, 4, 60, 31, 61 }, /* 130 Mb*/
[32] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS, 156000,
- 137200, 21, 21, 4, 29, 62, 33, 63 }, /* 156 Mb */
+ 137200, 21, 21, 4, 62, 33, 63 }, /* 156 Mb */
[33] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS_HGI, 173300,
- 151100, 21, 21, 4, 29, 62, 33, 63 }, /* 173.3 Mb */
+ 151100, 21, 21, 4, 62, 33, 63 }, /* 173.3 Mb */
[34] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS, 175500,
- 152800, 22, 22, 4, 30, 64, 35, 65 }, /* 175.5 Mb */
+ 152800, 22, 22, 4, 64, 35, 65 }, /* 175.5 Mb */
[35] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS_HGI, 195000,
- 168400, 22, 22, 4, 30, 64, 35, 65 }, /* 195 Mb*/
+ 168400, 22, 22, 4, 64, 35, 65 }, /* 195 Mb*/
[36] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS, 195000,
- 168400, 23, 23, 4, 31, 66, 37, 67 }, /* 195 Mb */
+ 168400, 23, 23, 4, 66, 37, 67 }, /* 195 Mb */
[37] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS_HGI, 216700,
- 185000, 23, 23, 4, 31, 66, 37, 67 }, /* 216.7 Mb */
+ 185000, 23, 23, 4, 66, 37, 67 }, /* 216.7 Mb */
[38] = { RC_HT_SDT_40, WLAN_RC_PHY_HT_40_SS, 13500,
- 13200, 0, 0, 0, 8, 38, 38, 38 }, /* 13.5 Mb*/
+ 13200, 0, 0, 0, 38, 38, 38 }, /* 13.5 Mb*/
[39] = { RC_HT_SDT_40, WLAN_RC_PHY_HT_40_SS, 27500,
- 25900, 1, 1, 2, 9, 39, 39, 39 }, /* 27.0 Mb*/
+ 25900, 1, 1, 2, 39, 39, 39 }, /* 27.0 Mb*/
[40] = { RC_HT_SDT_40, WLAN_RC_PHY_HT_40_SS, 40500,
- 38600, 2, 2, 2, 10, 40, 40, 40 }, /* 40.5 Mb*/
+ 38600, 2, 2, 2, 40, 40, 40 }, /* 40.5 Mb*/
[41] = { RC_HT_SD_40, WLAN_RC_PHY_HT_40_SS, 54000,
- 49800, 3, 3, 4, 11, 41, 41, 41 }, /* 54 Mb */
+ 49800, 3, 3, 4, 41, 41, 41 }, /* 54 Mb */
[42] = { RC_HT_SD_40, WLAN_RC_PHY_HT_40_SS, 81500,
- 72200, 4, 4, 4, 12, 42, 42, 42 }, /* 81 Mb */
+ 72200, 4, 4, 4, 42, 42, 42 }, /* 81 Mb */
[43] = { RC_HT_S_40, WLAN_RC_PHY_HT_40_SS, 108000,
- 92900, 5, 5, 4, 13, 43, 43, 43 }, /* 108 Mb */
+ 92900, 5, 5, 4, 43, 43, 43 }, /* 108 Mb */
[44] = { RC_HT_S_40, WLAN_RC_PHY_HT_40_SS, 121500,
- 102700, 6, 6, 4, 14, 44, 44, 44 }, /* 121.5 Mb*/
+ 102700, 6, 6, 4, 44, 44, 44 }, /* 121.5 Mb*/
[45] = { RC_HT_S_40, WLAN_RC_PHY_HT_40_SS, 135000,
- 112000, 7, 7, 4, 15, 45, 46, 46 }, /* 135 Mb */
+ 112000, 7, 7, 4, 45, 46, 46 }, /* 135 Mb */
[46] = { RC_HT_S_40, WLAN_RC_PHY_HT_40_SS_HGI, 150000,
- 122000, 7, 7, 4, 15, 45, 46, 46 }, /* 150 Mb */
+ 122000, 7, 7, 4, 45, 46, 46 }, /* 150 Mb */
[47] = { RC_INVALID, WLAN_RC_PHY_HT_40_DS, 27000,
- 25800, 8, 8, 0, 16, 47, 47, 47 }, /* 27 Mb */
+ 25800, 8, 8, 0, 47, 47, 47 }, /* 27 Mb */
[48] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_DS, 54000,
- 49800, 9, 9, 2, 17, 48, 48, 48 }, /* 54 Mb */
+ 49800, 9, 9, 2, 48, 48, 48 }, /* 54 Mb */
[49] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_DS, 81000,
- 71900, 10, 10, 2, 18, 49, 49, 49 }, /* 81 Mb */
+ 71900, 10, 10, 2, 49, 49, 49 }, /* 81 Mb */
[50] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 108000,
- 92500, 11, 11, 4, 19, 50, 50, 50 }, /* 108 Mb */
+ 92500, 11, 11, 4, 50, 50, 50 }, /* 108 Mb */
[51] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 162000,
- 130300, 12, 12, 4, 20, 51, 51, 51 }, /* 162 Mb */
+ 130300, 12, 12, 4, 51, 51, 51 }, /* 162 Mb */
[52] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 216000,
- 162800, 13, 13, 4, 21, 52, 52, 52 }, /* 216 Mb */
+ 162800, 13, 13, 4, 52, 52, 52 }, /* 216 Mb */
[53] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 243000,
- 178200, 14, 14, 4, 22, 53, 53, 53 }, /* 243 Mb */
+ 178200, 14, 14, 4, 53, 53, 53 }, /* 243 Mb */
[54] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 270000,
- 192100, 15, 15, 4, 23, 54, 55, 55 }, /* 270 Mb */
+ 192100, 15, 15, 4, 54, 55, 55 }, /* 270 Mb */
[55] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS_HGI, 300000,
- 207000, 15, 15, 4, 23, 54, 55, 55 }, /* 300 Mb */
+ 207000, 15, 15, 4, 54, 55, 55 }, /* 300 Mb */
[56] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 40500,
- 36100, 16, 16, 0, 24, 56, 56, 56 }, /* 40.5 Mb */
+ 36100, 16, 16, 0, 56, 56, 56 }, /* 40.5 Mb */
[57] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 81000,
- 72900, 17, 17, 2, 25, 57, 57, 57 }, /* 81 Mb */
+ 72900, 17, 17, 2, 57, 57, 57 }, /* 81 Mb */
[58] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 121500,
- 108300, 18, 18, 2, 26, 58, 58, 58 }, /* 121.5 Mb */
+ 108300, 18, 18, 2, 58, 58, 58 }, /* 121.5 Mb */
[59] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 162000,
- 142000, 19, 19, 4, 27, 59, 59, 59 }, /* 162 Mb */
+ 142000, 19, 19, 4, 59, 59, 59 }, /* 162 Mb */
[60] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 243000,
- 205100, 20, 20, 4, 28, 60, 61, 61 }, /* 243 Mb */
+ 205100, 20, 20, 4, 60, 61, 61 }, /* 243 Mb */
[61] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS_HGI, 270000,
- 224700, 20, 20, 4, 28, 60, 61, 61 }, /* 270 Mb */
+ 224700, 20, 20, 4, 60, 61, 61 }, /* 270 Mb */
[62] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS, 324000,
- 263100, 21, 21, 4, 29, 62, 63, 63 }, /* 324 Mb */
+ 263100, 21, 21, 4, 62, 63, 63 }, /* 324 Mb */
[63] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 360000,
- 288000, 21, 21, 4, 29, 62, 63, 63 }, /* 360 Mb */
+ 288000, 21, 21, 4, 62, 63, 63 }, /* 360 Mb */
[64] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS, 364500,
- 290700, 22, 22, 4, 30, 64, 65, 65 }, /* 364.5 Mb */
+ 290700, 22, 22, 4, 64, 65, 65 }, /* 364.5 Mb */
[65] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 405000,
- 317200, 22, 22, 4, 30, 64, 65, 65 }, /* 405 Mb */
+ 317200, 22, 22, 4, 64, 65, 65 }, /* 405 Mb */
[66] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS, 405000,
- 317200, 23, 23, 4, 31, 66, 67, 67 }, /* 405 Mb */
+ 317200, 23, 23, 4, 66, 67, 67 }, /* 405 Mb */
[67] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 450000,
- 346400, 23, 23, 4, 31, 66, 67, 67 }, /* 450 Mb */
+ 346400, 23, 23, 4, 66, 67, 67 }, /* 450 Mb */
},
50, /* probe interval */
WLAN_RC_HT_FLAG, /* Phy rates allowed initially */
@@ -172,149 +172,149 @@ static const struct ath_rate_table ar5416_11ng_ratetable = {
12, /* MCS start */
{
[0] = { RC_ALL, WLAN_RC_PHY_CCK, 1000,
- 900, 0, 2, 0, 0, 0, 0, 0 }, /* 1 Mb */
+ 900, 0, 2, 0, 0, 0, 0 }, /* 1 Mb */
[1] = { RC_ALL, WLAN_RC_PHY_CCK, 2000,
- 1900, 1, 4, 1, 1, 1, 1, 1 }, /* 2 Mb */
+ 1900, 1, 4, 1, 1, 1, 1 }, /* 2 Mb */
[2] = { RC_ALL, WLAN_RC_PHY_CCK, 5500,
- 4900, 2, 11, 2, 2, 2, 2, 2 }, /* 5.5 Mb */
+ 4900, 2, 11, 2, 2, 2, 2 }, /* 5.5 Mb */
[3] = { RC_ALL, WLAN_RC_PHY_CCK, 11000,
- 8100, 3, 22, 3, 3, 3, 3, 3 }, /* 11 Mb */
+ 8100, 3, 22, 3, 3, 3, 3 }, /* 11 Mb */
[4] = { RC_INVALID, WLAN_RC_PHY_OFDM, 6000,
- 5400, 4, 12, 4, 4, 4, 4, 4 }, /* 6 Mb */
+ 5400, 4, 12, 4, 4, 4, 4 }, /* 6 Mb */
[5] = { RC_INVALID, WLAN_RC_PHY_OFDM, 9000,
- 7800, 5, 18, 4, 5, 5, 5, 5 }, /* 9 Mb */
+ 7800, 5, 18, 4, 5, 5, 5 }, /* 9 Mb */
[6] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 12000,
- 10100, 6, 24, 6, 6, 6, 6, 6 }, /* 12 Mb */
+ 10100, 6, 24, 6, 6, 6, 6 }, /* 12 Mb */
[7] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 18000,
- 14100, 7, 36, 6, 7, 7, 7, 7 }, /* 18 Mb */
+ 14100, 7, 36, 6, 7, 7, 7 }, /* 18 Mb */
[8] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 24000,
- 17700, 8, 48, 8, 8, 8, 8, 8 }, /* 24 Mb */
+ 17700, 8, 48, 8, 8, 8, 8 }, /* 24 Mb */
[9] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 36000,
- 23700, 9, 72, 8, 9, 9, 9, 9 }, /* 36 Mb */
+ 23700, 9, 72, 8, 9, 9, 9 }, /* 36 Mb */
[10] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 48000,
- 27400, 10, 96, 8, 10, 10, 10, 10 }, /* 48 Mb */
+ 27400, 10, 96, 8, 10, 10, 10 }, /* 48 Mb */
[11] = { RC_L_SDT, WLAN_RC_PHY_OFDM, 54000,
- 30900, 11, 108, 8, 11, 11, 11, 11 }, /* 54 Mb */
+ 30900, 11, 108, 8, 11, 11, 11 }, /* 54 Mb */
[12] = { RC_INVALID, WLAN_RC_PHY_HT_20_SS, 6500,
- 6400, 0, 0, 4, 12, 42, 12, 42 }, /* 6.5 Mb */
+ 6400, 0, 0, 4, 42, 12, 42 }, /* 6.5 Mb */
[13] = { RC_HT_SDT_20, WLAN_RC_PHY_HT_20_SS, 13000,
- 12700, 1, 1, 6, 13, 43, 13, 43 }, /* 13 Mb */
+ 12700, 1, 1, 6, 43, 13, 43 }, /* 13 Mb */
[14] = { RC_HT_SDT_20, WLAN_RC_PHY_HT_20_SS, 19500,
- 18800, 2, 2, 6, 14, 44, 14, 44 }, /* 19.5 Mb*/
+ 18800, 2, 2, 6, 44, 14, 44 }, /* 19.5 Mb*/
[15] = { RC_HT_SD_20, WLAN_RC_PHY_HT_20_SS, 26000,
- 25000, 3, 3, 8, 15, 45, 15, 45 }, /* 26 Mb */
+ 25000, 3, 3, 8, 45, 15, 45 }, /* 26 Mb */
[16] = { RC_HT_SD_20, WLAN_RC_PHY_HT_20_SS, 39000,
- 36700, 4, 4, 8, 16, 46, 16, 46 }, /* 39 Mb */
+ 36700, 4, 4, 8, 46, 16, 46 }, /* 39 Mb */
[17] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS, 52000,
- 48100, 5, 5, 8, 17, 47, 17, 47 }, /* 52 Mb */
+ 48100, 5, 5, 8, 47, 17, 47 }, /* 52 Mb */
[18] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS, 58500,
- 53500, 6, 6, 8, 18, 48, 18, 48 }, /* 58.5 Mb */
+ 53500, 6, 6, 8, 48, 18, 48 }, /* 58.5 Mb */
[19] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS, 65000,
- 59000, 7, 7, 8, 19, 49, 20, 50 }, /* 65 Mb */
+ 59000, 7, 7, 8, 49, 20, 50 }, /* 65 Mb */
[20] = { RC_HT_S_20, WLAN_RC_PHY_HT_20_SS_HGI, 72200,
- 65400, 7, 7, 8, 19, 49, 20, 50 }, /* 65 Mb*/
+ 65400, 7, 7, 8, 49, 20, 50 }, /* 65 Mb*/
[21] = { RC_INVALID, WLAN_RC_PHY_HT_20_DS, 13000,
- 12700, 8, 8, 4, 20, 51, 21, 51 }, /* 13 Mb */
+ 12700, 8, 8, 4, 51, 21, 51 }, /* 13 Mb */
[22] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_DS, 26000,
- 24800, 9, 9, 6, 21, 52, 22, 52 }, /* 26 Mb */
+ 24800, 9, 9, 6, 52, 22, 52 }, /* 26 Mb */
[23] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_DS, 39000,
- 36600, 10, 10, 6, 22, 53, 23, 53 }, /* 39 Mb */
+ 36600, 10, 10, 6, 53, 23, 53 }, /* 39 Mb */
[24] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 52000,
- 48100, 11, 11, 8, 23, 54, 24, 54 }, /* 52 Mb */
+ 48100, 11, 11, 8, 54, 24, 54 }, /* 52 Mb */
[25] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 78000,
- 69500, 12, 12, 8, 24, 55, 25, 55 }, /* 78 Mb */
+ 69500, 12, 12, 8, 55, 25, 55 }, /* 78 Mb */
[26] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 104000,
- 89500, 13, 13, 8, 25, 56, 26, 56 }, /* 104 Mb */
+ 89500, 13, 13, 8, 56, 26, 56 }, /* 104 Mb */
[27] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 117000,
- 98900, 14, 14, 8, 26, 57, 27, 57 }, /* 117 Mb */
+ 98900, 14, 14, 8, 57, 27, 57 }, /* 117 Mb */
[28] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 130000,
- 108300, 15, 15, 8, 27, 58, 29, 59 }, /* 130 Mb */
+ 108300, 15, 15, 8, 58, 29, 59 }, /* 130 Mb */
[29] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS_HGI, 144400,
- 120000, 15, 15, 8, 27, 58, 29, 59 }, /* 144.4 Mb */
+ 120000, 15, 15, 8, 58, 29, 59 }, /* 144.4 Mb */
[30] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 19500,
- 17400, 16, 16, 4, 28, 60, 30, 60 }, /* 19.5 Mb */
+ 17400, 16, 16, 4, 60, 30, 60 }, /* 19.5 Mb */
[31] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 39000,
- 35100, 17, 17, 6, 29, 61, 31, 61 }, /* 39 Mb */
+ 35100, 17, 17, 6, 61, 31, 61 }, /* 39 Mb */
[32] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 58500,
- 52600, 18, 18, 6, 30, 62, 32, 62 }, /* 58.5 Mb */
+ 52600, 18, 18, 6, 62, 32, 62 }, /* 58.5 Mb */
[33] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 78000,
- 70400, 19, 19, 8, 31, 63, 33, 63 }, /* 78 Mb */
+ 70400, 19, 19, 8, 63, 33, 63 }, /* 78 Mb */
[34] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 117000,
- 104900, 20, 20, 8, 32, 64, 35, 65 }, /* 117 Mb */
+ 104900, 20, 20, 8, 64, 35, 65 }, /* 117 Mb */
[35] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS_HGI, 130000,
- 115800, 20, 20, 8, 32, 64, 35, 65 }, /* 130 Mb */
+ 115800, 20, 20, 8, 64, 35, 65 }, /* 130 Mb */
[36] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS, 156000,
- 137200, 21, 21, 8, 33, 66, 37, 67 }, /* 156 Mb */
+ 137200, 21, 21, 8, 66, 37, 67 }, /* 156 Mb */
[37] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS_HGI, 173300,
- 151100, 21, 21, 8, 33, 66, 37, 67 }, /* 173.3 Mb */
+ 151100, 21, 21, 8, 66, 37, 67 }, /* 173.3 Mb */
[38] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS, 175500,
- 152800, 22, 22, 8, 34, 68, 39, 69 }, /* 175.5 Mb */
+ 152800, 22, 22, 8, 68, 39, 69 }, /* 175.5 Mb */
[39] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS_HGI, 195000,
- 168400, 22, 22, 8, 34, 68, 39, 69 }, /* 195 Mb */
+ 168400, 22, 22, 8, 68, 39, 69 }, /* 195 Mb */
[40] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS, 195000,
- 168400, 23, 23, 8, 35, 70, 41, 71 }, /* 195 Mb */
+ 168400, 23, 23, 8, 70, 41, 71 }, /* 195 Mb */
[41] = { RC_HT_T_20, WLAN_RC_PHY_HT_20_TS_HGI, 216700,
- 185000, 23, 23, 8, 35, 70, 41, 71 }, /* 216.7 Mb */
+ 185000, 23, 23, 8, 70, 41, 71 }, /* 216.7 Mb */
[42] = { RC_HT_SDT_40, WLAN_RC_PHY_HT_40_SS, 13500,
- 13200, 0, 0, 8, 12, 42, 42, 42 }, /* 13.5 Mb */
+ 13200, 0, 0, 8, 42, 42, 42 }, /* 13.5 Mb */
[43] = { RC_HT_SDT_40, WLAN_RC_PHY_HT_40_SS, 27500,
- 25900, 1, 1, 8, 13, 43, 43, 43 }, /* 27.0 Mb */
+ 25900, 1, 1, 8, 43, 43, 43 }, /* 27.0 Mb */
[44] = { RC_HT_SDT_40, WLAN_RC_PHY_HT_40_SS, 40500,
- 38600, 2, 2, 8, 14, 44, 44, 44 }, /* 40.5 Mb */
+ 38600, 2, 2, 8, 44, 44, 44 }, /* 40.5 Mb */
[45] = { RC_HT_SD_40, WLAN_RC_PHY_HT_40_SS, 54000,
- 49800, 3, 3, 8, 15, 45, 45, 45 }, /* 54 Mb */
+ 49800, 3, 3, 8, 45, 45, 45 }, /* 54 Mb */
[46] = { RC_HT_SD_40, WLAN_RC_PHY_HT_40_SS, 81500,
- 72200, 4, 4, 8, 16, 46, 46, 46 }, /* 81 Mb */
+ 72200, 4, 4, 8, 46, 46, 46 }, /* 81 Mb */
[47] = { RC_HT_S_40 , WLAN_RC_PHY_HT_40_SS, 108000,
- 92900, 5, 5, 8, 17, 47, 47, 47 }, /* 108 Mb */
+ 92900, 5, 5, 8, 47, 47, 47 }, /* 108 Mb */
[48] = { RC_HT_S_40, WLAN_RC_PHY_HT_40_SS, 121500,
- 102700, 6, 6, 8, 18, 48, 48, 48 }, /* 121.5 Mb */
+ 102700, 6, 6, 8, 48, 48, 48 }, /* 121.5 Mb */
[49] = { RC_HT_S_40, WLAN_RC_PHY_HT_40_SS, 135000,
- 112000, 7, 7, 8, 19, 49, 50, 50 }, /* 135 Mb */
+ 112000, 7, 7, 8, 49, 50, 50 }, /* 135 Mb */
[50] = { RC_HT_S_40, WLAN_RC_PHY_HT_40_SS_HGI, 150000,
- 122000, 7, 7, 8, 19, 49, 50, 50 }, /* 150 Mb */
+ 122000, 7, 7, 8, 49, 50, 50 }, /* 150 Mb */
[51] = { RC_INVALID, WLAN_RC_PHY_HT_40_DS, 27000,
- 25800, 8, 8, 8, 20, 51, 51, 51 }, /* 27 Mb */
+ 25800, 8, 8, 8, 51, 51, 51 }, /* 27 Mb */
[52] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_DS, 54000,
- 49800, 9, 9, 8, 21, 52, 52, 52 }, /* 54 Mb */
+ 49800, 9, 9, 8, 52, 52, 52 }, /* 54 Mb */
[53] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_DS, 81000,
- 71900, 10, 10, 8, 22, 53, 53, 53 }, /* 81 Mb */
+ 71900, 10, 10, 8, 53, 53, 53 }, /* 81 Mb */
[54] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 108000,
- 92500, 11, 11, 8, 23, 54, 54, 54 }, /* 108 Mb */
+ 92500, 11, 11, 8, 54, 54, 54 }, /* 108 Mb */
[55] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 162000,
- 130300, 12, 12, 8, 24, 55, 55, 55 }, /* 162 Mb */
+ 130300, 12, 12, 8, 55, 55, 55 }, /* 162 Mb */
[56] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 216000,
- 162800, 13, 13, 8, 25, 56, 56, 56 }, /* 216 Mb */
+ 162800, 13, 13, 8, 56, 56, 56 }, /* 216 Mb */
[57] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 243000,
- 178200, 14, 14, 8, 26, 57, 57, 57 }, /* 243 Mb */
+ 178200, 14, 14, 8, 57, 57, 57 }, /* 243 Mb */
[58] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS, 270000,
- 192100, 15, 15, 8, 27, 58, 59, 59 }, /* 270 Mb */
+ 192100, 15, 15, 8, 58, 59, 59 }, /* 270 Mb */
[59] = { RC_HT_DT_40, WLAN_RC_PHY_HT_40_DS_HGI, 300000,
- 207000, 15, 15, 8, 27, 58, 59, 59 }, /* 300 Mb */
+ 207000, 15, 15, 8, 58, 59, 59 }, /* 300 Mb */
[60] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 40500,
- 36100, 16, 16, 8, 28, 60, 60, 60 }, /* 40.5 Mb */
+ 36100, 16, 16, 8, 60, 60, 60 }, /* 40.5 Mb */
[61] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 81000,
- 72900, 17, 17, 8, 29, 61, 61, 61 }, /* 81 Mb */
+ 72900, 17, 17, 8, 61, 61, 61 }, /* 81 Mb */
[62] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 121500,
- 108300, 18, 18, 8, 30, 62, 62, 62 }, /* 121.5 Mb */
+ 108300, 18, 18, 8, 62, 62, 62 }, /* 121.5 Mb */
[63] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 162000,
- 142000, 19, 19, 8, 31, 63, 63, 63 }, /* 162 Mb */
+ 142000, 19, 19, 8, 63, 63, 63 }, /* 162 Mb */
[64] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS, 243000,
- 205100, 20, 20, 8, 32, 64, 65, 65 }, /* 243 Mb */
+ 205100, 20, 20, 8, 64, 65, 65 }, /* 243 Mb */
[65] = { RC_INVALID, WLAN_RC_PHY_HT_40_TS_HGI, 270000,
- 224700, 20, 20, 8, 32, 64, 65, 65 }, /* 170 Mb */
+ 224700, 20, 20, 8, 64, 65, 65 }, /* 170 Mb */
[66] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS, 324000,
- 263100, 21, 21, 8, 33, 66, 67, 67 }, /* 324 Mb */
+ 263100, 21, 21, 8, 66, 67, 67 }, /* 324 Mb */
[67] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 360000,
- 288000, 21, 21, 8, 33, 66, 67, 67 }, /* 360 Mb */
+ 288000, 21, 21, 8, 66, 67, 67 }, /* 360 Mb */
[68] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS, 364500,
- 290700, 22, 22, 8, 34, 68, 69, 69 }, /* 364.5 Mb */
+ 290700, 22, 22, 8, 68, 69, 69 }, /* 364.5 Mb */
[69] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 405000,
- 317200, 22, 22, 8, 34, 68, 69, 69 }, /* 405 Mb */
+ 317200, 22, 22, 8, 68, 69, 69 }, /* 405 Mb */
[70] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS, 405000,
- 317200, 23, 23, 8, 35, 70, 71, 71 }, /* 405 Mb */
+ 317200, 23, 23, 8, 70, 71, 71 }, /* 405 Mb */
[71] = { RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 450000,
- 346400, 23, 23, 8, 35, 70, 71, 71 }, /* 450 Mb */
+ 346400, 23, 23, 8, 70, 71, 71 }, /* 450 Mb */
},
50, /* probe interval */
WLAN_RC_HT_FLAG, /* Phy rates allowed initially */
@@ -325,21 +325,21 @@ static const struct ath_rate_table ar5416_11a_ratetable = {
0,
{
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 6000, /* 6 Mb */
- 5400, 0, 12, 0, 0, 0 },
+ 5400, 0, 12, 0},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 9000, /* 9 Mb */
- 7800, 1, 18, 0, 1, 0 },
+ 7800, 1, 18, 0},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 12000, /* 12 Mb */
- 10000, 2, 24, 2, 2, 0 },
+ 10000, 2, 24, 2},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 18000, /* 18 Mb */
- 13900, 3, 36, 2, 3, 0 },
+ 13900, 3, 36, 2},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 24000, /* 24 Mb */
- 17300, 4, 48, 4, 4, 0 },
+ 17300, 4, 48, 4},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 36000, /* 36 Mb */
- 23000, 5, 72, 4, 5, 0 },
+ 23000, 5, 72, 4},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 48000, /* 48 Mb */
- 27400, 6, 96, 4, 6, 0 },
+ 27400, 6, 96, 4},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 54000, /* 54 Mb */
- 29300, 7, 108, 4, 7, 0 },
+ 29300, 7, 108, 4},
},
50, /* probe interval */
0, /* Phy rates allowed initially */
@@ -350,29 +350,29 @@ static const struct ath_rate_table ar5416_11g_ratetable = {
0,
{
{ RC_L_SDT, WLAN_RC_PHY_CCK, 1000, /* 1 Mb */
- 900, 0, 2, 0, 0, 0 },
+ 900, 0, 2, 0},
{ RC_L_SDT, WLAN_RC_PHY_CCK, 2000, /* 2 Mb */
- 1900, 1, 4, 1, 1, 0 },
+ 1900, 1, 4, 1},
{ RC_L_SDT, WLAN_RC_PHY_CCK, 5500, /* 5.5 Mb */
- 4900, 2, 11, 2, 2, 0 },
+ 4900, 2, 11, 2},
{ RC_L_SDT, WLAN_RC_PHY_CCK, 11000, /* 11 Mb */
- 8100, 3, 22, 3, 3, 0 },
+ 8100, 3, 22, 3},
{ RC_INVALID, WLAN_RC_PHY_OFDM, 6000, /* 6 Mb */
- 5400, 4, 12, 4, 4, 0 },
+ 5400, 4, 12, 4},
{ RC_INVALID, WLAN_RC_PHY_OFDM, 9000, /* 9 Mb */
- 7800, 5, 18, 4, 5, 0 },
+ 7800, 5, 18, 4},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 12000, /* 12 Mb */
- 10000, 6, 24, 6, 6, 0 },
+ 10000, 6, 24, 6},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 18000, /* 18 Mb */
- 13900, 7, 36, 6, 7, 0 },
+ 13900, 7, 36, 6},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 24000, /* 24 Mb */
- 17300, 8, 48, 8, 8, 0 },
+ 17300, 8, 48, 8},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 36000, /* 36 Mb */
- 23000, 9, 72, 8, 9, 0 },
+ 23000, 9, 72, 8},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 48000, /* 48 Mb */
- 27400, 10, 96, 8, 10, 0 },
+ 27400, 10, 96, 8},
{ RC_L_SDT, WLAN_RC_PHY_OFDM, 54000, /* 54 Mb */
- 29300, 11, 108, 8, 11, 0 },
+ 29300, 11, 108, 8},
},
50, /* probe interval */
0, /* Phy rates allowed initially */
diff --git a/drivers/net/wireless/ath/ath9k/rc.h b/drivers/net/wireless/ath/ath9k/rc.h
index e914c33..dc10826 100644
--- a/drivers/net/wireless/ath/ath9k/rc.h
+++ b/drivers/net/wireless/ath/ath9k/rc.h
@@ -162,7 +162,6 @@ struct ath_rate_table {
u8 ratecode;
u8 dot11rate;
u8 ctrl_rate;
- u8 base_index;
u8 cw40index;
u8 sgi_index;
u8 ht_index;
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] ath9k: Fix incorrect user ratekbs of MCS15 ShortGI
From: Senthil Balasubramanian @ 2010-07-27 13:46 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Senthil Balasubramanian
In-Reply-To: <1280238394-2565-1-git-send-email-senthilkumar@atheros.com>
The user ratekbs of MCS15 ShortGI is incorrect and can not be lesser
than MCS15 rate. This incorrect rate may affect switching to higher
rates as the rate control algorithm always finds MCS15 is better
than MCS15 ShortGI and results in lower throughput. Fix this by
feeding the correct user ratekbs for MCS15 ShortGI rate.
This issue affects 3 stream case very badly as the 3 stream rates are
not used at all once we scale down to MCS15 from 3 stream rates.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
---
drivers/net/wireless/ath/ath9k/rc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 7b63958..5c9df3b 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -74,7 +74,7 @@ static const struct ath_rate_table ar5416_11na_ratetable = {
[24] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS, 130000,
108300, 15, 15, 4, 23, 54, 25, 55 }, /* 130 Mb */
[25] = { RC_HT_DT_20, WLAN_RC_PHY_HT_20_DS_HGI, 144400,
- 12000, 15, 15, 4, 23, 54, 25, 55 }, /* 144.4 Mb */
+ 120000, 15, 15, 4, 23, 54, 25, 55 }, /* 144.4 Mb */
[26] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 19500,
17400, 16, 16, 0, 24, 56, 26, 56 }, /* 19.5 Mb */
[27] = { RC_INVALID, WLAN_RC_PHY_HT_20_TS, 39000,
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox