* Re: [PATCH] rndis_wlan: set cipher suites for cfg80211
From: Holger Schurig @ 2009-08-26 13:21 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20090826125302.25900.98016.stgit@fate.lan>
> +static const u32 rndis_cipher_suites[] = {
> + WLAN_CIPHER_SUITE_WEP40,
> + WLAN_CIPHER_SUITE_WEP104,
> + WLAN_CIPHER_SUITE_TKIP,
> + WLAN_CIPHER_SUITE_CCMP,
> +};
> +
Okay, this is static, a.k.a. set-in-stone. Then why ...
> + memcpy(priv->cipher_suites, rndis_cipher_suites,
> + sizeof(rndis_cipher_suites));
... copy this to priv?
> + wiphy->cipher_suites = priv->cipher_suites;
> + wiphy->n_cipher_suites = ARRAY_SIZE(rndis_cipher_suites);
Wouldn't
+ wiphy->cipher_suide = rndis_cipher_suites;
+ wiphy->n_cipher_suites = ARRAY_SIZE(rndis_cipher_suites);
do the job? That way you can drop priv->cipher_suites.
--
http://www.holgerschurig.de
^ permalink raw reply
* [PATCH] rndis_wlan: set cipher suites for cfg80211
From: Jussi Kivilinna @ 2009-08-26 12:53 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
rndis_wlan does not set cipher suites list for cfg80211 which causes
wext-compat-range to report rndis_wlan not supporting WPA. Patch adds
cipher suites list and fixes NetworkManager not being able to connect to
WPA encrypted APs.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index c5b921b..f181b00 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -413,6 +413,13 @@ static const struct ieee80211_rate rndis_rates[] = {
{ .bitrate = 540 }
};
+static const u32 rndis_cipher_suites[] = {
+ WLAN_CIPHER_SUITE_WEP40,
+ WLAN_CIPHER_SUITE_WEP104,
+ WLAN_CIPHER_SUITE_TKIP,
+ WLAN_CIPHER_SUITE_CCMP,
+};
+
struct rndis_wlan_encr_key {
int len;
int cipher;
@@ -441,6 +448,7 @@ struct rndis_wlan_private {
struct ieee80211_supported_band band;
struct ieee80211_channel channels[ARRAY_SIZE(rndis_channels)];
struct ieee80211_rate rates[ARRAY_SIZE(rndis_rates)];
+ u32 cipher_suites[ARRAY_SIZE(rndis_cipher_suites)];
struct iw_statistics iwstats;
struct iw_statistics privstats;
@@ -2892,7 +2900,7 @@ static int rndis_wlan_bind(struct usbnet *usbdev, struct usb_interface *intf)
| BIT(NL80211_IFTYPE_ADHOC);
wiphy->max_scan_ssids = 1;
- /* TODO: fill-out band information based on priv->caps */
+ /* TODO: fill-out band/encr information based on priv->caps */
rndis_wlan_get_caps(usbdev);
memcpy(priv->channels, rndis_channels, sizeof(rndis_channels));
@@ -2904,6 +2912,11 @@ static int rndis_wlan_bind(struct usbnet *usbdev, struct usb_interface *intf)
wiphy->bands[IEEE80211_BAND_2GHZ] = &priv->band;
wiphy->signal_type = CFG80211_SIGNAL_TYPE_UNSPEC;
+ memcpy(priv->cipher_suites, rndis_cipher_suites,
+ sizeof(rndis_cipher_suites));
+ wiphy->cipher_suites = priv->cipher_suites;
+ wiphy->n_cipher_suites = ARRAY_SIZE(rndis_cipher_suites);
+
set_wiphy_dev(wiphy, &usbdev->udev->dev);
if (wiphy_register(wiphy)) {
^ permalink raw reply related
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Larry Finger @ 2009-08-26 12:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Hin-Tak Leung, htl10, Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <1251277063.10667.10.camel@johannes.local>
Johannes Berg wrote:
> On Wed, 2009-08-26 at 03:43 +0100, Hin-Tak Leung wrote:
>
>> The rfkill event hard just goes 1 and 0 whenever I slide the switch,
>> regardless of what NM does . e.g. NM set to disable networking has no
>> effect on the 1/0 switch (it happens just depending on the slide
>> switch and nothing else), and nothing changes when NM noticed
>> rfkill'ed if down & decided to if'up and reassociate.
>
> Right, I just wanted to make sure the switch could be correctly read
> while the interface is down.
>
>> Basically the rfkill event state just depends on the slide switch,
>> regardless of NM (if it is set to enable wireless networking, it just
>> if up the device again; if it is set to disable, it just stayed
>> disable & the device stay down, but the event state continues to
>> respond to the slide switch).
>
> Ok. But this isn't making a lot of sense to me, since cfg80211 should
> refuse to UP the device when it's rfkilled.
>
> Or wait ... are you using compat-wireless?
Yes he is.
^ permalink raw reply
* [ANN] rfkill: v0.2
From: wireless @ 2009-08-26 9:50 UTC (permalink / raw)
To: linux-wireless
A new release of rfkill (v0.2) is available at:
http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
Here is the short log of the changes included in this
release:
Johannes Berg (4):
remove iteration and let the kernel do it
add manpage
sync with kernel, add GPS
version 0.2
Tim Gardner (3):
Added a utility function to acquire a list of events.
Added rfkill_block_all()
Added support for block/unblock wireless types.
^ permalink raw reply
* [ANN] iw: v0.9.17
From: wireless @ 2009-08-26 9:50 UTC (permalink / raw)
To: linux-wireless
A new release of iw (v0.9.17) is available at:
http://wireless.kernel.org/download/iw/iw-0.9.17.tar.bz2
SHA1 sum: ca2afc3cdf553a9231fcd7ad59e74cf964fb4b9d
Here is the short log of the changes included in this
release:
Arnd Hannemann (1):
fix output qualifier for unsigned values
Holger Schurig (1):
don't emit usage to stderr
Johannes Berg (3):
also fix %d -> %u for 'iw link'
separate commands into sections
0.9.17
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Johannes Berg @ 2009-08-26 9:09 UTC (permalink / raw)
To: Richard Farina; +Cc: linux-wireless
In-Reply-To: <4A94AA12.4040807@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
On Tue, 2009-08-25 at 23:20 -0400, Richard Farina wrote:
> wireless@sipsolutions.net wrote:
> > A new release of rfkill (v0.2) is available at:
> >
> > http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
> >
> > SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
> >
> > Here is the short log of the changes included in this
> > release:
> >
> >
> Again, a very short list...
Too lazy to fix the script ... guess I should do that so that not every
software release triggers a flood of replies :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Johannes Berg @ 2009-08-26 8:57 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: htl10, Larry Finger, Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <3ace41890908251943n4affc955n61768e2ce98d0c94@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 985 bytes --]
On Wed, 2009-08-26 at 03:43 +0100, Hin-Tak Leung wrote:
> The rfkill event hard just goes 1 and 0 whenever I slide the switch,
> regardless of what NM does . e.g. NM set to disable networking has no
> effect on the 1/0 switch (it happens just depending on the slide
> switch and nothing else), and nothing changes when NM noticed
> rfkill'ed if down & decided to if'up and reassociate.
Right, I just wanted to make sure the switch could be correctly read
while the interface is down.
> Basically the rfkill event state just depends on the slide switch,
> regardless of NM (if it is set to enable wireless networking, it just
> if up the device again; if it is set to disable, it just stayed
> disable & the device stay down, but the event state continues to
> respond to the slide switch).
Ok. But this isn't making a lot of sense to me, since cfg80211 should
refuse to UP the device when it's rfkilled.
Or wait ... are you using compat-wireless?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30
From: Rafał Miłecki @ 2009-08-26 8:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, DRI, Linux SCSI List,
Network Development, Linux Wireless List, Natalie Protasevich,
Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds,
Linux PM List
In-Reply-To: <JuOd1ZASH0B.A.YGB.0zGlKB@chimera>
2009/8/25 Rafael J. Wysocki <rjw@sisk.pl>:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514
> Subject : acer_wmi causes stack corruption
> Submitter : Rus <harbour@sfinx.od.ua>
> Date : 2009-06-12 08:13 (75 days old)
It has patch, just Len doesn't seem to... don't know, read the topic?
http://patchwork.kernel.org/patch/29082/
Can we ping Len somehow to push this patch directly to Linus's tree?
--
Rafał Miłecki
^ permalink raw reply
* Re: [PATCH 1/1] iwmc3200: add more SDIO device ids
From: Holger Schurig @ 2009-08-26 7:25 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Tomas Winkler, Luis R. Rodriguez, davem, netdev, linux-wireless,
Greg KH
In-Reply-To: <1251156118.2950.82.camel@localhost.localdomain>
On Tuesday 25 August 2009 01:21:58 Marcel Holtmann wrote:
> My personal vote is for keeping all IDs inside the drivers.
> And I also prefer to keep the plain hex values and just put a
> comment above them which device this is. Something like this:
>
> static struct usb_device_id btusb_table[] = {
> /* Generic Bluetooth USB device */
> { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+1
When I have an unknown device (and not compiled all modules) it's
so much easier to do an
grep -ri 057c drivers/usb
then to do the same on include/ and then again to find the driver
that uses this id. For the same reason, I prefer 0x057c in the
source and not 0x57c.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Tomas Winkler @ 2009-08-26 7:06 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <E1Mg8tl-0005Rh-8w@sipsolutions.net>
On Wed, Aug 26, 2009 at 6:10 AM, <wireless@sipsolutions.net> wrote:
>
> A new release of rfkill (v0.2) is available at:
>
> http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
>
> SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
>
> Here is the short log of the changes included in this
> release:
>
> Johannes Berg - version 0.2
Thanks for the GPS updated, I should sent you patch myself. :)
Tomas
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Marcel Holtmann @ 2009-08-26 6:56 UTC (permalink / raw)
To: Julian Calaby; +Cc: linux-wireless
In-Reply-To: <646765f40908252017v27f34c48hab7dc9edc23694a3@mail.gmail.com>
Hi Julian,
> > A new release of rfkill (v0.2) is available at:
> >
> > http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
> >
> > SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
> >
> > Here is the short log of the changes included in this
> > release:
> >
> > Johannes Berg - version 0.2
>
> Unless you're just bumping the version number, this is a rather slim release.
seriously, what do you expect from this tool? It is a pretty simple tool
and nothing fancy :)
Regards
Marcel
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Sedat Dilek @ 2009-08-26 6:55 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <E1Mg8tl-0005Rh-8w@sipsolutions.net>
[1] gives you a log of changes.
-SD
[1] http://git.sipsolutions.net/gitweb.cgi?p=rfkill.git;a=log
On Wed, Aug 26, 2009 at 5:10 AM, <wireless@sipsolutions.net> wrote:
>
> A new release of rfkill (v0.2) is available at:
>
> http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
>
> SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
>
> Here is the short log of the changes included in this
> release:
>
> Johannes Berg - version 0.2
> --
> 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
>
^ permalink raw reply
* [PATCH] ath9k: Wrap DMA dump function with PS wakeup/restore
From: Sujith @ 2009-08-26 5:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
When dumping register contents, HW has to be awake.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/debug.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 9e36920..2be4c22 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -93,6 +93,8 @@ static ssize_t read_file_dma(struct file *file, char __user *user_buf,
int i, qcuOffset = 0, dcuOffset = 0;
u32 *qcuBase = &val[0], *dcuBase = &val[4];
+ ath9k_ps_wakeup(sc);
+
REG_WRITE(ah, AR_MACMISC,
((AR_MACMISC_DMA_OBS_LINE_8 << AR_MACMISC_DMA_OBS_S) |
(AR_MACMISC_MISC_OBS_BUS_1 <<
@@ -159,6 +161,8 @@ static ssize_t read_file_dma(struct file *file, char __user *user_buf,
len += snprintf(buf + len, sizeof(buf) - len,
"AR_CR: 0x%x \n", REG_READ(ah, AR_CR));
+ ath9k_ps_restore(sc);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Larry Finger @ 2009-08-26 5:11 UTC (permalink / raw)
To: Richard Farina
Cc: John W Linville, Herton Ronaldo Krzesinski, Hin-Tak Leung,
linux-wireless
In-Reply-To: <4A94B01E.9040309@gmail.com>
Richard Farina wrote:
> Larry Finger wrote:
>> When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
>> may oops when the module is unloaded as the workqueue for led_on was
>> not being cancelled.
>>
>> This patch fixes the problem reported in
>> http://marc.info/?l=linux-wireless&m=124742957615781&w=2.
>>
>> Reported-by: Gábor Stefanik <netrolller.3d@gmail.com>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger>
>> ---
>>
>> V2 - Do not create a new workqueue.
>>
>> John,
>>
>> This patch is 2.6.31 material. To the best of my knowledge, a formal bug
>> report was never filed; however, it was reported in the reference
>> given above.
>>
>>
> Anyone know what happened here? This bug still seems very much alive in
> compat-wireless-2.6.31-rc7. I know the window is closed and this really
> isn't "earthshattering" but a kernel panick is kind of "a big deal". I
> seems like it was tested doing a proper modprobe -r but not if you just
> unplug the usb card.
This kind of accusation is not the best way to get your problem solved.
> When I unplug the usb I get instadeath, very uncool. If someone can
> teach me how to get the kernel output from a non-functional system I am
> happy to provide whatever.
This patch has been in wireless testing since August 3. I have no idea
why it wouldn't be in compat-wireless since then. In addition, I have
unplugged/plugged my RTL8187B device many times with no problem.
I just downloaded compat-wireless-2009-08-26 - it has the patch
included. You certainly could have checked your source to determine that.
To get something from a system that is crashing, you should switch to
the logging console by pressing CTRL/ALT/F10 before you do whatever it
takes to crash it. You will not get a full dump, but hopefully, there
will be enough of the stack visible when the panic occurs. Either copy
down the stack list, or take a picture of the screen and post a link
to it. FYI, you can get back to the graphical screen with CTRL/ALT/F7.
If you have a wired connection in addition to the wireless one, and
you have a second Linux host, you can also capture the dump using
netconsole. Using this facility is not easy, so we'll go the other
route first.
When you report what info you have, please tell what architecture you
are running (i386, x86_64, ppc,...) and whether your device is an
RTL8187L or RTL8187B. It may not matter, but who knows.
Larry
^ permalink raw reply
* Re: Initial work for ar9271
From: Luis R. Rodriguez @ 2009-08-26 4:34 UTC (permalink / raw)
To: Joe Perches
Cc: linux-wireless, linux-kernel, Christian Lamparter, Johannes Berg,
John W. Linville, Greg KH, Stephen Chen, Zhifeng Cai,
Cliff Holden, Christoph Hellwig, Len Widra
In-Reply-To: <1251261111.3463.15.camel@Joe-Laptop.home>
On Tue, Aug 25, 2009 at 9:31 PM, Joe Perches<joe@perches.com> wrote:
> On Tue, 2009-08-25 at 21:03 -0700, Luis R. Rodriguez wrote:
>> If you'd like to work on the
>> driver I welcome patches:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/ar9271.git
>
> I think this style ugly because it's non kernel standard.
Yup! Hence initial release.
> int func(args)
> {
> do {
> [ linear code ...]
> if (err) {
> errorcode = ;
> break;
> }
> [ more linear code ...]
> } while (0);
>
> if (errorcode) {
> handle()...
> return some_err;
> }
>
> return 0;
> }
>
> It's a bit too much like a try/throw/catch block.
So I gladly welcome every type of patch. Nuke nuke nuke.
> Are patches accepted to convert it to the more
> commonly used kernel style using gotos?
Absolutely. Tons of things here have to be removed / ported / etc.
There is even kernel_thread() calls!
Luis
^ permalink raw reply
* Re: Initial work for ar9271
From: Joe Perches @ 2009-08-26 4:31 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, linux-kernel, Christian Lamparter, Johannes Berg,
John W. Linville, Greg KH, Stephen Chen, Zhifeng Cai,
Cliff Holden, Christoph Hellwig, Len Widra
In-Reply-To: <43e72e890908252103j2332d8eat9e18fecb20a1fe58@mail.gmail.com>
On Tue, 2009-08-25 at 21:03 -0700, Luis R. Rodriguez wrote:
> If you'd like to work on the
> driver I welcome patches:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/ar9271.git
I think this style ugly because it's non kernel standard.
int func(args)
{
do {
[ linear code ...]
if (err) {
errorcode = ;
break;
}
[ more linear code ...]
} while (0);
if (errorcode) {
handle()...
return some_err;
}
return 0;
}
It's a bit too much like a try/throw/catch block.
Are patches accepted to convert it to the more
commonly used kernel style using gotos?
^ permalink raw reply
* Re: Initial work for ar9271
From: Greg KH @ 2009-08-26 4:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, linux-kernel, Christian Lamparter, Johannes Berg,
John W. Linville, Stephen Chen, Zhifeng Cai, Cliff Holden,
Christoph Hellwig, Len Widra
In-Reply-To: <43e72e890908252103j2332d8eat9e18fecb20a1fe58@mail.gmail.com>
On Tue, Aug 25, 2009 at 09:03:08PM -0700, Luis R. Rodriguez wrote:
> I'm not yet sure if working with a separate repo or staging might be
> best here as the driver does not yet give STA functionality, the whole
> mac80211 driver part still remains to be developed. Lets play it by
> ear, I'll see if we can get a mailing list created in the meantime
> unless Greg doesn't mind me borrowing the driver project mailing list
> for that.
Not at all, feel free to use it for something like this.
thanks for asking,
greg k-h
^ permalink raw reply
* Initial work for ar9271
From: Luis R. Rodriguez @ 2009-08-26 4:03 UTC (permalink / raw)
To: linux-wireless, linux-kernel
Cc: Christian Lamparter, Johannes Berg, John W. Linville, Greg KH,
Stephen Chen, Zhifeng Cai, Cliff Holden, Christoph Hellwig,
Len Widra
Atheros ar9271 support work is underway with the initial hardware
revision support already added on ath9k [1]. This driver shares a lot
of the framework used by ar6k so there may be potential of sharing
there. The final step of course is to add mac80211 support. ar9271
will just be the first of a few generation of firmware based Atheros
11n devices as such a different driver core will need to be written to
support these devices, specifically for usb its important as we need
to sleep during reads/writes, re-using ath9k as is may not quite do
it. To help iron out the specifics we would like to work with the
community on the rest of the driver. For now I've stuffed what I have
with a clean history on a git repo. If you'd like to work on the
driver I welcome patches:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/ar9271.git
You can get the ar9271.fw firmware here:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/athfw2lnx.git
I encourage really interested developers to please send me a note as
we would like to allocate sample cards for you.
Bare with me on the progress of the driver, this code is so new I
haven't even tested if firmware loading works but I think it may. At
least it compiles now.
I'm not yet sure if working with a separate repo or staging might be
best here as the driver does not yet give STA functionality, the whole
mac80211 driver part still remains to be developed. Lets play it by
ear, I'll see if we can get a mailing list created in the meantime
unless Greg doesn't mind me borrowing the driver project mailing list
for that.
[1] http://marc.info/?l=linux-wireless&m=124935567308276&w=2
Luis
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Richard Farina @ 2009-08-26 3:46 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Herton Ronaldo Krzesinski, Hin-Tak Leung,
linux-wireless
In-Reply-To: <4a5cf0b4.F1C7R/E9sD5tpPd2%Larry.Finger@lwfinger.net>
Larry Finger wrote:
> When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
> may oops when the module is unloaded as the workqueue for led_on was
> not being cancelled.
>
> This patch fixes the problem reported in
> http://marc.info/?l=linux-wireless&m=124742957615781&w=2.
>
> Reported-by: Gábor Stefanik <netrolller.3d@gmail.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger>
> ---
>
> V2 - Do not create a new workqueue.
>
> John,
>
> This patch is 2.6.31 material. To the best of my knowledge, a formal bug
> report was never filed; however, it was reported in the reference given above.
>
>
Anyone know what happened here? This bug still seems very much alive in
compat-wireless-2.6.31-rc7. I know the window is closed and this really
isn't "earthshattering" but a kernel panick is kind of "a big deal". I
seems like it was tested doing a proper modprobe -r but not if you just
unplug the usb card.
When I unplug the usb I get instadeath, very uncool. If someone can
teach me how to get the kernel output from a non-functional system I am
happy to provide whatever.
thanks,
Rick Farina
> Larry
> ---
>
> Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
> +++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> @@ -208,11 +208,12 @@ void rtl8187_leds_exit(struct ieee80211_
> {
> struct rtl8187_priv *priv = dev->priv;
>
> - rtl8187_unregister_led(&priv->led_tx);
> /* turn the LED off before exiting */
> queue_delayed_work(dev->workqueue, &priv->led_off, 0);
> cancel_delayed_work_sync(&priv->led_off);
> + cancel_delayed_work_sync(&priv->led_on);
> rtl8187_unregister_led(&priv->led_rx);
> + rtl8187_unregister_led(&priv->led_tx);
> }
> #endif /* def CONFIG_RTL8187_LED */
>
> --
> 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
>
>
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Richard Farina @ 2009-08-26 3:20 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <E1Mg8tl-0005Rh-8w@sipsolutions.net>
wireless@sipsolutions.net wrote:
> A new release of rfkill (v0.2) is available at:
>
> http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
>
> SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
>
> Here is the short log of the changes included in this
> release:
>
>
Again, a very short list...
-Rick
> Johannes Berg - version 0.2
> --
> 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
>
>
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Julian Calaby @ 2009-08-26 3:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <E1Mg8tl-0005Rh-8w@sipsolutions.net>
On Wed, Aug 26, 2009 at 13:10, <wireless@sipsolutions.net> wrote:
>
> A new release of rfkill (v0.2) is available at:
>
> http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
>
> SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
>
> Here is the short log of the changes included in this
> release:
>
> Johannes Berg - version 0.2
Unless you're just bumping the version number, this is a rather slim release.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* [ANN] rfkill: v0.2
From: wireless @ 2009-08-26 3:10 UTC (permalink / raw)
To: linux-wireless
A new release of rfkill (v0.2) is available at:
http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
Here is the short log of the changes included in this
release:
Johannes Berg - version 0.2
^ permalink raw reply
* [PATCH 4/4] ath9k: Update INITVALs for AR9285
From: Sujith @ 2009-08-26 3:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/initvals.h | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/initvals.h b/drivers/net/wireless/ath/ath9k/initvals.h
index 27a86bb..8622265 100644
--- a/drivers/net/wireless/ath/ath9k/initvals.h
+++ b/drivers/net/wireless/ath/ath9k/initvals.h
@@ -4133,7 +4133,7 @@ static const u_int32_t ar9285Modes_9285_1_2[][6] = {
{ 0x00008318, 0x00003e80, 0x00007d00, 0x00006880, 0x00003440, 0x00006880 },
{ 0x00009804, 0x00000300, 0x000003c4, 0x000003c4, 0x00000300, 0x00000303 },
{ 0x00009820, 0x02020200, 0x02020200, 0x02020200, 0x02020200, 0x02020200 },
- { 0x00009824, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e },
+ { 0x00009824, 0x01000e0e, 0x01000e0e, 0x01000e0e, 0x01000e0e, 0x01000e0e },
{ 0x00009828, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001 },
{ 0x00009834, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e },
{ 0x00009838, 0x00000007, 0x00000007, 0x00000007, 0x00000007, 0x00000007 },
@@ -4158,7 +4158,7 @@ static const u_int32_t ar9285Modes_9285_1_2[][6] = {
{ 0x000099bc, 0x00000600, 0x00000600, 0x00000c00, 0x00000c00, 0x00000c00 },
{ 0x000099c0, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4 },
{ 0x000099c4, 0x06336f77, 0x06336f77, 0x06336f77, 0x06336f77, 0x06336f77 },
- { 0x000099c8, 0x6af65329, 0x6af65329, 0x6af65329, 0x6af65329, 0x6af65329 },
+ { 0x000099c8, 0x6af6532f, 0x6af6532f, 0x6af6532f, 0x6af6532f, 0x6af6532f },
{ 0x000099cc, 0x08f186c8, 0x08f186c8, 0x08f186c8, 0x08f186c8, 0x08f186c8 },
{ 0x000099d0, 0x00046384, 0x00046384, 0x00046384, 0x00046384, 0x00046384 },
{ 0x000099d4, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
@@ -4601,7 +4601,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -4650,7 +4650,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
{ 0x00009954, 0x5f3ca3de },
{ 0x00009958, 0x2108ecff },
{ 0x00009968, 0x000003ce },
- { 0x00009970, 0x192bb515 },
+ { 0x00009970, 0x192bb514 },
{ 0x00009974, 0x00000000 },
{ 0x00009978, 0x00000001 },
{ 0x0000997c, 0x00000000 },
@@ -4728,7 +4728,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
{ 0x00007800, 0x00140000 },
{ 0x00007804, 0x0e4548d8 },
{ 0x00007808, 0x54214514 },
- { 0x0000780c, 0x02025820 },
+ { 0x0000780c, 0x02025830 },
{ 0x00007810, 0x71c0d388 },
{ 0x00007814, 0x924934a8 },
{ 0x0000781c, 0x00000000 },
--
1.6.4
^ permalink raw reply related
* [PATCH 3/4] ath9k: Handle PA cal usage properly
From: Sujith @ 2009-08-26 3:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
PA Calibration is not needed for high power solutions.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index f9de16c..3234995 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -879,6 +879,11 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
DPRINTF(ah->ah_sc, ATH_DBG_CALIBRATE, "Running PA Calibration\n");
+ /* PA CAL is not needed for high power solution */
+ if (ah->eep_ops->get_eeprom(ah, EEP_TXGAIN_TYPE) ==
+ AR5416_EEP_TXGAIN_HIGH_POWER)
+ return;
+
if (AR_SREV_9285_11(ah)) {
REG_WRITE(ah, AR9285_AN_TOP4, (AR9285_AN_TOP4_DEFAULT | 0x14));
udelay(10);
--
1.6.4
^ permalink raw reply related
* [PATCH 2/4] ath9k: Fix bugs in programming registers during PA CAL
From: Sujith @ 2009-08-26 3:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
* First PA driver (PDPADRV1) was not powered down properly.
* Compensation capacitor for dynamic PA was programmed incorrectly.
Also, remove a stray REG_READ.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 47a024d..f9de16c 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -901,13 +901,13 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
REG_RMW_FIELD(ah, AR9285_AN_RF2G2, AR9285_AN_RF2G2_OFFCAL, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PWDDB, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_ENPACAL, 0);
- REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1, 1);
+ REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV2, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPAOUT, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G8, AR9285_AN_RF2G8_PADRVGN2TAB0, 7);
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PADRVGN2TAB0, 0);
ccomp_org = MS(REG_READ(ah, AR9285_AN_RF2G6), AR9285_AN_RF2G6_CCOMP);
- REG_RMW_FIELD(ah, AR9285_AN_RF2G6, AR9285_AN_RF2G6_CCOMP, 7);
+ REG_RMW_FIELD(ah, AR9285_AN_RF2G6, AR9285_AN_RF2G6_CCOMP, 0xf);
REG_WRITE(ah, AR9285_AN_TOP2, 0xca0358a0);
udelay(30);
@@ -919,7 +919,6 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
regVal |= (1 << (19 + i));
REG_WRITE(ah, 0x7834, regVal);
udelay(1);
- regVal = REG_READ(ah, 0x7834);
regVal &= (~(0x1 << (19 + i)));
reg_field = MS(REG_READ(ah, 0x7840), AR9285_AN_RXTXBB1_SPARE9);
regVal |= (reg_field << (19 + i));
--
1.6.4
^ 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