* [RFC PATCHv4 0/2] mac80211: cfg80211: dynamic ps timeout based on pm-qos
From: Juuso Oikarinen @ 2010-04-21 11:47 UTC (permalink / raw)
To: linux-wireless
These patches propose a way to adjust the dynamic ps timeout in the mac80211
based on the pm-qos network latency value. This allows user space to influence
the level of power saving performed by the mac80211.
v4 of these patches change the way pm qos network latency ranges converted to
dynamic ps timeout values a little bit saner. Unlike the previous set of
patches, now the latancy values make sense in a wider scope than this
ps timeout thing only. I hope this makes them somewhat more future-proof.
As wext still has an interface to adjust the dynamic ps timeout from userspace,
the wext configuration will override the above, to remain backwards
compatible.
Comments are appreciated.
Juuso Oikarinen (2):
mac80211: Determine dynamic PS timeout based on ps-qos network
latency
cfg80211: Remove default dynamic PS timeout value
include/net/cfg80211.h | 2 ++
include/net/mac80211.h | 5 ++++-
net/mac80211/cfg.c | 4 ++--
net/mac80211/main.c | 2 ++
net/mac80211/mlme.c | 21 +++++++++++++++++++++
net/wireless/core.c | 3 ++-
6 files changed, 33 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Jerome Glisse @ 2010-04-21 8:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Nick Bowler, DRI, Linux SCSI List, Network Development,
Linux Wireless List, Linux Kernel Mailing List, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
In-Reply-To: <201004210715.38621.rjw@sisk.pl>
On Wed, Apr 21, 2010 at 07:15:38AM +0200, Rafael J. Wysocki wrote:
> On Tuesday 20 April 2010, Nick Bowler wrote:
> > On 05:15 Tue 20 Apr , Rafael J. Wysocki wrote:
> > > If you know of any other unresolved regressions from 2.6.33, please let us
> > > know either and we'll add them to the list. Also, please let us know
> > > if any of the entries below are invalid.
> >
> > Please list these two similar regressions from 2.6.33 in the r600 DRM:
> >
> > * r600 CS checker rejects GL_DEPTH_TEST w/o depth buffer:
> > https://bugs.freedesktop.org/show_bug.cgi?id=27571
> >
> > * r600 CS checker rejects narrow FBO renderbuffers:
> > https://bugs.freedesktop.org/show_bug.cgi?id=27609
>
> Do you want to me to add them as one entry or as two separate bugs?
>
> Rafael
>
First one is userspace bug, i need to look into the second one.
ie we were lucky the hw didn't lockup without depth buffer and
depth test enabled.
Cheers,
Jerome
^ permalink raw reply
* [PATCH] radiotap parser: fix endian annotation
From: Johannes Berg @ 2010-04-21 8:25 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When I updated this from the corresponding
userspace library, an annotation error crept
in -- this variable needs to be annotated as
little endian. No effect on code generation.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
It's a fix for a .34 patch but I don't care if it makes it in there
since it only fixes a sparse warning.
include/net/cfg80211.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/include/net/cfg80211.h 2010-04-21 10:23:42.000000000 +0200
+++ wireless-testing/include/net/cfg80211.h 2010-04-21 10:23:54.000000000 +0200
@@ -1643,7 +1643,7 @@ struct ieee80211_radiotap_iterator {
const struct ieee80211_radiotap_namespace *current_namespace;
unsigned char *_arg, *_next_ns_data;
- uint32_t *_next_bitmap;
+ __le32 *_next_bitmap;
unsigned char *this_arg;
int this_arg_index;
^ permalink raw reply
* Re: [rt2x00] rt3070 fails to initialize with rt2800usb
From: Walter Goldens @ 2010-04-21 8:17 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: linux-wireless, users
In-Reply-To: <201004191825.54738.IvDoorn@gmail.com>
> > > Thats odd, in compar-wireless, it already
> contains the
> > > lines:
> > >
> > > #ifdef CONFIG_RT2800USB_RT30XX
> > > <..snip..>
> > > /* Ralink */
> > > { USB_DEVICE(0x148f, 0x2070),
> > > USB_DEVICE_DATA(&rt2800usb_ops) },
> > > { USB_DEVICE(0x148f, 0x3070),
> > > USB_DEVICE_DATA(&rt2800usb_ops) },
> > > { USB_DEVICE(0x148f, 0x3071),
> > > USB_DEVICE_DATA(&rt2800usb_ops) },
> > > { USB_DEVICE(0x148f, 0x3072),
> > > USB_DEVICE_DATA(&rt2800usb_ops) },
> > > <..snip..>
> > > #endif
> > >
> > > So adding the USB ID does not need to be added.
> > >
> > > Ivo
> >
> > It is odd. I followed exactly the same logic you have,
> but I'm adamant the module doesn't recognize the VID of card
> as it is. Lets get factual:
> >
> > compat-wireless from March 28th. default install (make
> && make install) here is the output when the
> rt2800usb is loaded:
> >
> > [21902.553231] Generic kernel compatibility enabled
> based on linux-next next-20100113
> > [21902.596351] cfg80211: Calling CRDA to update world
> regulatory domain
> > [21902.695076] usbcore: registered new interface
> driver rt2800usb
> > [21902.714019] cfg80211: World regulatory domain
> updated:
> > [21902.714026] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> > [21902.714032] (2402000 KHz - 2472000 KHz @
> 40000 KHz), (300 mBi, 2000 mBm)
> > [21902.714036] (2457000 KHz - 2482000 KHz @
> 20000 KHz), (300 mBi, 2000 mBm)
> > [21902.714041] (2474000 KHz - 2494000 KHz @
> 20000 KHz), (300 mBi, 2000 mBm)
> > [21902.714045] (5170000 KHz - 5250000 KHz @
> 40000 KHz), (300 mBi, 2000 mBm)
> > [21902.714050] (5735000 KHz - 5835000 KHz @
> 40000 KHz), (300 mBi, 2000 mBm)
> >
> > modinfo rt2800usb |grep 3070 -- returns nothing
> >
> > as soon as I add the 148f:rt3070 to:
> >
> > /* Ralink */
> > { USB_DEVICE(0x148f, 0x2770),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x2870),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x3070),
> USB_DEVICE_DATA(&rt2800usb_ops) }, <--- manually
> added
> > /* Samsung */
> >
> > rt2800usb recognizes the chip and initializes all
> operations:
> >
> > [22310.272382] usb 5-2.4: new high speed USB device
> using ehci_hcd and address 10
> > [22310.381269] usb 5-2.4: configuration #1 chosen from
> 1 choice
> > [22310.416482] phy1: Selected rate control algorithm
> 'minstrel'
> > [22310.417403] Registered led device:
> rt2800usb-phy1::radio
> > [22310.417456] Registered led device:
> rt2800usb-phy1::assoc
> > [22310.417505] Registered led device:
> rt2800usb-phy1::quality
> > [22310.479159] udev: renamed network interface wlan0
> to wlan2
> > [22310.483779] rt2800usb 5-2.4:1.0: firmware:
> requesting rt2870.bin
> >
> > Now, modinfo rt2800usb |grep 3070 -- shows its OK:
> >
> > alias:
> usb:v148Fp3070d*dc*dsc*dp*ic*isc*ip*
> >
> >
> > This is a longstanding bug from at least few months or
> so, I thought you were experimenting/adjusting the code
> and I figured it would be temporary, but it has been so long
> that I thought I had to report this now.
> >
> > Walter.
>
> Just checked the wireless-compat package, but are you sure
> that the config file contains:
> CONFIG_RT2800USB_RT30XX=y
> and not the default:
> # CONFIG_RT2800USB_RT30XX=y
>
> Note the prefixed '#' which should be removed to enable the
> configuration option.
>
> Ivo
I think I spoke too early. Must have been a snarl up at my end, because even removing the "#" comment sign before "CONFIG_RT2800USB_RT30XX=y" in config.mk doesn't solve the detection problem.
I just concluded a test with today's compat-wireless /April 20/, enabled "CONFIG_RT2800USB_RT30XX=y" in config.mk, but rt2800usb doesn't detect the VIDs and subsequently fails to initialize the device. Adding, however the card's VIDs in the upper portion of code appears to solve the case. I welcome you to test yourself.
The good news is, once we get past the detection debacle the device seems to finally show some life.
Walter.
^ permalink raw reply
* ath9k initvals-tool - integrity checks | reformat | synchronize
From: Luis R. Rodriguez @ 2010-04-21 7:29 UTC (permalink / raw)
To: linux-wireless
Cc: doug.dahlby, Atheros Internal ath9k development team,
Cliff Holden, Zhifeng Cai, Pavel Roskin
In the v2 patch cover letter for AR9003 I noted how I had started some
simple initval userspcae tool to check the integrity of the initvals.
Since we also had some discussions about the possible format changes
for it I've gone ahead and extended the same tool to also reformat our
initvals to any format we like and at the same time allowing us to
verify the integrity is kept. This same tool can now be used by us at
Atheros to check for changes quickly between our Atheros HAL and the
ath9k_hw module. I've written some docs how to do all this here:
http://wireless.kernel.org/en/users/Drivers/ath9k_hw/initvals-tool
We have a few initval patches not yet submitted for AR9003, once we
shoot those out, and they get merged, we can then start talking about
the preferred format we want for these initvals and rewrite
ath9k_hw_print_initval() to our liking, and then keep using that
moving forward. We will still need to eventually merge these same
files into the Atheros HAL so we just have the same initvals
style/format everywhere but this should help somewhat with this. The
Atheros HAL uses some other tool to generate the initvals, that will
just need to be modified to accommodate the desired upon style on
Linux and we can finally move on with other things to synchronize.
Let me know if you have any questions.
Luis
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: Sedat Dilek @ 2010-04-21 7:06 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless, John Linville, Johannes Berg
In-Reply-To: <1271782442.14052.19698.camel@rchatre-DESK>
On Tue, Apr 20, 2010 at 6:54 PM, reinette chatre
<reinette.chatre@intel.com> wrote:
> Hi,
>
> On Sat, 2010-04-17 at 07:05 -0700, Sedat Dilek wrote:
>> I have already sent an bug-report "iwl3945: Network dropouts w/
>> flash-stream in firefox" in [1].
>> Unfortunately, the problem still remains, especially when
>> fast-forwarding flash movies in firefox-3.6.3.
>> It seems the wifi-card is hanging and my system needs a coldstart.
>
> Is this a recent problem? How regularly do you update your kernel?
>
Currently, I am using mostly upstream 2.6.34-rcX kernels.
When kernel snapshots (-gitX) have drm-2.6, ext4 or wireless-2.6
patches I jump on them.
>>
>> The kernel I use is a Linux-2.6.34-rc4-git4 with these 3 patches in addition:
>
> Where can I access this kernel's git repo?
>
As I already said it is Linus-tree - to be on 2.6.34-rc4-git4 [1], run:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ git reset --hard dc57da3875f527b1cc195ea4ce5bd32e1e68433d
It would be cool, when you can check this on some iwl3945 hardware.
Do not forget the three patches from [2] to have same testing environment.
As far as I can see, wireless-2.6 (master-2010-04-20) has them included.
>> According to Johannes (on IRC) iwl3945 doesn't use internal scans yet
>> (see my patch below).
>> Thus, I am not sure if this needs to be fixed separately for iwl3945
>> and if I ran into a scan race condition here.
>
> Does this patch make any difference for you?
>
Speaking of my patch "iwl3945-fix-scan-races.patch" from [3]?
I was guessing iwl3945 has internal scans support - is that the fact?
Johannes told me someone is working on it.
To answer your question: Not sure, but it seems not to help.
Unfortunately, it is hard for me to say what exactly caused these wifi problems.
After my email I tested 2.6.34-rc4-git6 and could not reproduce it.
I tested several websites with flash streams.
Do the ash particles of the Iceland volcano disturb wlan waves here?
Wonder why John gave no restrictions to Linux wireless users and devs
to not use wifi and switch to wired connections for last weekend and
next days :-).
>> Hope, this helps.
>
> It does. Thank you. As a sanity check, could you please try this patch?
>
In general, it would be very helpful to give some comments on what
this offered patch is doing.
Not sure, if I can test it today.
To have same scenario, base is a Linux-2.6.34-rc4-git4 kernel with this series:
wireless-2.6/0001-iwlwifi-work-around-bogus-active-chains-detection.patch
iwlwifi-fixes-for-2.6.34/1-2-iwlwifi-fix-scan-races.patch
iwlwifi-fixes-for-2.6.34/2-2-iwlwifi-correct-6000-EEPROM-regulatory-address.patch
rchatre/sanity-check.patch
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index c8cd169..1ad15bd 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -814,7 +814,7 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata)
> changed |= BSS_CHANGED_ASSOC;
> sdata->vif.bss_conf.assoc = false;
>
> - ieee80211_set_wmm_default(sdata);
> + /*ieee80211_set_wmm_default(sdata);*/
>
> /* channel(_type) changes are handled by ieee80211_hw_config */
> local->oper_channel_type = NL80211_CHAN_NO_HT;
>
By the way, might help to set one of the module-options for iwl3945?
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: swcrypto:using software crypto (default 1 [software]) (int)
parm: debug:debug output mask (uint)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: fw_restart3945:restart firmware in case of error (int)
Especially "fw_restart3945" in my case? On which errors it is
restarting firmware?
Kind Regards,
- Sedat -
[1] http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.34-rc4-git4.id
[2] http://files.iniza.org/BUG_iwl3945_20100417/patches/
[3] http://marc.info/?l=linux-wireless&m=127151315515173&w=2
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-04-21 5:15 UTC (permalink / raw)
To: Nick Bowler
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <20100420135636.GA10674@elliptictech.com>
On Tuesday 20 April 2010, Nick Bowler wrote:
> On 05:15 Tue 20 Apr , Rafael J. Wysocki wrote:
> > If you know of any other unresolved regressions from 2.6.33, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
>
> Please list these two similar regressions from 2.6.33 in the r600 DRM:
>
> * r600 CS checker rejects GL_DEPTH_TEST w/o depth buffer:
> https://bugs.freedesktop.org/show_bug.cgi?id=27571
>
> * r600 CS checker rejects narrow FBO renderbuffers:
> https://bugs.freedesktop.org/show_bug.cgi?id=27609
Do you want to me to add them as one entry or as two separate bugs?
Rafael
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-04-21 5:14 UTC (permalink / raw)
To: Ben Gamari
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <4bce5cc3.966bdc0a.2ef7.fffff5de@mx.google.com>
On Wednesday 21 April 2010, Ben Gamari wrote:
> On Tue, 20 Apr 2010 05:15:57 +0200 (CEST), "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > This message contains a list of some regressions from 2.6.33,
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved regressions from 2.6.33, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
> >
>
> I have recently reported this suspend regression on my Dell laptop hardware.
>
> References: http://lkml.org/lkml/2010/4/18/20
> Bug-report: https://bugzilla.kernel.org/show_bug.cgi?id=15820
This has been added to the list now. Please check my comment in the Bugzilla
entry.
Rafael
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID now
From: Sujith @ 2010-04-21 2:08 UTC (permalink / raw)
To: John W. Linville
Cc: Luis Rodriguez, Wiktor Zajas, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20100420154543.GA6472@tuxdriver.com>
John W. Linville wrote:
> Any feedback on this?
This has already been merged.
commit e92119ca88691ac2239916d31c3dcecd10867521
Author: Sujith <Sujith.Manoharan@atheros.com>
Date: Thu Apr 1 10:28:24 2010 +0530
ath9k_htc: Add TL-WN422G v2 product ID
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Ben Gamari @ 2010-04-21 2:02 UTC (permalink / raw)
To: Rafael J. Wysocki, Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <deuQKFRcc0B.A.3EG.BRSzLB@tosh>
On Tue, 20 Apr 2010 05:15:57 +0200 (CEST), "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> This message contains a list of some regressions from 2.6.33,
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 2.6.33, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
>
I have recently reported this suspend regression on my Dell laptop hardware.
References: http://lkml.org/lkml/2010/4/18/20
Bug-report: https://bugzilla.kernel.org/show_bug.cgi?id=15820
Thanks,
- Ben
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-04-20
From: David Miller @ 2010-04-21 1:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100420183013.GC6472@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 20 Apr 2010 14:30:14 -0400
> Here are a few more intended for 2.6.34, mostly from the iwlwifi team.
> They fix a couple of potential crashes, an incorrect EEPROM offset
> related to regulatory information, and a connectivity failure relating
> to 802.11n and the 4965. The "iwlwifi: fix scan races" seems a little
> long, but much of it is the fallout from renaming a goto label.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 2/2] ath9k_hw: make all AR9002 initvals use u32
From: Luis R. Rodriguez @ 2010-04-20 23:43 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linville, linux-wireless
In-Reply-To: <j2t69e28c911004201634h41e320bfu2f0746a25f1f0d00@mail.gmail.com>
2010/4/20 Gábor Stefanik <netrolller.3d@gmail.com>:
> Will the u_int32_t type be removed eventually? (Given that the
> standard type is uint32_t.)
Not sure, but it doesn't matter for us so long as we use u32 :)
Luis
^ permalink raw reply
* Re: mac80211 and asymmetric 802.11n TX/RX
From: Gábor Stefanik @ 2010-04-20 23:36 UTC (permalink / raw)
To: Daniel Halperin; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <6D966E94-4FD1-4675-B39B-296B4D82D2AB@cs.washington.edu>
On Tue, Apr 20, 2010 at 7:10 PM, Daniel Halperin
<dhalperi@cs.washington.edu> wrote:
> Hi Johannes,
>
> On Apr 20, 2010, at 1:22 AM, Johannes Berg wrote:
>>> Does anyone know if the 11n standard says that the set of TX rates has
>>> to be a subset of the set of RX rates? This seems to be enforced now:
>>> when I set up one node to be 2x1, i.e. transmit 2 streams but only
>>> able to receive 1, then the mac80211 code only lets it transmit 1
>>> streams (even with a 2-stream-capable receiver at the other end).
>>
>> I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
>> about the "Rx Highest Supported Data Rate" field. Seems like maybe you
>> could set the "RX MCS bitmask" to more than is supported, limit it by
>> the highest supported data rate, and then use the bitmask for TX?
>
> First, did you mean 7.3.2.57.4? (I'm using IEEE P802.11n/D7.0, but I assume the section numbers haven't changed). For me that section represents the "Supported MCS Set field".
>
> (An aside: I don't actually *have* 7.3.2.56. I'm using IEEE 802.11-2007 [has up to 7.3.2.35] and IEEE P802.11n/D7.0 [has 7.3.2.57 and beyond] --- In which document are the missing sections?)
>
> Can you point me at which text in the section you think implies this requirement?
>
> In any case, maybe this discussion is silly: I don't know of any devices with this strange configuration. Typically clients assume downlink-heavy and might support a 1x2 connection but 2x1, i.e. designed for uplink, seems unlikely.
Unless we are talking about an AP...
>
>>> A second question: my understanding is that if I am a 2x2 node and I
>>> associate to a 3x3 AP, the same code will mask out the fact that the
>>> AP can receive 3 streams since I can't transmit 3 streams. Is there a
>>> way to access this info from the driver if I want it?
>>
>> Unfortunately not, at this point. We could keep track of it, what would
>> you need it for?
>
> Okay, that's what I figured; I can hack around it locally. I'm working on an alternative rate selection algorithm that at one point tries to take into account how much receive diversity the other endpoint has. The intuition is that how well (e.g.) 2-stream rates work is going to depend not just on the channel, but also on how many excess antennas the receiver has. I would benefit from knowing whether they have 2 or 3 antennas even if I can only send them at most 2 streams.
>
> Thanks,
> Dan--
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 2/2] ath9k_hw: make all AR9002 initvals use u32
From: Gábor Stefanik @ 2010-04-20 23:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1271802516-15195-3-git-send-email-lrodriguez@atheros.com>
Will the u_int32_t type be removed eventually? (Given that the
standard type is uint32_t.)
On Wed, Apr 21, 2010 at 12:28 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 68 +++++++++++-----------
> 1 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
> index 0f74ea7..f06313d 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
> +++ b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
> @@ -1468,7 +1468,7 @@ static const u32 ar9280PciePhy_clkreq_always_on_L1_9280[][2] = {
> };
>
> /* AR9285 Revsion 10*/
> -static const u_int32_t ar9285Modes_9285[][6] = {
> +static const u32 ar9285Modes_9285[][6] = {
> { 0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160, 0x000001e0 },
> { 0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c, 0x000001e0 },
> { 0x000010b0, 0x00000e60, 0x00001cc0, 0x00007c70, 0x00003e38, 0x00001180 },
> @@ -1790,7 +1790,7 @@ static const u_int32_t ar9285Modes_9285[][6] = {
> { 0x0000a358, 0x7999aa02, 0x7999aa02, 0x7999aa0e, 0x7999aa0e, 0x7999aa0e },
> };
>
> -static const u_int32_t ar9285Common_9285[][2] = {
> +static const u32 ar9285Common_9285[][2] = {
> { 0x0000000c, 0x00000000 },
> { 0x00000030, 0x00020045 },
> { 0x00000034, 0x00000005 },
> @@ -2123,7 +2123,7 @@ static const u_int32_t ar9285Common_9285[][2] = {
> { 0x00007870, 0x10142c00 },
> };
>
> -static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285[][2] = {
> +static const u32 ar9285PciePhy_clkreq_always_on_L1_9285[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -2136,7 +2136,7 @@ static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285[][2] = {
> {0x00004044, 0x00000000 },
> };
>
> -static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285[][2] = {
> +static const u32 ar9285PciePhy_clkreq_off_L1_9285[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -2150,7 +2150,7 @@ static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285[][2] = {
> };
>
> /* AR9285 v1_2 PCI Register Writes. Created: 04/13/09 */
> -static const u_int32_t ar9285Modes_9285_1_2[][6] = {
> +static const u32 ar9285Modes_9285_1_2[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160, 0x000001e0 },
> { 0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c, 0x000001e0 },
> @@ -2456,7 +2456,7 @@ static const u_int32_t ar9285Modes_9285_1_2[][6] = {
> { 0x0000a358, 0x7999aa02, 0x7999aa02, 0x7999aa0e, 0x7999aa0e, 0x7999aa0e },
> };
>
> -static const u_int32_t ar9285Common_9285_1_2[][2] = {
> +static const u32 ar9285Common_9285_1_2[][2] = {
> { 0x0000000c, 0x00000000 },
> { 0x00000030, 0x00020045 },
> { 0x00000034, 0x00000005 },
> @@ -2775,7 +2775,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
> { 0x00007870, 0x10142c00 },
> };
>
> -static const u_int32_t ar9285Modes_high_power_tx_gain_9285_1_2[][6] = {
> +static const u32 ar9285Modes_high_power_tx_gain_9285_1_2[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00006200, 0x00006200, 0x00000000 },
> @@ -2816,7 +2816,7 @@ static const u_int32_t ar9285Modes_high_power_tx_gain_9285_1_2[][6] = {
> { 0x0000a3e0, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7 },
> };
>
> -static const u_int32_t ar9285Modes_original_tx_gain_9285_1_2[][6] = {
> +static const u32 ar9285Modes_original_tx_gain_9285_1_2[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00009200, 0x00009200, 0x00000000 },
> @@ -2857,7 +2857,7 @@ static const u_int32_t ar9285Modes_original_tx_gain_9285_1_2[][6] = {
> { 0x0000a3e0, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c },
> };
>
> -static const u_int32_t ar9285Modes_XE2_0_normal_power[][6] = {
> +static const u32 ar9285Modes_XE2_0_normal_power[][6] = {
> { 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00009200, 0x00009200, 0x00000000 },
> { 0x0000a308, 0x00000000, 0x00000000, 0x00010208, 0x00010208, 0x00000000 },
> @@ -2897,7 +2897,7 @@ static const u_int32_t ar9285Modes_XE2_0_normal_power[][6] = {
> { 0x0000a3e0, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c },
> };
>
> -static const u_int32_t ar9285Modes_XE2_0_high_power[][6] = {
> +static const u32 ar9285Modes_XE2_0_high_power[][6] = {
> { 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00006200, 0x00006200, 0x00000000 },
> { 0x0000a308, 0x00000000, 0x00000000, 0x00008201, 0x00008201, 0x00000000 },
> @@ -2937,7 +2937,7 @@ static const u_int32_t ar9285Modes_XE2_0_high_power[][6] = {
> { 0x0000a3e0, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7 },
> };
>
> -static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285_1_2[][2] = {
> +static const u32 ar9285PciePhy_clkreq_always_on_L1_9285_1_2[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -2950,7 +2950,7 @@ static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285_1_2[][2] = {
> {0x00004044, 0x00000000 },
> };
>
> -static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285_1_2[][2] = {
> +static const u32 ar9285PciePhy_clkreq_off_L1_9285_1_2[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -2964,7 +2964,7 @@ static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285_1_2[][2] = {
> };
>
> /* AR9287 Revision 10 */
> -static const u_int32_t ar9287Modes_9287_1_0[][6] = {
> +static const u32 ar9287Modes_9287_1_0[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x00001030, 0x00000000, 0x00000000, 0x000002c0, 0x00000160, 0x000001e0 },
> { 0x00001070, 0x00000000, 0x00000000, 0x00000318, 0x0000018c, 0x000001e0 },
> @@ -3011,7 +3011,7 @@ static const u_int32_t ar9287Modes_9287_1_0[][6] = {
> { 0x0000a3d8, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> };
>
> -static const u_int32_t ar9287Common_9287_1_0[][2] = {
> +static const u32 ar9287Common_9287_1_0[][2] = {
> { 0x0000000c, 0x00000000 },
> { 0x00000030, 0x00020015 },
> { 0x00000034, 0x00000005 },
> @@ -3382,7 +3382,7 @@ static const u_int32_t ar9287Common_9287_1_0[][2] = {
> { 0x000078b8, 0x2a850160 },
> };
>
> -static const u_int32_t ar9287Modes_tx_gain_9287_1_0[][6] = {
> +static const u32 ar9287Modes_tx_gain_9287_1_0[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00004002, 0x00004002, 0x00004002 },
> @@ -3432,7 +3432,7 @@ static const u_int32_t ar9287Modes_tx_gain_9287_1_0[][6] = {
> };
>
>
> -static const u_int32_t ar9287Modes_rx_gain_9287_1_0[][6] = {
> +static const u32 ar9287Modes_rx_gain_9287_1_0[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x00009a00, 0x00000000, 0x00000000, 0x0000a120, 0x0000a120, 0x0000a120 },
> { 0x00009a04, 0x00000000, 0x00000000, 0x0000a124, 0x0000a124, 0x0000a124 },
> @@ -3694,7 +3694,7 @@ static const u_int32_t ar9287Modes_rx_gain_9287_1_0[][6] = {
> { 0x0000a848, 0x00000000, 0x00000000, 0x00001067, 0x00001067, 0x00001067 },
> };
>
> -static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_0[][2] = {
> +static const u32 ar9287PciePhy_clkreq_always_on_L1_9287_1_0[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -3707,7 +3707,7 @@ static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_0[][2] = {
> {0x00004044, 0x00000000 },
> };
>
> -static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_0[][2] = {
> +static const u32 ar9287PciePhy_clkreq_off_L1_9287_1_0[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -3722,7 +3722,7 @@ static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_0[][2] = {
>
> /* AR9287 Revision 11 */
>
> -static const u_int32_t ar9287Modes_9287_1_1[][6] = {
> +static const u32 ar9287Modes_9287_1_1[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x00001030, 0x00000000, 0x00000000, 0x000002c0, 0x00000160, 0x000001e0 },
> { 0x00001070, 0x00000000, 0x00000000, 0x00000318, 0x0000018c, 0x000001e0 },
> @@ -3769,7 +3769,7 @@ static const u_int32_t ar9287Modes_9287_1_1[][6] = {
> { 0x0000a3d8, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> };
>
> -static const u_int32_t ar9287Common_9287_1_1[][2] = {
> +static const u32 ar9287Common_9287_1_1[][2] = {
> { 0x0000000c, 0x00000000 },
> { 0x00000030, 0x00020015 },
> { 0x00000034, 0x00000005 },
> @@ -4142,19 +4142,19 @@ static const u_int32_t ar9287Common_9287_1_1[][2] = {
> * registers be programmed differently from the channel between 2412 and
> * 2472 MHz.
> */
> -static const u_int32_t ar9287Common_normal_cck_fir_coeff_92871_1[][2] = {
> +static const u32 ar9287Common_normal_cck_fir_coeff_92871_1[][2] = {
> { 0x0000a1f4, 0x00fffeff },
> { 0x0000a1f8, 0x00f5f9ff },
> { 0x0000a1fc, 0xb79f6427 },
> };
>
> -static const u_int32_t ar9287Common_japan_2484_cck_fir_coeff_92871_1[][2] = {
> +static const u32 ar9287Common_japan_2484_cck_fir_coeff_92871_1[][2] = {
> { 0x0000a1f4, 0x00000000 },
> { 0x0000a1f8, 0xefff0301 },
> { 0x0000a1fc, 0xca9228ee },
> };
>
> -static const u_int32_t ar9287Modes_tx_gain_9287_1_1[][6] = {
> +static const u32 ar9287Modes_tx_gain_9287_1_1[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00004002, 0x00004002, 0x00004002 },
> @@ -4203,7 +4203,7 @@ static const u_int32_t ar9287Modes_tx_gain_9287_1_1[][6] = {
> { 0x0000a274, 0x0a180000, 0x0a180000, 0x0a1aa000, 0x0a1aa000, 0x0a1aa000 },
> };
>
> -static const u_int32_t ar9287Modes_rx_gain_9287_1_1[][6] = {
> +static const u32 ar9287Modes_rx_gain_9287_1_1[][6] = {
> /* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
> { 0x00009a00, 0x00000000, 0x00000000, 0x0000a120, 0x0000a120, 0x0000a120 },
> { 0x00009a04, 0x00000000, 0x00000000, 0x0000a124, 0x0000a124, 0x0000a124 },
> @@ -4465,7 +4465,7 @@ static const u_int32_t ar9287Modes_rx_gain_9287_1_1[][6] = {
> { 0x0000a848, 0x00000000, 0x00000000, 0x00001067, 0x00001067, 0x00001067 },
> };
>
> -static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_1[][2] = {
> +static const u32 ar9287PciePhy_clkreq_always_on_L1_9287_1_1[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -4478,7 +4478,7 @@ static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_1[][2] = {
> {0x00004044, 0x00000000 },
> };
>
> -static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_1[][2] = {
> +static const u32 ar9287PciePhy_clkreq_off_L1_9287_1_1[][2] = {
> {0x00004040, 0x9248fd00 },
> {0x00004040, 0x24924924 },
> {0x00004040, 0xa8000019 },
> @@ -4493,7 +4493,7 @@ static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_1[][2] = {
>
>
> /* AR9271 initialization values automaticaly created: 06/04/09 */
> -static const u_int32_t ar9271Modes_9271[][6] = {
> +static const u32 ar9271Modes_9271[][6] = {
> { 0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160, 0x000001e0 },
> { 0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c, 0x000001e0 },
> { 0x000010b0, 0x00000e60, 0x00001cc0, 0x00007c70, 0x00003e38, 0x00001180 },
> @@ -4799,7 +4799,7 @@ static const u_int32_t ar9271Modes_9271[][6] = {
> { 0x0000a358, 0x7999aa02, 0x7999aa02, 0x7999aa0e, 0x7999aa0e, 0x7999aa0e },
> };
>
> -static const u_int32_t ar9271Common_9271[][2] = {
> +static const u32 ar9271Common_9271[][2] = {
> { 0x0000000c, 0x00000000 },
> { 0x00000030, 0x00020045 },
> { 0x00000034, 0x00000005 },
> @@ -5127,24 +5127,24 @@ static const u_int32_t ar9271Common_9271[][2] = {
> { 0x0000d384, 0xf3307ff0 },
> };
>
> -static const u_int32_t ar9271Common_normal_cck_fir_coeff_9271[][2] = {
> +static const u32 ar9271Common_normal_cck_fir_coeff_9271[][2] = {
> { 0x0000a1f4, 0x00fffeff },
> { 0x0000a1f8, 0x00f5f9ff },
> { 0x0000a1fc, 0xb79f6427 },
> };
>
> -static const u_int32_t ar9271Common_japan_2484_cck_fir_coeff_9271[][2] = {
> +static const u32 ar9271Common_japan_2484_cck_fir_coeff_9271[][2] = {
> { 0x0000a1f4, 0x00000000 },
> { 0x0000a1f8, 0xefff0301 },
> { 0x0000a1fc, 0xca9228ee },
> };
>
> -static const u_int32_t ar9271Modes_9271_1_0_only[][6] = {
> +static const u32 ar9271Modes_9271_1_0_only[][6] = {
> { 0x00009910, 0x30002311, 0x30002311, 0x30002311, 0x30002311, 0x30002311 },
> { 0x00009828, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001 },
> };
>
> -static const u_int32_t ar9271Modes_9271_ANI_reg[][6] = {
> +static const u32 ar9271Modes_9271_ANI_reg[][6] = {
> { 0x00009850, 0x6d4000e2, 0x6d4000e2, 0x6d4000e2, 0x6d4000e2, 0x6d4000e2 },
> { 0x0000985c, 0x3139605e, 0x3139605e, 0x3137605e, 0x3137605e, 0x3139605e },
> { 0x00009858, 0x7ec84d2e, 0x7ec84d2e, 0x7ec84d2e, 0x7ec84d2e, 0x7ec84d2e },
> @@ -5155,7 +5155,7 @@ static const u_int32_t ar9271Modes_9271_ANI_reg[][6] = {
> { 0x000099c0, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4 },
> };
>
> -static const u_int32_t ar9271Modes_normal_power_tx_gain_9271[][6] = {
> +static const u32 ar9271Modes_normal_power_tx_gain_9271[][6] = {
> { 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00009200, 0x00009200, 0x00000000 },
> { 0x0000a308, 0x00000000, 0x00000000, 0x00010208, 0x00010208, 0x00000000 },
> @@ -5191,7 +5191,7 @@ static const u_int32_t ar9271Modes_normal_power_tx_gain_9271[][6] = {
> { 0x0000a3e0, 0x000003bd, 0x000003bd, 0x000003bd, 0x000003bd, 0x000003bd },
> };
>
> -static const u_int32_t ar9271Modes_high_power_tx_gain_9271[][6] = {
> +static const u32 ar9271Modes_high_power_tx_gain_9271[][6] = {
> { 0x0000a300, 0x00000000, 0x00000000, 0x00010000, 0x00010000, 0x00000000 },
> { 0x0000a304, 0x00000000, 0x00000000, 0x00016200, 0x00016200, 0x00000000 },
> { 0x0000a308, 0x00000000, 0x00000000, 0x00018201, 0x00018201, 0x00000000 },
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH 2/2] ath9k_hw: make all AR9002 initvals use u32
From: Luis R. Rodriguez @ 2010-04-20 22:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1271802516-15195-1-git-send-email-lrodriguez@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 68 +++++++++++-----------
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
index 0f74ea7..f06313d 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
@@ -1468,7 +1468,7 @@ static const u32 ar9280PciePhy_clkreq_always_on_L1_9280[][2] = {
};
/* AR9285 Revsion 10*/
-static const u_int32_t ar9285Modes_9285[][6] = {
+static const u32 ar9285Modes_9285[][6] = {
{ 0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160, 0x000001e0 },
{ 0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c, 0x000001e0 },
{ 0x000010b0, 0x00000e60, 0x00001cc0, 0x00007c70, 0x00003e38, 0x00001180 },
@@ -1790,7 +1790,7 @@ static const u_int32_t ar9285Modes_9285[][6] = {
{ 0x0000a358, 0x7999aa02, 0x7999aa02, 0x7999aa0e, 0x7999aa0e, 0x7999aa0e },
};
-static const u_int32_t ar9285Common_9285[][2] = {
+static const u32 ar9285Common_9285[][2] = {
{ 0x0000000c, 0x00000000 },
{ 0x00000030, 0x00020045 },
{ 0x00000034, 0x00000005 },
@@ -2123,7 +2123,7 @@ static const u_int32_t ar9285Common_9285[][2] = {
{ 0x00007870, 0x10142c00 },
};
-static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285[][2] = {
+static const u32 ar9285PciePhy_clkreq_always_on_L1_9285[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -2136,7 +2136,7 @@ static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285[][2] = {
{0x00004044, 0x00000000 },
};
-static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285[][2] = {
+static const u32 ar9285PciePhy_clkreq_off_L1_9285[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -2150,7 +2150,7 @@ static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285[][2] = {
};
/* AR9285 v1_2 PCI Register Writes. Created: 04/13/09 */
-static const u_int32_t ar9285Modes_9285_1_2[][6] = {
+static const u32 ar9285Modes_9285_1_2[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160, 0x000001e0 },
{ 0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c, 0x000001e0 },
@@ -2456,7 +2456,7 @@ static const u_int32_t ar9285Modes_9285_1_2[][6] = {
{ 0x0000a358, 0x7999aa02, 0x7999aa02, 0x7999aa0e, 0x7999aa0e, 0x7999aa0e },
};
-static const u_int32_t ar9285Common_9285_1_2[][2] = {
+static const u32 ar9285Common_9285_1_2[][2] = {
{ 0x0000000c, 0x00000000 },
{ 0x00000030, 0x00020045 },
{ 0x00000034, 0x00000005 },
@@ -2775,7 +2775,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
{ 0x00007870, 0x10142c00 },
};
-static const u_int32_t ar9285Modes_high_power_tx_gain_9285_1_2[][6] = {
+static const u32 ar9285Modes_high_power_tx_gain_9285_1_2[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00006200, 0x00006200, 0x00000000 },
@@ -2816,7 +2816,7 @@ static const u_int32_t ar9285Modes_high_power_tx_gain_9285_1_2[][6] = {
{ 0x0000a3e0, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7 },
};
-static const u_int32_t ar9285Modes_original_tx_gain_9285_1_2[][6] = {
+static const u32 ar9285Modes_original_tx_gain_9285_1_2[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00009200, 0x00009200, 0x00000000 },
@@ -2857,7 +2857,7 @@ static const u_int32_t ar9285Modes_original_tx_gain_9285_1_2[][6] = {
{ 0x0000a3e0, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c },
};
-static const u_int32_t ar9285Modes_XE2_0_normal_power[][6] = {
+static const u32 ar9285Modes_XE2_0_normal_power[][6] = {
{ 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00009200, 0x00009200, 0x00000000 },
{ 0x0000a308, 0x00000000, 0x00000000, 0x00010208, 0x00010208, 0x00000000 },
@@ -2897,7 +2897,7 @@ static const u_int32_t ar9285Modes_XE2_0_normal_power[][6] = {
{ 0x0000a3e0, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c, 0x0000039c },
};
-static const u_int32_t ar9285Modes_XE2_0_high_power[][6] = {
+static const u32 ar9285Modes_XE2_0_high_power[][6] = {
{ 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00006200, 0x00006200, 0x00000000 },
{ 0x0000a308, 0x00000000, 0x00000000, 0x00008201, 0x00008201, 0x00000000 },
@@ -2937,7 +2937,7 @@ static const u_int32_t ar9285Modes_XE2_0_high_power[][6] = {
{ 0x0000a3e0, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7, 0x000000e7 },
};
-static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285_1_2[][2] = {
+static const u32 ar9285PciePhy_clkreq_always_on_L1_9285_1_2[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -2950,7 +2950,7 @@ static const u_int32_t ar9285PciePhy_clkreq_always_on_L1_9285_1_2[][2] = {
{0x00004044, 0x00000000 },
};
-static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285_1_2[][2] = {
+static const u32 ar9285PciePhy_clkreq_off_L1_9285_1_2[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -2964,7 +2964,7 @@ static const u_int32_t ar9285PciePhy_clkreq_off_L1_9285_1_2[][2] = {
};
/* AR9287 Revision 10 */
-static const u_int32_t ar9287Modes_9287_1_0[][6] = {
+static const u32 ar9287Modes_9287_1_0[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x00001030, 0x00000000, 0x00000000, 0x000002c0, 0x00000160, 0x000001e0 },
{ 0x00001070, 0x00000000, 0x00000000, 0x00000318, 0x0000018c, 0x000001e0 },
@@ -3011,7 +3011,7 @@ static const u_int32_t ar9287Modes_9287_1_0[][6] = {
{ 0x0000a3d8, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
};
-static const u_int32_t ar9287Common_9287_1_0[][2] = {
+static const u32 ar9287Common_9287_1_0[][2] = {
{ 0x0000000c, 0x00000000 },
{ 0x00000030, 0x00020015 },
{ 0x00000034, 0x00000005 },
@@ -3382,7 +3382,7 @@ static const u_int32_t ar9287Common_9287_1_0[][2] = {
{ 0x000078b8, 0x2a850160 },
};
-static const u_int32_t ar9287Modes_tx_gain_9287_1_0[][6] = {
+static const u32 ar9287Modes_tx_gain_9287_1_0[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00004002, 0x00004002, 0x00004002 },
@@ -3432,7 +3432,7 @@ static const u_int32_t ar9287Modes_tx_gain_9287_1_0[][6] = {
};
-static const u_int32_t ar9287Modes_rx_gain_9287_1_0[][6] = {
+static const u32 ar9287Modes_rx_gain_9287_1_0[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x00009a00, 0x00000000, 0x00000000, 0x0000a120, 0x0000a120, 0x0000a120 },
{ 0x00009a04, 0x00000000, 0x00000000, 0x0000a124, 0x0000a124, 0x0000a124 },
@@ -3694,7 +3694,7 @@ static const u_int32_t ar9287Modes_rx_gain_9287_1_0[][6] = {
{ 0x0000a848, 0x00000000, 0x00000000, 0x00001067, 0x00001067, 0x00001067 },
};
-static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_0[][2] = {
+static const u32 ar9287PciePhy_clkreq_always_on_L1_9287_1_0[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -3707,7 +3707,7 @@ static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_0[][2] = {
{0x00004044, 0x00000000 },
};
-static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_0[][2] = {
+static const u32 ar9287PciePhy_clkreq_off_L1_9287_1_0[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -3722,7 +3722,7 @@ static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_0[][2] = {
/* AR9287 Revision 11 */
-static const u_int32_t ar9287Modes_9287_1_1[][6] = {
+static const u32 ar9287Modes_9287_1_1[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x00001030, 0x00000000, 0x00000000, 0x000002c0, 0x00000160, 0x000001e0 },
{ 0x00001070, 0x00000000, 0x00000000, 0x00000318, 0x0000018c, 0x000001e0 },
@@ -3769,7 +3769,7 @@ static const u_int32_t ar9287Modes_9287_1_1[][6] = {
{ 0x0000a3d8, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
};
-static const u_int32_t ar9287Common_9287_1_1[][2] = {
+static const u32 ar9287Common_9287_1_1[][2] = {
{ 0x0000000c, 0x00000000 },
{ 0x00000030, 0x00020015 },
{ 0x00000034, 0x00000005 },
@@ -4142,19 +4142,19 @@ static const u_int32_t ar9287Common_9287_1_1[][2] = {
* registers be programmed differently from the channel between 2412 and
* 2472 MHz.
*/
-static const u_int32_t ar9287Common_normal_cck_fir_coeff_92871_1[][2] = {
+static const u32 ar9287Common_normal_cck_fir_coeff_92871_1[][2] = {
{ 0x0000a1f4, 0x00fffeff },
{ 0x0000a1f8, 0x00f5f9ff },
{ 0x0000a1fc, 0xb79f6427 },
};
-static const u_int32_t ar9287Common_japan_2484_cck_fir_coeff_92871_1[][2] = {
+static const u32 ar9287Common_japan_2484_cck_fir_coeff_92871_1[][2] = {
{ 0x0000a1f4, 0x00000000 },
{ 0x0000a1f8, 0xefff0301 },
{ 0x0000a1fc, 0xca9228ee },
};
-static const u_int32_t ar9287Modes_tx_gain_9287_1_1[][6] = {
+static const u32 ar9287Modes_tx_gain_9287_1_1[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00004002, 0x00004002, 0x00004002 },
@@ -4203,7 +4203,7 @@ static const u_int32_t ar9287Modes_tx_gain_9287_1_1[][6] = {
{ 0x0000a274, 0x0a180000, 0x0a180000, 0x0a1aa000, 0x0a1aa000, 0x0a1aa000 },
};
-static const u_int32_t ar9287Modes_rx_gain_9287_1_1[][6] = {
+static const u32 ar9287Modes_rx_gain_9287_1_1[][6] = {
/* Address 5G-HT20 5G-HT40 2G-HT40 2G-HT20 Turbo */
{ 0x00009a00, 0x00000000, 0x00000000, 0x0000a120, 0x0000a120, 0x0000a120 },
{ 0x00009a04, 0x00000000, 0x00000000, 0x0000a124, 0x0000a124, 0x0000a124 },
@@ -4465,7 +4465,7 @@ static const u_int32_t ar9287Modes_rx_gain_9287_1_1[][6] = {
{ 0x0000a848, 0x00000000, 0x00000000, 0x00001067, 0x00001067, 0x00001067 },
};
-static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_1[][2] = {
+static const u32 ar9287PciePhy_clkreq_always_on_L1_9287_1_1[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -4478,7 +4478,7 @@ static const u_int32_t ar9287PciePhy_clkreq_always_on_L1_9287_1_1[][2] = {
{0x00004044, 0x00000000 },
};
-static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_1[][2] = {
+static const u32 ar9287PciePhy_clkreq_off_L1_9287_1_1[][2] = {
{0x00004040, 0x9248fd00 },
{0x00004040, 0x24924924 },
{0x00004040, 0xa8000019 },
@@ -4493,7 +4493,7 @@ static const u_int32_t ar9287PciePhy_clkreq_off_L1_9287_1_1[][2] = {
/* AR9271 initialization values automaticaly created: 06/04/09 */
-static const u_int32_t ar9271Modes_9271[][6] = {
+static const u32 ar9271Modes_9271[][6] = {
{ 0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160, 0x000001e0 },
{ 0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c, 0x000001e0 },
{ 0x000010b0, 0x00000e60, 0x00001cc0, 0x00007c70, 0x00003e38, 0x00001180 },
@@ -4799,7 +4799,7 @@ static const u_int32_t ar9271Modes_9271[][6] = {
{ 0x0000a358, 0x7999aa02, 0x7999aa02, 0x7999aa0e, 0x7999aa0e, 0x7999aa0e },
};
-static const u_int32_t ar9271Common_9271[][2] = {
+static const u32 ar9271Common_9271[][2] = {
{ 0x0000000c, 0x00000000 },
{ 0x00000030, 0x00020045 },
{ 0x00000034, 0x00000005 },
@@ -5127,24 +5127,24 @@ static const u_int32_t ar9271Common_9271[][2] = {
{ 0x0000d384, 0xf3307ff0 },
};
-static const u_int32_t ar9271Common_normal_cck_fir_coeff_9271[][2] = {
+static const u32 ar9271Common_normal_cck_fir_coeff_9271[][2] = {
{ 0x0000a1f4, 0x00fffeff },
{ 0x0000a1f8, 0x00f5f9ff },
{ 0x0000a1fc, 0xb79f6427 },
};
-static const u_int32_t ar9271Common_japan_2484_cck_fir_coeff_9271[][2] = {
+static const u32 ar9271Common_japan_2484_cck_fir_coeff_9271[][2] = {
{ 0x0000a1f4, 0x00000000 },
{ 0x0000a1f8, 0xefff0301 },
{ 0x0000a1fc, 0xca9228ee },
};
-static const u_int32_t ar9271Modes_9271_1_0_only[][6] = {
+static const u32 ar9271Modes_9271_1_0_only[][6] = {
{ 0x00009910, 0x30002311, 0x30002311, 0x30002311, 0x30002311, 0x30002311 },
{ 0x00009828, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001 },
};
-static const u_int32_t ar9271Modes_9271_ANI_reg[][6] = {
+static const u32 ar9271Modes_9271_ANI_reg[][6] = {
{ 0x00009850, 0x6d4000e2, 0x6d4000e2, 0x6d4000e2, 0x6d4000e2, 0x6d4000e2 },
{ 0x0000985c, 0x3139605e, 0x3139605e, 0x3137605e, 0x3137605e, 0x3139605e },
{ 0x00009858, 0x7ec84d2e, 0x7ec84d2e, 0x7ec84d2e, 0x7ec84d2e, 0x7ec84d2e },
@@ -5155,7 +5155,7 @@ static const u_int32_t ar9271Modes_9271_ANI_reg[][6] = {
{ 0x000099c0, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4 },
};
-static const u_int32_t ar9271Modes_normal_power_tx_gain_9271[][6] = {
+static const u32 ar9271Modes_normal_power_tx_gain_9271[][6] = {
{ 0x0000a300, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00009200, 0x00009200, 0x00000000 },
{ 0x0000a308, 0x00000000, 0x00000000, 0x00010208, 0x00010208, 0x00000000 },
@@ -5191,7 +5191,7 @@ static const u_int32_t ar9271Modes_normal_power_tx_gain_9271[][6] = {
{ 0x0000a3e0, 0x000003bd, 0x000003bd, 0x000003bd, 0x000003bd, 0x000003bd },
};
-static const u_int32_t ar9271Modes_high_power_tx_gain_9271[][6] = {
+static const u32 ar9271Modes_high_power_tx_gain_9271[][6] = {
{ 0x0000a300, 0x00000000, 0x00000000, 0x00010000, 0x00010000, 0x00000000 },
{ 0x0000a304, 0x00000000, 0x00000000, 0x00016200, 0x00016200, 0x00000000 },
{ 0x0000a308, 0x00000000, 0x00000000, 0x00018201, 0x00018201, 0x00000000 },
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] ath9k_hw: make two initvals consto for the AR9001 family
From: Luis R. Rodriguez @ 2010-04-20 22:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1271802516-15195-1-git-send-email-lrodriguez@atheros.com>
This makes ar5416Addac_9160 and ar5416Addac_9160 const
I guess we skipped them long ago.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9001_initvals.h b/drivers/net/wireless/ath/ath9k/ar9001_initvals.h
index 20abffe..0b94bd3 100644
--- a/drivers/net/wireless/ath/ath9k/ar9001_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9001_initvals.h
@@ -1182,7 +1182,7 @@ static const u32 ar5416Bank7_9160[][2] = {
{ 0x000098cc, 0x0000000e },
};
-static u32 ar5416Addac_9160[][2] = {
+static const u32 ar5416Addac_9160[][2] = {
{0x0000989c, 0x00000000 },
{0x0000989c, 0x00000000 },
{0x0000989c, 0x00000000 },
@@ -1217,7 +1217,7 @@ static u32 ar5416Addac_9160[][2] = {
{0x000098cc, 0x00000000 },
};
-static u32 ar5416Addac_91601_1[][2] = {
+static const u32 ar5416Addac_91601_1[][2] = {
{0x0000989c, 0x00000000 },
{0x0000989c, 0x00000000 },
{0x0000989c, 0x00000000 },
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/2] ath9k_hw: few initval cosmetic changes
From: Luis R. Rodriguez @ 2010-04-20 22:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
Just a few cosmetic changes to the initvals. Using the checksum checker
I confirm the values are still intact :)
Luis R. Rodriguez (2):
ath9k_hw: make two initvals consto for the AR9001 family
ath9k_hw: make all AR9002 initvals use u32
drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 4 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 68 +++++++++++-----------
2 files changed, 36 insertions(+), 36 deletions(-)
^ permalink raw reply
* pull request: wireless-2.6 2010-04-20
From: John W. Linville @ 2010-04-20 18:30 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few more intended for 2.6.34, mostly from the iwlwifi team.
They fix a couple of potential crashes, an incorrect EEPROM offset
related to regulatory information, and a connectivity failure relating
to 802.11n and the 4965. The "iwlwifi: fix scan races" seems a little
long, but much of it is the fallout from renaming a goto label.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit b91ecb0027c7171c83d7cf443a22c39b1fde6d83:
Tilman Schmidt (1):
gigaset: include cleanup cleanup
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (2):
iwlwifi: fix scan races
mac80211: remove bogus TX agg state assignment
Reinette Chatre (1):
mac80211: pass HT changes to driver when off channel
Shanyu Zhao (1):
iwlwifi: correct 6000 EEPROM regulatory address
drivers/net/wireless/iwlwifi/iwl-6000.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 1 +
drivers/net/wireless/iwlwifi/iwl-core.c | 1 -
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 4 +++
drivers/net/wireless/iwlwifi/iwl-scan.c | 31 ++++++++++++++++++----------
net/mac80211/agg-tx.c | 1 -
net/mac80211/mlme.c | 2 +
9 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index c4844ad..92b3e64 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -259,7 +259,7 @@ static struct iwl_lib_ops iwl6000_lib = {
EEPROM_5000_REG_BAND_3_CHANNELS,
EEPROM_5000_REG_BAND_4_CHANNELS,
EEPROM_5000_REG_BAND_5_CHANNELS,
- EEPROM_5000_REG_BAND_24_HT40_CHANNELS,
+ EEPROM_6000_REG_BAND_24_HT40_CHANNELS,
EEPROM_5000_REG_BAND_52_HT40_CHANNELS
},
.verify_signature = iwlcore_eeprom_verify_signature,
@@ -323,7 +323,7 @@ static struct iwl_lib_ops iwl6050_lib = {
EEPROM_5000_REG_BAND_3_CHANNELS,
EEPROM_5000_REG_BAND_4_CHANNELS,
EEPROM_5000_REG_BAND_5_CHANNELS,
- EEPROM_5000_REG_BAND_24_HT40_CHANNELS,
+ EEPROM_6000_REG_BAND_24_HT40_CHANNELS,
EEPROM_5000_REG_BAND_52_HT40_CHANNELS
},
.verify_signature = iwlcore_eeprom_verify_signature,
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index e4c2e1e..ba0fdba 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -3330,6 +3330,7 @@ static void iwl_cancel_deferred_work(struct iwl_priv *priv)
cancel_delayed_work_sync(&priv->init_alive_start);
cancel_delayed_work(&priv->scan_check);
+ cancel_work_sync(&priv->start_internal_scan);
cancel_delayed_work(&priv->alive_start);
cancel_work_sync(&priv->beacon_update);
del_timer_sync(&priv->statistics_periodic);
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 894bcb8..1459cdb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -3357,7 +3357,6 @@ static void iwl_force_rf_reset(struct iwl_priv *priv)
*/
IWL_DEBUG_INFO(priv, "perform radio reset.\n");
iwl_internal_short_hw_scan(priv);
- return;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 732590f..36940a9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -506,7 +506,7 @@ void iwl_init_scan_params(struct iwl_priv *priv);
int iwl_scan_cancel(struct iwl_priv *priv);
int iwl_scan_cancel_timeout(struct iwl_priv *priv, unsigned long ms);
int iwl_mac_hw_scan(struct ieee80211_hw *hw, struct cfg80211_scan_request *req);
-int iwl_internal_short_hw_scan(struct iwl_priv *priv);
+void iwl_internal_short_hw_scan(struct iwl_priv *priv);
int iwl_force_reset(struct iwl_priv *priv, int mode);
u16 iwl_fill_probe_req(struct iwl_priv *priv, struct ieee80211_mgmt *frame,
const u8 *ie, int ie_len, int left);
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 6054c5f..ef1720a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -1296,6 +1296,7 @@ struct iwl_priv {
struct work_struct tt_work;
struct work_struct ct_enter;
struct work_struct ct_exit;
+ struct work_struct start_internal_scan;
struct tasklet_struct irq_tasklet;
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 4e1ba82..8171c70 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -203,6 +203,10 @@ struct iwl_eeprom_enhanced_txpwr {
#define EEPROM_5000_REG_BAND_52_HT40_CHANNELS ((0x92)\
| INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 22 bytes */
+/* 6000 regulatory - indirect access */
+#define EEPROM_6000_REG_BAND_24_HT40_CHANNELS ((0x80)\
+ | INDIRECT_ADDRESS | INDIRECT_REGULATORY) /* 14 bytes */
+
/* 6000 and up regulatory tx power - indirect access */
/* max. elements per section */
#define EEPROM_MAX_TXPOWER_SECTION_ELEMENTS (8)
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index bd2f7c4..5062f4e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -469,6 +469,8 @@ EXPORT_SYMBOL(iwl_init_scan_params);
static int iwl_scan_initiate(struct iwl_priv *priv)
{
+ WARN_ON(!mutex_is_locked(&priv->mutex));
+
IWL_DEBUG_INFO(priv, "Starting scan...\n");
set_bit(STATUS_SCANNING, &priv->status);
priv->is_internal_short_scan = false;
@@ -546,24 +548,31 @@ EXPORT_SYMBOL(iwl_mac_hw_scan);
* internal short scan, this function should only been called while associated.
* It will reset and tune the radio to prevent possible RF related problem
*/
-int iwl_internal_short_hw_scan(struct iwl_priv *priv)
+void iwl_internal_short_hw_scan(struct iwl_priv *priv)
{
- int ret = 0;
+ queue_work(priv->workqueue, &priv->start_internal_scan);
+}
+
+static void iwl_bg_start_internal_scan(struct work_struct *work)
+{
+ struct iwl_priv *priv =
+ container_of(work, struct iwl_priv, start_internal_scan);
+
+ mutex_lock(&priv->mutex);
if (!iwl_is_ready_rf(priv)) {
- ret = -EIO;
IWL_DEBUG_SCAN(priv, "not ready or exit pending\n");
- goto out;
+ goto unlock;
}
+
if (test_bit(STATUS_SCANNING, &priv->status)) {
IWL_DEBUG_SCAN(priv, "Scan already in progress.\n");
- ret = -EAGAIN;
- goto out;
+ goto unlock;
}
+
if (test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
IWL_DEBUG_SCAN(priv, "Scan request while abort pending\n");
- ret = -EAGAIN;
- goto out;
+ goto unlock;
}
priv->scan_bands = 0;
@@ -576,9 +585,8 @@ int iwl_internal_short_hw_scan(struct iwl_priv *priv)
set_bit(STATUS_SCANNING, &priv->status);
priv->is_internal_short_scan = true;
queue_work(priv->workqueue, &priv->request_scan);
-
-out:
- return ret;
+ unlock:
+ mutex_unlock(&priv->mutex);
}
EXPORT_SYMBOL(iwl_internal_short_hw_scan);
@@ -964,6 +972,7 @@ void iwl_setup_scan_deferred_work(struct iwl_priv *priv)
INIT_WORK(&priv->scan_completed, iwl_bg_scan_completed);
INIT_WORK(&priv->request_scan, iwl_bg_request_scan);
INIT_WORK(&priv->abort_scan, iwl_bg_abort_scan);
+ INIT_WORK(&priv->start_internal_scan, iwl_bg_start_internal_scan);
INIT_DELAYED_WORK(&priv->scan_check, iwl_bg_scan_check);
}
EXPORT_SYMBOL(iwl_setup_scan_deferred_work);
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 5538e1b..944a8a9 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -183,7 +183,6 @@ static void sta_addba_resp_timer_expired(unsigned long data)
HT_AGG_STATE_REQ_STOP_BA_MSK)) !=
HT_ADDBA_REQUESTED_MSK) {
spin_unlock_bh(&sta->lock);
- *state = HT_AGG_STATE_IDLE;
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "timer expired on tid %d but we are not "
"(or no longer) expecting addBA response there",
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index be5f723..8a96503 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -167,6 +167,8 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
ht_changed = conf_is_ht(&local->hw.conf) != enable_ht ||
channel_type != local->hw.conf.channel_type;
+ if (local->tmp_channel)
+ local->tmp_channel_type = channel_type;
local->oper_channel_type = channel_type;
if (ht_changed) {
--
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 related
* Problem with AR5001 on eeepc900A after disable with RFKILL switch
From: Larry Finger @ 2010-04-20 18:04 UTC (permalink / raw)
To: wireless; +Cc: Bernhard M. Wiedemann
This problem is reported at
https://bugzilla.novell.com/show_bug.cgi?id=595586.
Although not mentioned in the bug report, the kernel is 2.6.33.
The initial part of the report is as follows:
======================================================================
After disabling WLAN on Asus eeepc 900A using rfkill button (Fn+F2) it
does not get back into a working state without a reboot.
Reproducible: Always
Steps to Reproduce:
1. boot up eeepc900A with WLAN enabled
2. press Fn+F2 (rfkill button) to disable WLAN
3. press Fn+F2 again to enable WLAN
Actual Results:
-----
1. lspci before rfkill
01:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114
Gigabit or Fast Ethernet (rev b0)
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless
Network Adapter (rev 01)
-----
2. lspci after rfkill
01:00.0 Ethernet controller: Attansic Technology Corp. Atheros
AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0)
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless
Network Adapter (rev ff)
======================================================================
The curious thing is that the lspci output is different for both the
wired and wireless cards.
Any ideas on why setting rfkill should change data in this way?
Thanks,
Larry
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID now
From: Luis R. Rodriguez @ 2010-04-20 17:36 UTC (permalink / raw)
To: John W. Linville, Stephen Chen, Sujith
Cc: Luis Rodriguez, Wiktor Zajas, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20100420154543.GA6472@tuxdriver.com>
On Tue, Apr 20, 2010 at 08:45:44AM -0700, John W. Linville wrote:
> On Mon, Mar 29, 2010 at 03:20:08PM -0700, Luis R. Rodriguez wrote:
> > On Mon, Mar 29, 2010 at 12:40:09PM -0700, Wiktor Zajas wrote:
> > > Thanks so much for this driver, it's working flawlessly. Only one minor problem
> > > was "Michael MIC failure detected", changing to AES helped.
> >
> > Not sure if Sujith's patch posted yesterday would fix this.
> >
> > > I don't know if what I've done is correct, in order to recognize my card
> > > (TL-WN422G v2) I've added "ATH9K_FW_USB_DEV(0x1006, "ar9271.fw")," to
> > > "ath9k_hif_usb_ids[]", and changed "#define AR9271_USB 0x9271" to
> > > "#define AR9271_USB 0x1006", is this the right thing to do ?
> >
> > Sort of, try this patch:
> >
> > From: Luis R. Rodriguez <lrodriguez@atheros.com>
> > Subject: [PATCH] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID
> >
> > Reported-by: Wiktor Zajas <w.zajas@gmail.com>
> > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > ---
> > drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> > index fc4f6e8..a7664e4 100644
> > --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> > @@ -21,6 +21,7 @@
> >
> > static struct usb_device_id ath9k_hif_usb_ids[] = {
> > ATH9K_FW_USB_DEV(0x9271, "ar9271.fw"),
> > + ATH9K_FW_USB_DEV(0x1006, "ar9271.fw"), /* TL-WN422G v2 */
This patch was wrong, Sujith was going to fix it, I think he sent
some followups. If not we'll take care of it.
Luis
^ permalink raw reply
* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Till Kamppeter @ 2010-04-20 17:31 UTC (permalink / raw)
To: Grant Likely
Cc: Rik van Riel, Theodore Ts'o, Greg KH,
Arnaldo Carvalho de Melo, Luis R. Rodriguez, linux-kernel,
linux-wireless, Witold Sowa, Johannes Berg
In-Reply-To: <i2wfa686aa41004200543gfbb71c98m9a70120fe1cbc8b9@mail.gmail.com>
On 04/20/2010 05:43 AM, Grant Likely wrote:
> On Mon, Apr 19, 2010 at 1:39 PM, Till Kamppeter
> <till.kamppeter@gmail.com> wrote:
>> Please mail me if a mentor needs to be (re)assigned.
>
> Nitin Gupta has 2 proposals on the table (one pending acceptance, and
> one rejection). I'm assigned as mentor on both of them, but I'm
> certainly not qualified. Rik van Riel has expressed a willingness to
> mentor Nitin. Rik, are you willing to take on a second student, or
> can you suggest somebody to mentor Nitin?
>
Set Rik as mentor for the project pending acceptance.
> Alex Lorca's Locator/ID Separation Protocol project is pending
> acceptance, but it has not been reviewed by anyone working in the area
> of network routing. Again, I'm not qualified to mentor this project
> and I do not know who to suggest.
Seems that we have to reject this student because no one wants to mentor
him.
TIll
^ permalink raw reply
* Re: mac80211 and asymmetric 802.11n TX/RX
From: Daniel Halperin @ 2010-04-20 17:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1271751747.8954.3.camel@jlt3.sipsolutions.net>
Hi Johannes,
On Apr 20, 2010, at 1:22 AM, Johannes Berg wrote:
>> Does anyone know if the 11n standard says that the set of TX rates has
>> to be a subset of the set of RX rates? This seems to be enforced now:
>> when I set up one node to be 2x1, i.e. transmit 2 streams but only
>> able to receive 1, then the mac80211 code only lets it transmit 1
>> streams (even with a 2-stream-capable receiver at the other end).
>
> I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
> about the "Rx Highest Supported Data Rate" field. Seems like maybe you
> could set the "RX MCS bitmask" to more than is supported, limit it by
> the highest supported data rate, and then use the bitmask for TX?
First, did you mean 7.3.2.57.4? (I'm using IEEE P802.11n/D7.0, but I assume the section numbers haven't changed). For me that section represents the "Supported MCS Set field".
(An aside: I don't actually *have* 7.3.2.56. I'm using IEEE 802.11-2007 [has up to 7.3.2.35] and IEEE P802.11n/D7.0 [has 7.3.2.57 and beyond] --- In which document are the missing sections?)
Can you point me at which text in the section you think implies this requirement?
In any case, maybe this discussion is silly: I don't know of any devices with this strange configuration. Typically clients assume downlink-heavy and might support a 1x2 connection but 2x1, i.e. designed for uplink, seems unlikely.
>> A second question: my understanding is that if I am a 2x2 node and I
>> associate to a 3x3 AP, the same code will mask out the fact that the
>> AP can receive 3 streams since I can't transmit 3 streams. Is there a
>> way to access this info from the driver if I want it?
>
> Unfortunately not, at this point. We could keep track of it, what would
> you need it for?
Okay, that's what I figured; I can hack around it locally. I'm working on an alternative rate selection algorithm that at one point tries to take into account how much receive diversity the other endpoint has. The intuition is that how well (e.g.) 2-stream rates work is going to depend not just on the channel, but also on how many excess antennas the receiver has. I would benefit from knowing whether they have 2 or 3 antennas even if I can only send them at most 2 streams.
Thanks,
Dan
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: reinette chatre @ 2010-04-20 16:54 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: wireless, Berg, Johannes
In-Reply-To: <n2g2d0a357f1004170705j6d0750fdkc4784f86aab51c97@mail.gmail.com>
Hi,
On Sat, 2010-04-17 at 07:05 -0700, Sedat Dilek wrote:
> I have already sent an bug-report "iwl3945: Network dropouts w/
> flash-stream in firefox" in [1].
> Unfortunately, the problem still remains, especially when
> fast-forwarding flash movies in firefox-3.6.3.
> It seems the wifi-card is hanging and my system needs a coldstart.
Is this a recent problem? How regularly do you update your kernel?
>
> The kernel I use is a Linux-2.6.34-rc4-git4 with these 3 patches in addition:
Where can I access this kernel's git repo?
> According to Johannes (on IRC) iwl3945 doesn't use internal scans yet
> (see my patch below).
> Thus, I am not sure if this needs to be fixed separately for iwl3945
> and if I ran into a scan race condition here.
Does this patch make any difference for you?
> Hope, this helps.
It does. Thank you. As a sanity check, could you please try this patch?
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index c8cd169..1ad15bd 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -814,7 +814,7 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata)
changed |= BSS_CHANGED_ASSOC;
sdata->vif.bss_conf.assoc = false;
- ieee80211_set_wmm_default(sdata);
+ /*ieee80211_set_wmm_default(sdata);*/
/* channel(_type) changes are handled by ieee80211_hw_config */
local->oper_channel_type = NL80211_CHAN_NO_HT;
^ permalink raw reply related
* Re: [ath9k-devel] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID now
From: John W. Linville @ 2010-04-20 15:45 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Wiktor Zajas, ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <20100329222008.GA2852@tux>
On Mon, Mar 29, 2010 at 03:20:08PM -0700, Luis R. Rodriguez wrote:
> On Mon, Mar 29, 2010 at 12:40:09PM -0700, Wiktor Zajas wrote:
> > Thanks so much for this driver, it's working flawlessly. Only one minor problem
> > was "Michael MIC failure detected", changing to AES helped.
>
> Not sure if Sujith's patch posted yesterday would fix this.
>
> > I don't know if what I've done is correct, in order to recognize my card
> > (TL-WN422G v2) I've added "ATH9K_FW_USB_DEV(0x1006, "ar9271.fw")," to
> > "ath9k_hif_usb_ids[]", and changed "#define AR9271_USB 0x9271" to
> > "#define AR9271_USB 0x1006", is this the right thing to do ?
>
> Sort of, try this patch:
>
> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> Subject: [PATCH] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID
>
> Reported-by: Wiktor Zajas <w.zajas@gmail.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index fc4f6e8..a7664e4 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -21,6 +21,7 @@
>
> static struct usb_device_id ath9k_hif_usb_ids[] = {
> ATH9K_FW_USB_DEV(0x9271, "ar9271.fw"),
> + ATH9K_FW_USB_DEV(0x1006, "ar9271.fw"), /* TL-WN422G v2 */
> { },
> };
Any feedback on this?
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: 2.6.34-rc5: Reported regressions from 2.6.33
From: Nick Bowler @ 2010-04-20 13:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <deuQKFRcc0B.A.3EG.BRSzLB@tosh>
On 05:15 Tue 20 Apr , Rafael J. Wysocki wrote:
> If you know of any other unresolved regressions from 2.6.33, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
Please list these two similar regressions from 2.6.33 in the r600 DRM:
* r600 CS checker rejects GL_DEPTH_TEST w/o depth buffer:
https://bugs.freedesktop.org/show_bug.cgi?id=27571
* r600 CS checker rejects narrow FBO renderbuffers:
https://bugs.freedesktop.org/show_bug.cgi?id=27609
Thanks.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
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